Migrazione degli spazi dei nomi ACS a Google OpenID Connect

Articolo
11/09/2015

Questo argomento è destinato ai proprietari degli spazi dei nomi del servizio di controllo di accesso (ACS) 2.0 che attualmente usano Google come provider di identità. ACS offre questa funzionalità usando l'implementazione openID 2.0 di Google. Google prevede di interrompere il supporto di OpenID 2.0 entro il 20 aprile 2015. Gli spazi dei nomi ACS continueranno a funzionare con l'implementazione openID 2.0 di Google fino al 1° giugno 2015, entro il quale è necessario completare la migrazione di questi spazi dei nomi per usare l'implementazione di OpenID Connect di Google o gli utenti non potranno più accedere all'applicazione con un account Google. La migrazione degli spazi dei nomi ACS a OpenID Connect non causerà tempi di inattività dell'applicazione. Con un'eccezione (vedere la nota seguente), questa migrazione è possibile senza modificare il codice dell'applicazione. Dopo aver migrato gli spazi dei nomi ACS per usare OpenID Connect, sarà necessario eseguire la migrazione degli identificatori degli utenti nel back-end agli identificatori OpenID Connect. Questa migrazione deve essere completata entro il 1° gennaio 2017. Richiederà modifiche al codice nel back-end. Per informazioni dettagliate su entrambe le fasi della migrazione, vedere la nota importante riportata di seguito.

Importante

Prendere nota delle date importanti seguenti e completare le azioni richieste da ogni data per assicurarsi che gli spazi dei nomi ACS che usano Google come provider di identità continuino a funzionare:

1 giugno 2015 - Gli spazi dei nomi ACS smetteranno di lavorare con l'implementazione openID 2.0 di Google. È necessario completare la migrazione dello spazio dei nomi ACS per usare Google OpenID Connect entro questa data. Prima di questa data, è possibile eseguire il rollback a OpenID 2.0 se si verificano problemi durante la migrazione. Per gli spazi dei nomi che non sono stati migrati da questa data, gli utenti non potranno più accedere con un account Google e verranno visualizzati una pagina che indica che OpenID 2.0 per gli account Google è scomparso. Per ripristinare la funzionalità di accesso con gli account Google, è necessario eseguire la migrazione dello spazio dei nomi.

Nella maggior parte dei casi, non è necessario apportare modifiche al codice dell'applicazione. Se si dispone della regola "pass-through di tutte le attestazioni" per Google come provider di identità in un gruppo di regole associato all'applicazione, potrebbe tuttavia essere necessario apportare modifiche al codice. Questo perché, al momento della migrazione, un nuovo tipo di attestazione (Oggetto) diventa disponibile per ACS da Google e potrebbe essere necessario apportare modifiche al codice per garantire che l'applicazione possa gestire correttamente la presenza del nuovo tipo di attestazione. Per completare correttamente la migrazione, non sarà necessario elaborare il nuovo tipo di attestazione nell'applicazione.
1 gennaio 2017 : le implementazioni openID 2.0 e OpenID Connect di Google usano identificatori diversi per identificare in modo univoco gli utenti di Google. Quando si esegue la migrazione dello spazio dei nomi ACS, ACS crea due identificatori, sia l'identificatore OpenID 2.0 corrente che il nuovo identificatore OpenID Connect, disponibili per l'applicazione. È necessario passare gli identificatori degli utenti nel sistema back-end agli identificatori OpenID Connect entro questa data e iniziare a usare solo gli identificatori OpenID Connect in futuro. Ciò richiede modifiche al codice dell'applicazione.

È possibile pubblicare domande sulla migrazione su Stack Overflow e contrassegnarle con "acs-google". Risponderemo il più rapidamente possibile.

Per altre informazioni sui piani di Google, vedere Guida alla migrazione di OpenID 2.0.

Elenco di controllo per la migrazione

La tabella seguente contiene un elenco di controllo che riepiloga i passaggi necessari per eseguire la migrazione dello spazio dei nomi ACS per usare l'implementazione di OpenID Connect di Google:

Passo	Descrizione	Deve essere completato da
1	Creare un'applicazione Google+ nella Google Developers Console.	1 giugno 2015
2	Se si dispone della regola "pass-through di tutte le attestazioni" per Google come provider di identità in un gruppo di regole associato all'applicazione, testare l'applicazione per assicurarsi che sia pronta per la migrazione; in caso contrario, questo passaggio è facoltativo.	1 giugno 2015
3	Usare il portale di gestione ACS per cambiare lo spazio dei nomi ACS per usare l'implementazione di Google OpenID Connect fornendolo con i parametri dell'applicazione Google+ (ID client e segreto client). Se si verificano problemi con la migrazione, è possibile eseguire il rollback a OpenID 2.0 fino al 1° giugno 2015.	1 giugno 2015
4	Eseguire la migrazione degli identificatori degli utenti nel sistema back-end dagli identificatori Google OpenID 2.0 correnti ai nuovi identificatori google OpenID Connect. Ciò richiede modifiche al codice.	1 gennaio 2017

Procedura dettagliata per la migrazione

Per eseguire la migrazione dello spazio dei nomi ACS per usare l'implementazione di OpenID Connect di Google, seguire questa procedura:

Creare un'applicazione Google+

Per istruzioni dettagliate su come eseguire questa operazione, vedere la sezione Procedura: Creare un'applicazione Google+.
Assicurarsi che l'applicazione sia pronta per la migrazione

Se si dispone della regola "pass-through di tutte le attestazioni" per Google come provider di identità in un gruppo di regole associato all'applicazione, seguire le istruzioni riportate nella sezione Procedura: Assicurarsi che la conformità alla migrazione di un'applicazione ACS per testare l'applicazione per la conformità alla migrazione. Ciò è dovuto al fatto che al momento della migrazione un nuovo tipo di attestazione (Subject) diventa disponibile per ACS da Google.

Nota

Una regola "pass-through tutte le attestazioni" è una regola in cui tipo di attestazione di input e valore attestazione di input sono impostati su Qualsiasi e tipo di attestazione output e valore attestazione di output sono impostati rispettivamente su tipo di attestazione pass-through e valore attestazione di input pass-through. La regola è elencata nel portale di gestione ACS, come illustrato di seguito, con la colonna attestazione di output impostata su pass-through.

Se in precedenza sono state generate regole o sono state aggiunte manualmente regole per Google come provider di identità in un gruppo di regole associato all'applicazione, è possibile ignorare questo passaggio. Ciò è dovuto al fatto che, in questi casi, al momento della migrazione, il nuovo tipo di attestazione soggetto non viene inviato all'applicazione.

Per altre informazioni su queste opzioni, vedere Gruppi di regole e regole.
Cambiare lo spazio dei nomi ACS per usare l'implementazione di OpenID Connect di Google
1. Passare al portale di gestione di Microsoft Azure , accedere e fare clic su Active Directory. Selezionare lo spazio dei nomi ACS di cui eseguire la migrazione e fare clic su Gestisci per avviare il portale di gestione ACS .
2. Nel portale di gestione ACS fare clic su Provider di identità nell'albero a sinistra oppure fare clic sul collegamento provider di identità nella sezione Introduzione. Fare clic su Google.
3. Nella pagina Modifica provider di identità Google selezionare Usa OpenID Connect.
4. Nei campi ID client e segreto client (ora abilitato), copiare i valori corrispondenti dall'applicazione Google+.
  
  Nota
  
  A questo punto, se si fa clic su Salva, tutte le richieste del provider di identità Google dallo spazio dei nomi ACS useranno automaticamente l'implementazione di Google OpenID Connect. Se è necessario eseguire il rollback, è possibile deselezionare Usare OpenID Connect. L'ID client e il segreto client rimangono salvati e possono essere riutilizzati in un secondo momento.
5. Fare clic su Salva.
6. Provare ad accedere con un ID Google per assicurarsi che il passaggio all'uso di OpenID Connect sia riuscito. Se si verificano problemi di accesso, tornare alla pagina di Modifica provider di identità Google e deselezionare Usare OpenID Connect per eseguire il rollback a OpenID 2.0. Dopo aver eseguito il rollback, verificare che l'ID client e segreto copiato dall'Google Developer Console siano immessi correttamente per lo spazio dei nomi; ad esempio, verificare la presenza di errori di digitazioni.
Eseguire la migrazione degli identificatori degli utenti nel sistema back-end da Open ID 2.0 a OpenID Connect

È necessario eseguire la migrazione degli identificatori degli utenti nel sistema back-end dagli identificatori google Open ID 2.0 esistenti ai nuovi identificatori google OpenID Connect prima del 1° gennaio 2017. Questo passaggio richiede modifiche al codice. Per altre informazioni, vedere Procedura: Eseguire la migrazione degli identificatori Open ID 2.0 esistenti degli utenti ai nuovi identificatori utente openID Connect

Procedura: Creare un'applicazione Google+

Avrai bisogno di un account Google per eseguire i passaggi seguenti; se non è disponibile, è possibile ottenerlo in https://accounts.google.com/SignUp.

In una finestra del browser passare alla Google Developers Console e accedere con le credenziali dell'account Google.
Fare clic su Crea progettoe immettere un nome progetto e ID progetto. Selezionare la casella di controllo Condizioni per il servizio. Fare quindi clic su Crea. In questo modo l'applicazione viene registrata con Google.
Fare clic su API & di autenticazione nel riquadro sinistro. Fare clic su Credenziali. In OAuthfare clic su Crea nuovo ID client. Selezionare applicazione Web e fare clic su schermata Configura consenso. Specificare un nome prodotto e fare clic su Salva.
Fare clic su API & di autenticazione nel riquadro sinistro. Quindi fare clic su API . In Sfoglia APIcercare e trovare API Google+. Impostare il stato di su ON.
Nella finestra di dialogo Crea ID client selezionare applicazione Web come tipo di applicazione.

Nel campo Origini JavaScript autorizzate specificare l'URL del nome di dominio completo (FQDN) dello spazio dei nomi, incluso il "HTTPS://" iniziale e il numero di porta finale; ad esempio, https://contoso.accesscontrol.windows.net:443.

Nel campo URL di reindirizzamento autorizzati specificare un URI che contiene l'URL del nome di dominio completo (FQDN) dello spazio dei nomi, inclusi il "HTTPS://" iniziale e il numero di porta finale, seguito da "/v2/openid"; ad esempio, https://contoso.accesscontrol.windows.net:443/v2/openid.

Fare clic su Crea ID client.
Prendere nota dei valori di ID client e segreto client dalla pagina ID client per l'applicazione Web. Saranno necessari per configurare l'implementazione di OpenID Connect di Google nel portale di gestione di ACS .

Importante

segreto client è una credenziale di sicurezza importante. Mantieni il segreto.

Procedura: Eseguire la migrazione degli identificatori Open ID 2.0 esistenti degli utenti ai nuovi identificatori utente openID Connect

Dopo aver eseguito la migrazione dello spazio dei nomi ACS per usare l'implementazione di OpenID Connect di Google, è necessario fino al 1° gennaio 2017 (per ogni OpenID 2.0 Migration Guide) per eseguire la migrazione degli identificatori degli utenti nel sistema back-end dagli identificatori OpenID 2.0 correnti ai nuovi identificatori OpenID Connect.

La tabella seguente mostra i tipi di attestazione che diventano disponibili per ACS da Google dopo la migrazione dello spazio dei nomi ACS per usare l'implementazione openID Connect di Google:

Tipo di attestazione	URI	Descrizione	Disponibilità del protocollo
Identificatore del nome	https://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier	Identificatore univoco per l'account utente, fornito da Google. Si tratta dell'identificatore OpenID 2.0 (esistente).	OpenID 2.0, OpenID Connect
Oggetto	https://schemas.microsoft.com/identity/claims/subject	Identificatore univoco per l'account utente, fornito da Google. Si tratta dell'identificatore OpenID Connect (nuovo).	OpenID Connect
Nome	https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name	Nome visualizzato per l'account utente, fornito da Google.	OpenID 2.0, OpenID Connect (vedere la nota seguente)
Indirizzo email	https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress	Indirizzo di posta elettronica per l'account utente, fornito da Google	OpenID 2.0, OpenID Connect
Provider di identità	https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/IdentityProvider	Attestazione fornita da ACS che indica all'applicazione relying party che l'utente ha autenticato usando il provider di identità Google predefinito. Il valore di questa attestazione è visibile nel portale di gestione ACS tramite il campo Area di autenticazione nella pagina Modifica provider di identità.	OpenID 2.0, OpenID Connect

Nota

Per un utente Google che non ha un profilo Google+ registrato, il valore del tipo di attestazione nome corrisponde al valore dell'indirizzo di posta elettronica tipo di attestazione in OpenID Connect.

I tipi di attestazione Identificatore nome e soggetto possono essere usati per tenere traccia e cambiare gli identificatori univoci degli utenti esistenti nel back-end eseguendo il mapping (precedente) degli identificatori OpenID 2.0 a (nuovo) identificatori OpenID Connect.

Se si dispone della regola "pass-through di tutte le attestazioni" per Google come provider di identità in un gruppo di regole associato all'applicazione, l'applicazione inizierà automaticamente a ricevere il tipo di attestazione Soggetto.

Se in precedenza sono state generate regole o sono state aggiunte manualmente regole per Google come provider di identità in un gruppo di regole associato all'applicazione, sarà necessario aggiungere manualmente il tipo di attestazione Soggetto. Per altre informazioni su come eseguire questa operazione, vedere Regole e gruppi di regole.

configurazione attestazione di input

Ad esempio, se in precedenza sono state generate regole per Google come provider di identità in un gruppo di regole e quindi aggiungere il nuovo tipo di attestazione Subject (come illustrato in precedenza), si noterà quanto segue.

attestazioni pass-through google

L'applicazione che usa questo gruppo di regole riceverà il tipo di attestazione Subject insieme ad altri tipi di attestazione.

Nota

Dopo il 1° gennaio 2017, quando Google interrompe il supporto per il mapping degli identificatori, ACS popola entrambi i NameIdentifier e tipi di attestazione Subject con lo stesso identificatore utente OpenID Connect.

Procedura: Assicurarsi che l'idoneità per la migrazione di un'applicazione ACS

Con un'eccezione, la migrazione dello spazio dei nomi ACS per usare l'implementazione di OpenID Connect di Google è possibile senza modificare il codice dell'applicazione. Il caso di eccezione è se si dispone della regola "pass-through di tutte le attestazioni" per Google come provider di identità in un gruppo di regole associato all'applicazione. Questo perché, in questo caso, al momento della migrazione un nuovo tipo di attestazione (Subject) viene inviato automaticamente all'applicazione.

In questa sezione viene illustrata la procedura consigliata di modifica e test che è possibile seguire per assicurarsi che ogni applicazione interessata dalla migrazione sia pronta per gestire il nuovo tipo di attestazione.

Ai fini di questa procedura, si supponga di essere il proprietario di uno spazio dei nomi ACS denominato ns-contoso e che l'applicazione nell'ambiente di produzione venga chiamata ProdContosoApp. Si supponga inoltre che questa applicazione usi Google come provider di identità e abbia "pass-through tutte le attestazioni" regola abilitata per Google.

Apparecchio

Per iniziare, passare al portale di gestione di Microsoft Azure , accedere e quindi fare clic su Active Directory. Selezionare lo spazio dei nomi ACS (ns-contoso) e quindi fare clic su Gestisci per avviare il portale di gestione di ACS .
Nel portale di gestione di ACS fare clic su applicazioni relying party nell'albero a sinistra oppure fare clic sul collegamento Relying Party Applications (Applicazioni relying party) nella sezione Introduzione. Fare quindi clic sull'applicazione di produzione (ProdContosoApp).
Prendere nota delle proprietà di ProdContosoApp, saranno necessarie in un secondo momento.
Fare clic su gruppo di regole predefinito per ProdContosoApp in gruppi di regole per verificare che abbia la regola "pass-through di tutte le attestazioni" abilitata per Google.

attestazione pass-through google

Passaggio 1: Configurare un'istanza di test dell'applicazione nello spazio dei nomi ACS di produzione

Configurare un'istanza di test dell'applicazione, TestContosoApp, in un URI radice diverso; ad esempio, https://contoso-test.com:7777/. Sarà necessario registrarlo come applicazione relying party (relying party applications) nello spazio dei nomi ns-contoso.

Nel portale di gestione di ACS fare clic su applicazioni relying party nell'albero a sinistra oppure fare clic sul collegamento Relying Party Applications (Applicazioni relying party) nella sezione Introduzione. Fare quindi clic su Aggiungi nella pagina Relying Party Applications.
Nella pagina Aggiungi applicazione relying partying eseguire le operazioni seguenti:
- In Nomedigitare il nome dell'applicazione di test. Ecco TestContosoApp.
- In modalità selezionare Immettere le impostazioni manualmente.
- In Realmdigitare l'URI dell'applicazione di test. Qui è https://contoso-test.com:7777/.
- Ai fini di questa procedura, è possibile lasciare URL errore (facoltativo) vuoto.
- Per il formato token , i criteri di crittografia token e durata del token (secs) e la sezione impostazioni di firma del token di , usare gli stessi valori usati per ProdContosoApp.
- Assicurarsi di aver selezionato Google come provider di identità .
- In gruppi di regoleselezionare Crea nuovo gruppo di regole.
Fare clic Salva nella parte inferiore della pagina.

Passaggio 2: Creare un gruppo di regole che simula il formato del token ACS che l'applicazione riceverà dopo la migrazione dello spazio dei nomi per usare l'implementazione di OpenID Connect di Google

Nel portale di gestione ACS fare clic su gruppi di regole nell'albero a sinistra oppure fare clic sul collegamento gruppo regole nella sezione Introduzione. Fare quindi clic su Aggiungi nella pagina gruppi di regole di .
Nella pagina Aggiungi gruppo di regole specificare un nome per il nuovo gruppo di regole, ad esempio ManualGoogleRuleGroup. Fare clic su Salva.
Nella pagina Modifica gruppo di regole fare clic sul collegamento aggiungi .
Nella pagina Aggiungi regola attestazione assicurarsi di disporre dei valori seguenti e fare clic su Salva. In questo modo viene generata una regola "pass-through per tutte le attestazioni" per Google.
- sezione If:
  - provider di identità è Google.
  - tipo di attestazione di input selezione è Qualsiasi.
  - valore attestazione di input è Qualsiasi.
- sezione Then:
  - tipo di attestazione output è tipo di attestazione Pass-through first.
  - valore attestazione di output è valore dell'attestazione pass-through first input.
- sezione informazioni sulle regole:
  - Lasciare vuoto il campo Descrizione (facoltativo).
Nella pagina Modifica gruppo di regole fare di nuovo clic sul collegamento aggiungi .
Nella pagina Aggiungi regola attestazione verificare che siano presenti i valori seguenti e fare clic su Salva. Viene generata una regola attestazione "statica" per Google che simula l'aggiunta di un nuovo tipo di attestazione, Subject, che è il nuovo identificatore OpenID Connect dell'utente che Google invia l'applicazione al momento della migrazione.
- sezione If:
  - provider di identità è Google.
  - tipo di attestazione di input selezione è Qualsiasi.
  - valore attestazione di input è Qualsiasi.
- sezione Then:
  - tipo di attestazione di output è tipo Enter. Nel campo digitare https://schemas.microsoft.com/identity/claims/subject.
  - valore dell'attestazione di output è valore Enter. Nel campo digitare 123456.
- sezione informazioni sulle regole:
  - Lasciare vuoto il campo Descrizione (facoltativo).
Fare clic Salva nella pagina modifica gruppo di regole .

Passaggio 3: Associare il nuovo gruppo di regole all'istanza di test dell'applicazione

Nel portale di gestione di ACS fare clic su applicazioni relying party nell'albero a sinistra oppure fare clic sul collegamento Relying Party Applications (Applicazioni relying party) nella sezione Introduzione. Fare quindi clic su TestContosoApp nella pagina Relying Party Applications.
Nella pagina Modifica relying party selezionare ManualGoogleRuleGroup nella sezione Authentication Settings e fare clic su Save.

impostazioni di autenticazione di

A questo punto, tutte le richieste di accesso di Google alle applicazioni di test includeranno il nuovo tipo di attestazione.

Passaggio 4: Testare per assicurarsi che l'applicazione possa gestire l'aggiunta del tipo di attestazione Soggetto

Testare l'applicazione per assicurarsi che possa gestire correttamente la presenza del nuovo tipo di attestazione (Subject). In genere, un'applicazione ben scritta deve essere affidabile per i nuovi tipi di attestazione aggiunti al token. Trovare e risolvere eventuali problemi. Facoltativamente, è anche possibile seguire la sezione Procedura: Eseguire la migrazione degli identificatori Open ID 2.0 esistenti degli utenti alla nuova sezione Identificatori utente OpenID Connect per eseguire il mapping degli identificatori utente.

Passaggio 5: Eseguire la migrazione dell'ambiente di produzione

Ripetere la compilazione e la distribuzione dell'applicazione di produzione (ProdContosoApp). Eseguire la migrazione dello spazio dei nomi (ns-contoso) per usare l'implementazione di OpenID Connect di Google seguendo la procedura descritta nella procedura dettagliata sulla migrazione. Verificare che ProdContosoApp funzioni come previsto.

Condividi tramite