Procedura: Eseguire la migrazione da Servizio di controllo di accesso di Microsoft Azure
Avviso
Questo contenuto riguarda l'endpoint di Azure AD v1.0 meno recente. Per i nuovi progetti, usare Microsoft Identity Platform.
Servizio di controllo di accesso di Microsoft Azure, un servizio di Azure Active Directory (Azure AD), verrà ritirato il 7 novembre 2018. Le applicazioni e i servizi che attualmente utilizzano questo servizio devono eseguire la migrazione completa a un meccanismo di autenticazione diverso entro tale data. Questo articolo presenta i consigli per i clienti attuali che pianificano la deprecazione dell'uso di Controllo di accesso. Se attualmente non si utilizza Controllo di accesso, non è necessario intraprendere alcuna azione.
Panoramica
Controllo di accesso è un servizio di autenticazione cloud che offre un modo semplice per autenticare e autorizzare gli utenti per l'accesso a servizi e applicazioni Web. Consente il factoring di molte funzionalità di autenticazione e autorizzazione dal codice. Controllo di accesso viene utilizzato principalmente dagli sviluppatori e architetti di client Microsoft .NET, applicazioni Web ASP.NET e servizi Web Windows Communication Foundation (WCF).
I casi d'uso per Controllo di accesso possono essere suddivisi in tre categorie principali:
- Autenticazione per determinati servizi cloud Microsoft, tra cui bus di servizio di Azure e Dynamics CRM. Le applicazioni client ottengono token da Controllo di accesso da usare per l'autenticazione in questi servizi per eseguire diverse azioni.
- Aggiunta di autenticazione ad applicazioni Web, sia personalizzate che preconfenzionate (come SharePoint). Tramite l'autenticazione "passiva" di Controllo di accesso, le applicazioni Web possono supportare l'accesso con un account Microsoft (precedentemente Live ID) e con account di Google, Facebook, Yahoo, Azure AD e Active Directory Federation Services (AD FS).
- Protezione di servizi Web personalizzati con token rilasciati da Controllo di accesso. Tramite l'autenticazione "attiva", i servizi Web possono garantire che l'accesso sia consentito solo a client noti che hanno eseguito l'autenticazione con Controllo di accesso.
Questi casi d'uso e le rispettive strategie di migrazione consigliate vengono illustrati nelle sezioni seguenti.
Avviso
Nella maggior parte dei casi sono necessarie modifiche significative al codice per la migrazione delle app e dei servizi esistenti in tecnologie più recenti. È consigliabile iniziare subito a pianificare ed eseguire la migrazione, per evitare qualsiasi rischio di interruzione o di tempo di inattività.
Controllo di accesso include i componenti seguenti:
- Un servizio token di sicurezza, che riceve richieste di autenticazione e restituisce token di sicurezza.
- Il portale di Azure classico, in cui vengono creati, eliminati, attivati e disattivati gli spazi dei nomi di Controllo di accesso.
- Un portale di gestione di Controllo di accesso separato, in cui personalizzare e configurare gli spazi dei nomi di Controllo di accesso.
- Un servizio di gestione che può essere usato per automatizzare le funzioni dei portali.
- Un motore di regole di trasformazione dei token che può essere usato per definire logica complessa per la manipolazione del formato di output dei token rilasciati da Controllo di accesso.
Per usare questi componenti, è necessario creare uno o più spazi dei nomi di Controllo di accesso. Uno spazio dei nomi è un'istanza dedicata di Controllo di accesso con cui comunicano applicazioni e servizi. Uno spazio dei nomi è isolato da tutti gli altri clienti di Controllo di accesso. Altri clienti di Controllo di accesso utilizzano spazi dei nomi dedicati. Uno spazio dei nomi in Controllo di accesso dispone di un URL dedicato simile al seguente:
https://<mynamespace>.accesscontrol.windows.net
Tutte le comunicazioni con il servizio token di sicurezza e tutte le operazioni di gestione vengono eseguite in corrispondenza di questo URL. Si utilizzano percorsi diversi per scopi diversi. Per determinare se le applicazioni o i servizi in uso utilizzano Controllo di accesso, verificare la presenza di qualsiasi tipo di traffico a https://<spaziodeinomi>.accesscontrol.windows.net. Il traffico verso questo URL è gestito da Controllo di accesso e deve essere sospeso.
A questo fa eccezione il traffico verso l'indirizzo https://accounts.accesscontrol.windows.net, che è già gestito da un servizio diverso e non è interessato dal ritiro di Controllo di accesso.
Per altre informazioni su Controllo di accesso, vedere Servizio di controllo di accesso 2.0 (archiviato).
Scoprire quali app saranno interessate
Seguire i passaggi descritti in questa sezione per scoprire quali app saranno interessate dal ritiro di ACS.
Scaricare e installare ACS PowerShell
Passare a PowerShell Gallery e scaricare Acs.Namespaces.
Installare il modulo eseguendo
Install-Module -Name Acs.NamespacesOttenere un elenco di tutti i comandi disponibili eseguendo
Get-Command -Module Acs.NamespacesPer ottenere informazioni su un comando specifico, eseguire:
Get-Help [Command-Name] -Fulldove
[Command-Name]è il nome del comando ACS.
Elencare gli spazi dei nomi ACS
Connettersi ad ACS usando il cmdlet Connect-AcsAccount.
Potrebbe essere necessario eseguire
Set-ExecutionPolicy -ExecutionPolicy Bypassprima di poter eseguire i comandi ed essere l'amministratore di tali sottoscrizioni per eseguire i comandi.Elencare le sottoscrizioni di Azure disponibili usando il cmdlet Get-AcsSubscription.
Elencare gli spazi dei nomi ACS usando il cmdlet Get-AcsNamespace.
Controllare quali applicazioni saranno interessate
Usare lo spazio dei nomi del passaggio precedente e accedere a
https://<namespace>.accesscontrol.windows.netSe ad esempio uno degli spazi dei nomi è contoso-test, passare a
https://contoso-test.accesscontrol.windows.netIn Relazioni di attendibilità selezionare Applicazioni relying party per visualizzare l'elenco di app che saranno interessate dal ritiro di ACS.
Ripetere i passaggi 1 e 2 per qualsiasi altro spazio dei nomi ACS disponibile.
Pianificazione del ritiro
A partire dal mese di novembre 2017, tutti i componenti di Controllo di accesso sono completamente supportati e operativi. L'unica restrizione è l'impossibilità di creare nuovi spazi dei nomi di Controllo di accesso tramite il portale di Azure classico.
Di seguito è riportata la pianificazione della deprecazione dei componenti di Controllo di accesso:
- Novembre 2017: l'esperienza di amministrazione di Azure AD nel portale di Azure classico viene ritirata. A questo punto, la gestione degli spazi dei nomi per Controllo di accesso sarà disponibile presso un nuovo URL dedicato:
https://manage.windowsazure.com?restoreClassic=true. Usare questo URL per visualizzare gli spazi dei nomi esistenti, abilitare e disabilitare gli spazi dei nomi e per eliminare gli spazi dei nomi, se si sceglie di. - 2 aprile 2018: il portale di Azure classico è stato completamente ritirato. Pertanto, la gestione degli spazi dei nomi di Controllo di accesso non è più disponibile tramite un URL. A questo punto, è impossibile disabilitare o abilitare, eliminare o enumerare gli spazi dei nomi di Controllo di accesso. Il portale di gestione di Controllo di accesso, tuttavia, sarà completamente funzionante e disponibile all'indirizzo
https://<namespace>.accesscontrol.windows.net. Tutti gli altri componenti di Controllo di accesso continuano a funzionare normalmente. - 7 novembre 2018: tutti i componenti di Controllo di accesso vengono arrestati in modo permanente. Sono inclusi il portale di gestione di Controllo di accesso, il servizio di gestione, il servizio token di sicurezza e il motore di regole di trasformazione dei token. A questo punto, le richieste inviate a Controllo di accesso (in
<namespace>.accesscontrol.windows.net) hanno esito negativo. È necessario eseguire la migrazione di tutte le app e di tutti i servizi esistenti ad altre tecnologie molto prima di questa data.
Nota
Un criterio disabilita gli spazi dei nomi che non hanno richiesto un token per un periodo di tempo. A partire dall'inizio del mese di settembre 2018, questo periodo di tempo corrisponde attualmente a 14 giorni di inattività, ma verrà ridotto a 7 giorni di inattività nelle prossime settimane. Se ci sono spazi dei nomi Controllo di accesso attualmente disabilitati, è possibile scaricare e installare ACS PowerShell per riabilitare gli spazi dei nomi.
Strategie di migrazione
Le sezioni seguenti illustrano i consigli generali per la migrazione da Controllo di accesso ad altre tecnologie Microsoft.
Client dei servizi cloud Microsoft
Ogni servizio cloud Microsoft che accetta token rilasciati da Controllo di accesso supporta ora almeno una forma alternativa di autenticazione. Il meccanismo di autenticazione corretto varia per ogni servizio. È consigliabile fare riferimento alla documentazione specifica per ogni servizio per indicazioni ufficiali. Per comodità, ogni set di documentazione viene indicato di seguito:
| Servizio | Indicazioni |
|---|---|
| Bus di servizio di Azure | Eseguire la migrazione alle firme di accesso condiviso |
| Inoltro del bus di servizio di Azure | Eseguire la migrazione alle firme di accesso condiviso |
| Cache gestita di Azure | Eseguire la migrazione alla cache di Azure per Redis |
| Azure DataMarket | Eseguire la migrazione alle API dei servizi di intelligenza artificiale di Azure |
| Servizi BizTalk | Eseguire la migrazione alla funzionalità app per la logica del servizio app di Azure |
| Servizi multimediali di Azure | Eseguire la migrazione all'autenticazione di Azure AD |
| Backup di Azure | Aggiornare l'agente di Backup di Azure |
Clienti di SharePoint
I clienti di SharePoint 2013, 2016 e SharePoint Online hanno usato ACS per scopi di autenticazione in scenari cloud, locali e ibridi. Il ritiro di ACS influirà su alcune funzionalità e su alcuni casi d'uso di SharePoint, ma non su altri. La tabella seguente include indicazioni di riepilogo sulla migrazione per alcune delle funzionalità di SharePoint più diffuse che sfruttano ACS:
| Funzionalità | Indicazioni |
|---|---|
| Autenticazione degli utenti da Azure AD | In precedenza Azure AD non supportava i token SAML 1.1 richiesti da SharePoint per l'autenticazione e ACS veniva usato come intermediario per rendere SharePoint compatibile con i formati di token di Azure AD. È ora possibile connettere SharePoint direttamente ad Azure AD usando l'app sharePoint della raccolta di app di Azure AD locale. |
| Autenticazione dell'app & autenticazione da server a server in SharePoint locale | Non interessata dal ritiro di ACS. Non è necessario apportare alcuna modifica. |
| Autorizzazione di attendibilità bassa per componenti aggiuntivi di SharePoint (ospitati da provider e da SharePoint) | Non interessata dal ritiro di ACS. Non è necessario apportare alcuna modifica. |
| Ricerca ibrida su cloud di SharePoint | Non interessata dal ritiro di ACS. Non è necessario apportare alcuna modifica. |
Applicazioni Web che usano l'autenticazione passiva
Per le applicazioni Web che usano Controllo di accesso per l'autenticazione utente, Controllo di accesso offre le seguenti caratteristiche e funzionalità ad architetti e sviluppatori di applicazioni Web:
- Integrazione profonda con Windows Identity Foundation (WIF).
- Federazione con account Google, Facebook, Yahoo, Azure Active Directory, AD FS Microsoft.
- Supporto per i protocolli di autenticazione seguenti: OAuth 2.0 bozza 13, WS-Trust e Web Services Federation (WS-Federation).
- Supporto per i formati di token seguenti: token JSON Web (JWT), SAML 1.1, SAML 2.0 e token Web semplice (SWT).
- Un'esperienza di individuazione dell'area di autenticazione principale, integrata in WIF, che consente agli utenti di scegliere il tipo di account da usare per l'accesso. Questa esperienza è ospitata dall'applicazione Web e completamente personalizzabile.
- Trasformazione dei token che consente la personalizzazione avanzata delle attestazioni ricevute dall'applicazione Web dal Controllo di accesso, tra cui:
- Pass-through delle attestazioni dai provider di identità.
- Aggiunta di altre attestazioni personalizzate.
- Semplice logica if-then per il rilascio di attestazioni in determinate condizioni.
Non è purtroppo disponibile un unico servizio che offra tutte queste funzionalità equivalenti. È consigliabile valutare le funzionalità di Controllo di accesso necessarie e quindi scegliere tra l'uso di Microsoft Entra ID, Azure Active Directory B2C (Azure AD B2C) o un altro servizio di autenticazione cloud.
Eseguire la migrazione all'ID di Microsoft Entra
Un percorso da considerare consiste nell'integrare le app e i servizi direttamente con Microsoft Entra ID. Microsoft Entra ID è il provider di identità basato sul cloud per gli account aziendali o dell'istituto di istruzione Microsoft. Microsoft Entra ID è il provider di identità per Microsoft 365, Azure e molto altro ancora. Offre funzionalità di autenticazione federata simili a quelle di Controllo di accesso, ma non supporta tutte le funzionalità di Controllo di accesso.
L'esempio principale è costituito dalla federazione con i provider di identità di social networking, ad esempio Facebook, Google e Yahoo. Se gli utenti accedono con questi tipi di credenziali, Microsoft Entra ID non è la soluzione.
Microsoft Entra ID non supporta necessariamente gli stessi protocolli di autenticazione di Controllo di accesso. Ad esempio, anche se sia Controllo di accesso che Microsoft Entra ID supportano OAuth, esistono piccole differenze tra ogni implementazione. Implementazioni diverse richiedono modifiche del codice come parte della migrazione.
Tuttavia, Microsoft Entra ID offre diversi vantaggi potenziali per Controllo di accesso clienti. Supporta in modalità nativa gli account Microsoft aziendali e dell'istituto di istruzione ospitati nel cloud, usati in genere dai clienti di Controllo di accesso.
Un tenant di Microsoft Entra può anche essere federato in una o più istanze di Active Directory locale tramite AD FS. In questo modo, l'app può autenticare gli utenti basati su cloud e gli utenti ospitati in locale. Supporta inoltre il protocollo WS-Federation, che rende relativamente semplice l'integrazione con un'applicazione Web tramite WIF.
Nella tabella seguente vengono confrontate le funzionalità di Controllo di accesso rilevanti per le applicazioni Web con quelle disponibili in Microsoft Entra ID.
A livello generale, Microsoft Entra ID è probabilmente la scelta migliore per la migrazione se si consente agli utenti di accedere solo con gli account Microsoft aziendali o dell'istituto di istruzione.
| Funzionalità | Supporto di Controllo di accesso | supporto dell'ID Microsoft Entra |
|---|---|---|
| Tipi di account | ||
| Account Microsoft aziendali o dell'istituto di istruzione | Supportato | Supportato |
| Account da Active Directory di Windows Server e AD FS | - Supportato tramite federazione con un tenant Microsoft Entra - Supportato tramite federazione diretta con AD FS |
Supportato solo tramite federazione con un tenant di Microsoft Entra |
| Account da altri sistemi di gestione delle identità aziendali | - Possibile tramite federazione con un tenant Microsoft Entra - Supportato tramite federazione diretta |
Possibile tramite la federazione con un tenant Microsoft Entra |
| Account Microsoft per uso personale | Supportato | Supportato tramite il protocollo OAuth Microsoft Entra v2.0, ma non tramite altri protocolli |
| Account Facebook, Google, Yahoo | Supportato | Non supportato in alcun modo |
| Compatibilità con protocolli e SDK | ||
| WIF | Supportato | Supportato ma sono disponibili istruzioni limitate |
| WS-Federation | Supportato | Supportato |
| OAuth 2.0 | Supporto per la bozza 13 | Supporto per RFC 6749, la specifica più moderna |
| WS-Trust | Supportato | Non supportato |
| Formati di token | ||
| Token JSON Web | Supportato nella versione Beta | Supportato |
| SAML 1.1 | Supportato | Anteprima |
| SAML 2.0 | Supportato | Supportato |
| Token Web semplice | Supportato | Non supportato |
| Personalizzazioni | ||
| Individuazione dell'area di autenticazione principale/interfaccia utente per la scelta dell'account personalizzabili | Codice scaricabile che può essere incorporato nelle app | Non supportato |
| Caricare certificati per la firma di token personalizzati | Supportato | Supportato |
| Personalizzare le attestazioni nei token | - Eseguire il pass-through delle attestazioni di input dai provider di identità - Ottenere un token di accesso dal provider di identità come attestazione - Rilasciare attestazioni di output in base ai valori delle attestazioni di input - Rilasciare attestazioni di output con valori costanti |
- Non è possibile eseguire il pass-through di attestazioni da provider di identità federati - Non è possibile ottenere un token di accesso dal provider di identità come attestazione - Non è possibile rilasciare attestazioni di output in base ai valori delle attestazioni di input - È possibile rilasciare attestazioni di output con valori costanti - Può emettere attestazioni di output in base alle proprietà degli utenti sincronizzate con Microsoft Entra ID |
| Automazione | ||
| Automatizzare le attività di configurazione e gestione | Supportato tramite il servizio di gestione del Controllo di accesso | Supportato con Microsoft API Graph |
Se si decide che Microsoft Entra ID è il percorso di migrazione migliore per le applicazioni e i servizi, è necessario conoscere due modi per integrare l'app con Microsoft Entra ID.
Per usare WS-Federation o WIF per l'integrazione con Microsoft Entra ID, è consigliabile seguire l'approccio descritto in Configurare l'accesso Single Sign-On federato per un'applicazione non della raccolta. L'articolo si riferisce alla configurazione di Microsoft Entra ID per l'accesso Single Sign-On basato su SAML, ma funziona anche per la configurazione di WS-Federation. Per seguire questo approccio è necessaria una licenza Microsoft Entra ID P1 o P2. Questo approccio presenta due vantaggi:
- Si ottiene la massima flessibilità della personalizzazione dei token di Microsoft Entra. È possibile personalizzare le attestazioni rilasciate da Microsoft Entra ID in modo che corrispondano alle attestazioni rilasciate da Controllo di accesso. In particolare è inclusa l'attestazione di ID utente o Identificatore nome. Per continuare a ricevere identificatori utente coerenti per gli utenti dopo aver modificato le tecnologie, assicurarsi che gli ID utente rilasciati da Microsoft Entra ID corrispondano a quelli rilasciati da Controllo di accesso.
- È possibile configurare un certificato per la firma di token specifico per l'applicazione e controllarne la durata.
Nota
Questo approccio richiede una licenza Microsoft Entra ID P1 o P2. Se si è un cliente di Controllo di accesso e si necessita di una licenza premium per la configurazione dell'accesso Single Sign-On per un'applicazione, contattare Microsoft. Verranno fornite licenze per sviluppatori.
Un approccio alternativo consiste nell'attenersi a questo esempio di codice che fornisce istruzioni leggermente diverse sulla configurazione di WS-Federation. L'esempio di codice non usa WIF, ma il middleware OWIN di ASP.NET 4.5. Tuttavia, le istruzioni per la registrazione dell'app sono valide per le app che usano WIF e non richiedono una licenza Microsoft Entra ID P1 o P2.
Se si sceglie questo approccio, è necessario comprendere il rollover della chiave di firma in Microsoft Entra ID. Questo approccio usa la chiave di firma globale Microsoft Entra per rilasciare i token. Per impostazione predefinita, WIF non aggiorna automaticamente le chiavi di firma. Quando Microsoft Entra ID ruota le chiavi di firma globali, l'implementazione di WIF deve essere pronta ad accettare le modifiche. Per altre informazioni, vedere Informazioni importanti sul rollover della chiave di firma in Microsoft Entra ID.
Se è possibile eseguire l'integrazione con Microsoft Entra ID tramite i protocolli OpenID Connect o OAuth, è consigliabile farlo. La documentazione e le linee guida complete su come integrare Microsoft Entra ID nell'applicazione Web disponibile nella guida per sviluppatori di Microsoft Entra.
Migrazione ad Azure Active Directory B2C
L'altro approccio da prendere in considerazione per la migrazione è relativo ad Azure AD B2C. Azure AD B2C è un servizio di autenticazione cloud che, analogamente a Controllo di accesso, consente agli sviluppatori di eseguire l'outsourcing della logica di autenticazione e di gestione delle identità in un servizio cloud. Si tratta di un servizio a pagamento, con livello gratuito e livello Premium, progettato per applicazioni rivolte ai clienti che possono avere fino a milioni di utenti attivi.
Analogamente a Controllo di accesso, una delle funzionalità più attraenti di Azure AD B2C è costituita dal supporto di molti tipi di account diversi. Con Azure AD B2C, è possibile accedere gli utenti con account Microsoft oppure account Facebook, Google, LinkedIn, GitHub o Yahoo e altro ancora. Azure AD B2C supporta inoltre "account locali" o nome utente e password creati in modo specifico dagli utenti per l'applicazione. Azure AD B2C offre anche un'estendibilità avanzata, che consente di personalizzare i flussi di accesso.
Azure AD B2C, tuttavia, non supporta la varietà di protocolli di autenticazione e i formati di token che potrebbero essere richiesti dai clienti di Controllo di accesso. Non è inoltre possibile usare Azure AD B2C per ottenere token ed eseguire query per informazioni aggiuntive sull'utente dal provider di identità, Microsoft o altro.
La tabella seguente confronta le funzionalità di Controllo di accesso rilevanti per le applicazioni Web con le funzionalità disponibili in Azure AD B2C. A livello generale, Azure AD B2C è probabilmente la scelta ottimale per la migrazione se l'applicazione è rivolta ai consumer o se supporta molti tipi diversi di account.
| Funzionalità | Supporto di Controllo di accesso | Supporto di Azure AD B2C |
|---|---|---|
| Tipi di account | ||
| Account Microsoft aziendali o dell'istituto di istruzione | Supportato | Supportato tramite criteri personalizzati |
| Account da Active Directory di Windows Server e AD FS | Supportato tramite federazione diretta con AD FS | Supportato tramite federazione SAML con criteri personalizzati |
| Account da altri sistemi di gestione delle identità aziendali | Supportato tramite federazione diretta su WS-Federation | Supportato tramite federazione SAML con criteri personalizzati |
| Account Microsoft per uso personale | Supportato | Supportato |
| Account Facebook, Google, Yahoo | Supportato | Facebook e Google supportati in modalità nativa, Yahoo supportato tramite la federazione di OpenID Connect con criteri personalizzati |
| Compatibilità con protocolli e SDK | ||
| Windows Identity Foundation (WIF) | Supportato | Non supportato |
| WS-Federation | Supportato | Non supportato |
| OAuth 2.0 | Supporto per la bozza 13 | Supporto per RFC 6749, la specifica più moderna |
| WS-Trust | Supportato | Non supportato |
| Formati di token | ||
| Token JSON Web | Supportato nella versione Beta | Supportato |
| SAML 1.1 | Supportato | Non supportato |
| SAML 2.0 | Supportato | Non supportato |
| Token Web semplice | Supportato | Non supportato |
| Personalizzazioni | ||
| Individuazione dell'area di autenticazione principale/interfaccia utente per la scelta dell'account personalizzabili | Codice scaricabile che può essere incorporato nelle app | Interfaccia utente completamente personalizzabile tramite CSS personalizzati |
| Caricare certificati per la firma di token personalizzati | Supportato | Chiavi di accesso personalizzate, non certificati, supportati tramite criteri personalizzati |
| Personalizzare le attestazioni nei token | - Eseguire il pass-through delle attestazioni di input dai provider di identità - Ottenere un token di accesso dal provider di identità come attestazione - Rilasciare attestazioni di output in base ai valori delle attestazioni di input - Rilasciare attestazioni di output con valori costanti |
- È possibile eseguire il pass-through delle attestazioni dai provider di identità; alcune attestazioni richiedono criteri personalizzati - Non è possibile ottenere un token di accesso dal provider di identità come attestazione - È possibile rilasciare attestazioni di output in base ai valori delle attestazioni di input tramite criteri personalizzati - È possibile rilasciare attestazioni di output con valori costanti tramite criteri personalizzati |
| Automazione | ||
| Automatizzare le attività di configurazione e gestione | Supportato tramite il servizio di gestione del Controllo di accesso | - Creazione di utenti consentiti tramite microsoft API Graph - Non è possibile creare tenant, applicazioni o criteri di B2C a livello di codice |
Se si decide che Azure AD B2C è l'approccio ottimale per le applicazioni e i servizi in uso, iniziare dalle risorse seguenti:
Eseguire la migrazione a Ping Identity o Auth0
In alcuni casi, è possibile che Microsoft Entra ID e Azure AD B2C non siano sufficienti per sostituire Controllo di accesso nelle applicazioni Web senza apportare modifiche di codice importanti. Ecco alcuni esempi tipici:
- Applicazioni Web che utilizzano WIF o WS-Federation per l'accesso con provider di identità di social network, come Google o Facebook.
- Applicazioni Web che eseguono la federazione diretta a un provider di identità aziendale tramite il protocollo WS-Federation.
- Applicazioni Web che richiedono il token di accesso rilasciato da un provider di identità di social network, ad esempio Google o Facebook, come attestazione nei token rilasciati da Controllo di accesso.
- Applicazioni Web con regole di trasformazione token complesse che Microsoft Entra ID o Azure AD B2C non possono riprodurre.
- Applicazioni web multi-tenant che utilizzano ACS per la gestione centralizzata della federazione a molti provider di identità diversi
In questi casi, è necessario considerare la migrazione dell'applicazione web a un altro servizio di autenticazione cloud. Si consiglia di valutare le opzioni seguenti. Ciascuna delle opzioni seguenti offre funzionalità simili a Controllo di accesso:
Auth0 è un servizio di identità cloud flessibile che ha creato linee guida alla migrazione di alto livello per clienti di Controllo di accesso e supporta quasi tutte le funzionalità di ACS.
Ping Identity offre due soluzioni simili ad ACS. PingOne è un servizio di identità cloud che supporta molte delle stesse funzionalità di ACS e PingFederate è un prodotto di identità locale simile che offre maggiore flessibilità. Fare riferimento alle linee guida di Ping sul ritiro di ACS per ulteriori informazioni sull'utilizzo di questi prodotti.
L'obiettivo della collaborazione con Ping Identity e Auth0 è quello di assicurare a tutti i clienti di Controllo di accesso un percorso di migrazione per le loro app e i loro servizi in grado di ridurre al minimo il lavoro necessario per il passaggio da Controllo di accesso.
Servizi Web con autenticazione attiva
Per i servizi Web protetti con token rilasciati da Controllo di accesso, Controllo di accesso offre le caratteristiche e funzionalità seguenti:
- Possibilità di registrare una o più identità del servizio nello spazio dei nomi di Controllo di accesso. Le identità del servizio sono utilizzabili per richiedere i token.
- Supporto per i protocolli OAuth WRAP e OAuth 2.0 bozza 13 per la richiesta di token tramite i tipi di credenziali seguenti:
- Semplice password creata per l'identità del servizio
- Token Web semplice firmato che usa una chiave simmetrica o un certificato X509
- Token SAML rilasciato da un provider di identità attendibile (in genere un'istanza di AD FS)
- Supporto per i formati di token seguenti: JWT, SAML 1.1, SAML 2.0 e SWT.
- Semplici regole di trasformazione dei token.
Le identità del servizio di Controllo di accesso sono in genere usate per l'implementazione dell'autenticazione di tipo S2S (server-to-server).
Eseguire la migrazione all'ID di Microsoft Entra
Per questo tipo di flusso di autenticazione è consigliabile eseguire la migrazione all'ID di Microsoft Entra. Microsoft Entra ID è il provider di identità basato sul cloud per gli account aziendali o dell'istituto di istruzione Microsoft. Microsoft Entra ID è il provider di identità per Microsoft 365, Azure e molto altro ancora.
È anche possibile usare Microsoft Entra ID per l'autenticazione da server a server usando l'implementazione Microsoft Entra della concessione delle credenziali client OAuth. La tabella seguente confronta le funzionalità di Controllo di accesso nell'autenticazione da server a server con quelle disponibili in Microsoft Entra ID.
| Funzionalità | Supporto di Controllo di accesso | supporto Microsoft Entra ID |
|---|---|---|
| Come registrare un servizio Web | Creare un relying party nel portale di gestione di Controllo di accesso | Creare un'applicazione Web Microsoft Entra nel portale di Azure |
| Come registrare un client | Creare un'identità del servizio nel portale di gestione di Controllo di accesso | Creare un'altra applicazione Web Microsoft Entra nell'portale di Azure |
| Protocollo usato | - Protocollo OAuth WRAP - Concessione di credenziali client OAuth 2.0 bozza 13 |
Concessione di credenziali client OAuth 2.0 |
| Metodi di autenticazione client | - Password semplice - Token Web semplice firmato - Token SAML dal provider di identità federato |
- Password semplice - Token JWT firmato |
| Formati del token | - JWT - SAML 1.1 - SAML 2.0 - SWT |
Solo token JSON Web |
| Trasformazione di token | - Aggiungere attestazioni personalizzate - Logica semplice di emissione di attestazioni if-then |
Aggiungere attestazioni personalizzate |
| Automatizzare le attività di configurazione e gestione | Supportato tramite il servizio di gestione del Controllo di accesso | Supportato usando microsoft API Graph |
Per indicazioni sull'implementazione di scenari S2S, vedere le risorse seguenti:
- Sezione Service-to-Service della guida per sviluppatori di Microsoft Entra
- Esempio di codice Daemon che usa credenziali client per password semplice
- Esempio di codice Daemon che usa credenziali client per il certificato
Eseguire la migrazione a Ping Identity o Auth0
In alcuni casi, è possibile che le credenziali client Microsoft Entra e l'implementazione della concessione OAuth non siano sufficienti per sostituire Controllo di accesso nell'architettura senza modifiche di codice importanti. Ecco alcuni esempi tipici:
- Autenticazione S2S che usa formati di token diversi da JWT.
- Autenticazione S2S che usa un token di input fornito da un provider di identità esterna.
- Autenticazione da server a server con regole di trasformazione token che Microsoft Entra ID non possono riprodurre.
In questi casi, è possibile valutare la migrazione dell'applicazione Web a un altro servizio di autenticazione cloud. Si consiglia di valutare le opzioni seguenti. Ciascuna delle opzioni seguenti offre funzionalità simili a Controllo di accesso:
Auth0 è un servizio di identità cloud flessibile che ha creato linee guida alla migrazione di alto livello per clienti di Controllo di accesso e supporta quasi tutte le funzionalità di ACS.
Ping Identity offre due soluzioni simili a ACS. PingOne è un servizio di gestione delle identità cloud che supporta molte delle stesse funzionalità di ACS e PingFederate è un prodotto di identità locale simile che offre maggiore flessibilità. Fare riferimento alle linee guida di Ping sul ritiro di ACS per ulteriori informazioni sull'utilizzo di questi prodotti.
L'obiettivo della collaborazione con Ping Identity e Auth0 è quello di assicurare a tutti i clienti di Controllo di accesso un percorso di migrazione per le loro app e i loro servizi in grado di ridurre al minimo il lavoro necessario per il passaggio da Controllo di accesso.
Autenticazione pass-through
Per l'autenticazione pass-through con trasformazione arbitraria dei token, non è disponibile alcuna tecnologia Microsoft equivalente al Servizio di controllo di accesso. Se è ciò di cui i clienti hanno bisogno, Auth0 potrebbe essere la soluzione approssimativa più adatta.
Domande, dubbi e commenti
Siamo consapevoli che molti clienti di Controllo di accesso non trovino un percorso di migrazione ideale dopo la lettura di questo articolo. Alcuni potrebbero avere bisogno di assistenza o linee guida per determinare il piano ottimale. In caso di domande sugli scenari di migrazione, inserire un commento in questa pagina.