Migration d'espaces de noms ACS vers Google OpenID Connect

Article
11/09/2015

Cette rubrique s'adresse aux propriétaires d'espaces de noms ACS 2.0 qui utilisent Google comme fournisseur d'identité. Le Service de contrôle d'accès offre cette capacité en utilisant l'implémentation OpenID 2.0 de Google. Google prévoit d’interrompre le support OpenID 2.0 avant le 20 avril 2015. Les espaces de noms ACS continueront de fonctionner avec l’implémentation OpenID 2.0 de Google jusqu’au 1er juin 2015, au moment où vous devez effectuer la migration de ces espaces de noms pour utiliser l’implémentation OpenID de Google Connecter ou les utilisateurs ne pourront plus se connecter à votre application avec un compte Google. La migration de vos espaces de noms ACS vers OpenID Connect n'entraînera aucun temps mort de l'application. Cette migration est possible sans modifier le code d'application, à une seule exception indiquée dans la remarque ci-dessous. Après avoir migré vos espaces de noms ACS vers OpenID Connect, vous devez migrer les identificateurs de vos utilisateurs sur votre serveur principal vers des identificateurs OpenID Connect. Cette migration doit être effectuée d’ici le 1er janvier 2017. Il nécessite des modifications de code dans votre back-end. Voir la remarque importante ci-dessous pour plus d'informations sur les deux phases de migration.

Important

Notez les dates importantes suivantes et effectuez les actions requises pour chaque date afin de vous assurer que vos espaces de noms ACS qui utilisent Google comme fournisseur d'identité continuent de fonctionner :

1er juin 2015 - les espaces de noms ACS cesseront de fonctionner avec l'implémentation OpenID 2.0 de Google. Vous devrez avoir effectué la migration des espaces de noms ACS vers OpenID Connect à cette date. Avant cette date, vous pouvez revenir à OpenID 2.0 si vous rencontrez des problèmes lors de la migration. Pour les espaces de noms qui n’ont pas été migrés à cette date, les utilisateurs ne pourront plus se connecter avec un compte Google et seront présentés avec une page qui indique qu’OpenID 2.0 pour les comptes Google a disparu. Pour restaurer la fonctionnalité de connexion avec des comptes Google, vous devez migrer l’espace de noms.

Aucune modification du code d'application n'est généralement requise. Néanmoins, si un groupe de règles associé à votre application contient la règle « transférer toutes les revendications » pour Google comme fournisseur d'identité, vous devrez peut-être apporter des modifications de code. En effet, pendant la migration, un nouveau type de revendication (Objet) fourni par Google devient disponible pour le Service de contrôle d'accès. Vous devrez peut-être apporter des modifications de code pour vous assurer que votre application peut gérer correctement la présence de ce nouveau type de revendication. Il ne sera pas nécessaire de traiter le nouveau type de revendication dans votre application pour réussir la migration.
1er janvier 2017 – les implémentations OpenID 2.0 et OpenID Connect de Google utilisent des identificateurs différents pour identifier de manière unique les utilisateurs Google. Lorsque vous migrez votre espace de noms ACS, le Service de contrôle d'accès met à disposition de votre application deux identificateurs (l'identificateur OpenID 2.0 actuel et le nouvel identificateur OpenID Connect). Vous devez basculer les identificateurs de vos utilisateurs sur votre système principal vers les identificateurs OpenID Connect avant cette date, puis ne plus utiliser que les identificateurs OpenID Connect. Cela nécessite des modifications du code d'application.

Vous pouvez publier des questions sur la migration sur Stack Overflow et les étiqueter avec « acs-google ». Nous répondrons aussi rapidement que possible.

Pour plus d’informations sur les plans de Google, consultez leur Guide de migration OpenID 2.0.

Liste de vérification de migration

Le tableau suivant contient une liste de vérification qui résume les étapes nécessaires afin de migrer votre espace de noms ACS vers l'implémentation OpenID Connect de Google :

Étape	Description	Doit être réalisé pour le
1	Créer une application Google+ sur la console des développeurs Google.	1er juin 2015
2	Si un groupe de règles associé à votre application contient la règle « transférer toutes les revendications » pour Google comme fournisseur d'identité, testez votre application afin de vérifier qu'elle est prête pour la migration ; sinon, cette étape est facultative.	1er juin 2015
3	Utilisez le portail de gestion ACS pour basculer votre espace de noms ACS vers l'implémentation OpenID Connect de Google en indiquant les paramètres de votre application Google + (Identifiant client et Code secret du client). Si vous rencontrez des problèmes avec votre migration, il est possible de restaurer OpenID 2.0 jusqu'au 1er juin 2015.	1er juin 2015
4	Migrez les identificateurs Google OpenID 2.0 actuels de vos utilisateurs sur votre système principal vers les nouveaux identificateurs Google OpenID Connect. Cela nécessite des modifications de code.	1er janvier 2017

Procédure détaillée de migration

Pour migrer votre espace de noms ACS vers l'implémentation OpenID Connect de Google, procédez comme suit :

Créer une application Google+

Pour obtenir des instructions détaillées sur la procédure à suivre, consultez la section How to: Create a Google+ application.
Assurez-vous que votre application est prête pour la migration

Si vous disposez de la règle « passthrough all claims » pour Google en tant que fournisseur d’identité dans un groupe de règles associé à votre application, suivez les instructions de la section How to: Ensure an ACS application’s migration readiness section to test your application for migration readiness. En effet, pendant la migration, un nouveau type de revendication (Objet) fourni par Google devient disponible pour le Service de contrôle d'accès.

Notes

Une règle « passthrough all claims » est une règle dans laquelle le type de revendication d’entrée et la valeur de revendication d’entrée sont définis sur Any et Output claim type et Output claim value sont définis sur Pass through first input claim type et Pass through input claim value respectivement. Cette règle est répertoriée dans le portail de gestion ACS comme illustré ci-dessous. La colonne Revendication de sortie a la valeur Transfert.

Si vous avez déjà généré des règles ou ajouté des règles manuellement pour Google comme fournisseur d'identité dans un groupe de règles associé à votre application, vous pouvez ignorer cette étape. En effet, dans ces cas précis, le nouveau type de revendication Objet n'est pas envoyé à l'application lors de la migration.

Pour en savoir plus sur ces options, consultez Groupes de règles et Règles.
Basculez l'espace de noms ACS vers l'implémentation OpenID Connect de Google
1. Accédez au Portail de gestion Microsoft Azure, ouvrez une session, puis cliquez sur Active Directory. Sélectionnez l'espace de noms ACS à migrer, puis cliquez sur Gérer pour lancer le portail de gestion ACS.
2. Dans le portail de gestion ACS, cliquez sur Fournisseurs d'identité dans l'arborescence située sur la gauche, ou cliquez sur le lien Fournisseurs d'identité dans la section Mise en route. Cliquez sur Google.
3. Dans la page Modifier le fournisseur d'identité Google, cochez la case Utiliser OpenID Connect.
4. Dans les champs Identifiant du client et Code secret du client (désormais activés), copiez les valeurs correspondantes depuis votre application Google+.
  
  Notes
  
  À ce stade, si vous cliquez sur Enregistrer, toutes les demandes de fournisseur d'identité Google émanant de votre espace de noms ACS utiliseront automatiquement l'implémentation OpenID Connect de Google. Si vous souhaitez effectuer une restauration, vous pouvez décocher la case Utiliser OpenID Connect. L'Identifiant du client et le Code secret du client restent enregistrés et pourront être réutilisés plus tard.
5. Cliquez sur Enregistrer.
6. Essayez de vous connecter avec un ID Google pour vérifier que le basculement vers OpenID Connect a réussi. Si vous ne parvenez pas à vous connecter, revenez à la page Modifier le fournisseur d'identité Google et décochez la case Utiliser OpenID Connect pour restaurer OpenID 2.0. Après la restauration, vérifiez que l'Identifiant du client et le Code secret du client que vous avez copiés à partir de la Console des développeurs Google sont corrects pour votre espace de noms. Recherchez par exemple les fautes de frappe.
Migrez les identificateurs OpenID 2.0 de vos utilisateurs sur votre système principal vers OpenID Connect.

Vous devez migrer les identificateurs de vos utilisateurs dans votre système principal à partir des identificateurs Google Open ID 2.0 existants vers les nouveaux identificateurs Google OpenID Connecter avant le 1er janvier 2017. Cette étape nécessite des modifications de code. Pour plus d’informations, consultez Guide pratique pour migrer les identificateurs Open ID 2.0 existants de vos utilisateurs vers de nouveaux identificateurs d’utilisateur OpenID Connecter

Guide pratique pour créer une application Google+

Vous aurez besoin d’un compte Google pour effectuer les étapes suivantes ; si vous n’en avez pas, vous pouvez en obtenir un à https://accounts.google.com/SignUp.

Dans une fenêtre de navigateur, accédez à google Developers Console et connectez-vous avec vos informations d’identification de compte Google.
Cliquez sur Créer un projet, puis entrez le Nom du projet et l'Identifiant du projet. Cochez la case Conditions d'utilisation. Ensuite, cliquez sur Créer. L'application est alors enregistrée auprès de Google.
Cliquez sur l’authentification des & API dans le volet gauche. Cliquez ensuite sur Identifiants. Sous OAuth, cliquez sur Créer un identifiant client. Sélectionnez Application Web, puis cliquez sur Configurer l'écran d'autorisation. Indiquez le Nom du produit, puis cliquez sur Enregistrer.
Cliquez sur l’authentification des & API dans le volet gauche. Cliquez ensuite sur API. Sous Parcourir les interfaces API, recherchez Google+ API. Attribuez à l'État la valeur Activé.
Dans la boîte de dialogue Créer un identifiant client, sélectionnez Application Web comme Type d'application.

Dans le champ Origines Javascript autorisées , spécifiez l’URL de nom de domaine complet (FQDN) de votre espace de noms, y compris le « HTTPS:// » de début et le numéro de port de fin ; par exemple, https://contoso.accesscontrol.windows.net:443.

Dans le champ URI de redirection autorisé , spécifiez un URI qui contient l’URL de nom de domaine complet (FQDN) de votre espace de noms, y compris le « HTTPS:// » de début et le numéro de port de fin, suivi de « /v2/openid » ; par exemple, https://contoso.accesscontrol.windows.net:443/v2/openid.

Cliquez sur Créer un identifiant client.
Notez les valeurs de Identifiant client et Code secret du client sur la page Identifiant client de l'application Web. Vous en aurez besoin pour configurer l'implémentation OpenID Connect de Google sur le portail de gestion ACS.

Important

Client Secret est une information d’identification de sécurité importante. Ne le divulguez pas.

Guide pratique pour migrer les identificateurs Open ID 2.0 existants de vos utilisateurs vers de nouveaux identificateurs d’utilisateur OpenID Connecter

Une fois que vous avez correctement migré votre espace de noms ACS pour utiliser l’implémentation d’OpenID de Google Connecter, vous avez jusqu’au 1er janvier 2017 (conformément au Guide de migration OpenID 2.0 de Google) pour migrer les identificateurs de vos utilisateurs dans votre système principal à partir des identificateurs OpenID 2.0 actuels vers les nouveaux identificateurs OpenID Connecter.

Le tableau suivant présente les types de revendications fournis par Google qui deviennent disponibles pour le Service de contrôle d'accès une fois l'espace de noms ACS migré vers l'implémentation OpenID Connect de Google :

Type de revendication	URI	Description	Disponibilité de protocole
Identificateur de nom	https://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier	Identificateur unique pour le compte d'utilisateur, fourni par Google. Il s'agit de l'identificateur OpenID 2.0 (existant).	OpenID 2.0, OpenID Connect
Objet	https://schemas.microsoft.com/identity/claims/subject	Identificateur unique pour le compte d'utilisateur, fourni par Google. Il s'agit du (nouvel) identificateur OpenID Connect.	OpenID Connect
Nom	https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name	Nom complet du compte d'utilisateur, fourni par Google.	OpenID 2.0, OpenID Connect (voir la remarque ci-dessous)
Adresse de messagerie	https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress	Adresse de messagerie du compte d'utilisateur, fournie par Google.	OpenID 2.0, OpenID Connect
Fournisseur d’identité	https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/IdentityProvider	Revendication fournie par le Service de contrôle d'accès qui indique à l'application par partie de confiance que l'utilisateur s'est authentifié à l'aide du fournisseur d'identité Google par défaut. La valeur de cette revendication est visible dans le portail de gestion ACS, dans le champ Domaine de la page Modifier le fournisseur d'identité.	OpenID 2.0, OpenID Connect

Notes

Pour un utilisateur de Google n'ayant pas de profil Google + (enregistré), la valeur du type de revendication Nom est identique à la valeur du type de revendication Adresse de messagerie dans OpenID Connect.

Les types de revendication Identificateur de nom et Objet peuvent être utilisés pour suivre et basculer les identificateurs uniques des utilisateurs existants sur votre système principal en mappant les (anciens) identificateurs OpenID 2.0 aux (nouveaux) identificateurs OpenID Connect.

Si un groupe de règles associé à votre application contient la règle « transférer toutes les revendications » pour Google comme fournisseur d'identité, votre application commencera automatiquement à recevoir le type de revendication Objet.

Si vous avez déjà généré des règles ou ajouté des règles manuellement pour Google comme fournisseur d'identité dans un groupe de règles associé à votre application, vous devrez ajouter le type de revendication Objet manuellement. Pour plus d’informations sur la procédure à suivre, consultez Groupes de règles et Règles.

Input Claim Configuration

Par exemple, si vous avez déjà généré des règles pour Google comme fournisseur d'identité dans un groupe de règles, puis ajoutez le nouveau type de revendication Objet (comme indiqué ci-dessus), vous verrez les éléments suivants.

Google passthrough claims

L'application utilisant ce groupe de règles recevra le type de revendication Objet, ainsi que d'autres types de revendication.

Notes

Après le 1er janvier 2017, lorsque Google arrêtera la prise en charge du mappage des identificateurs, le Service de contrôle d'accès utilisera le même identificateur d'utilisateur OpenID Connect pour renseigner les types de revendications Identificateur de nom et Objet.

Guide pratique pour garantir la préparation de la migration d’une application ACS

La migration de votre espace de noms ACS vers l'implémentation OpenID Connect de Google est possible sans modification du code d'application, à une exception près : quand le groupe de règles associé à une application contient la règle « transférer toutes les revendications » pour Google comme fournisseur d'identité. En effet, dans ce cas, un nouveau type de revendication (Objet) est envoyé automatiquement à l'application lors de la migration.

Cette section décrit la procédure de modification et de test recommandée que vous pouvez suivre pour vous assurer que toutes les applications qui seront affectées par la migration sont prêtes à gérer le nouveau type de revendication.

Dans le cadre de cette procédure, supposons que vous êtes propriétaire d'un espace de noms ACS appelé ns-contoso et que votre application en production est nommée ProdContosoApp. Supposons également que cette application utilise Google comme fournisseur d'identité et que la règle « transférer toutes les revendications » est activée pour Google.

Programme d’installation

Pour commencer, accédez au Portail de gestion Microsoft Azure, ouvrez une session, puis cliquez sur Active Directory. Sélectionnez l'espace de noms ACS (ns-contoso), puis cliquez sur Gérer pour lancer le portail de gestion ACS.
Dans le portail de gestion ACS, cliquez sur Applications par partie de confiance dans l'arborescence située sur la gauche, ou sur le lien Applications par partie de confiance situé sous la section Mise en route. Cliquez ensuite sur votre application de production (ProdContosoApp).
Notez les propriétés de ProdContosoApp, vous en aurez besoin ultérieurement.
Cliquez sur Groupe de règles par défaut pour ProdContosoApp sous Groupes de règles pour vérifier que la règle « transférer toutes les revendications » est activée pour Google.

Étape 1 : Configurer une instance de test de votre application dans votre espace de noms ACS de production

Configurez une instance de test de votre application, TestContosoApp, sur un URI racine différent ; par exemple, https://contoso-test.com:7777/. Vous devrez l’inscrire en tant qu’application de partie de confiance (applications de partie de confiance) dans l’espace de noms ns-contoso.

Dans le portail de gestion ACS, cliquez sur Applications par partie de confiance dans l'arborescence située sur la gauche, ou sur le lien Applications par partie de confiance situé sous la section Mise en route. Cliquez ensuite sur Ajouter dans la page Applications par partie de confiance.
Dans la page Ajouter une application par partie de confiance, procédez comme suit :
- Dans la zone Nom, tapez le nom de l'application de test. Il s'agit ici de TestContosoApp.
- Dans la zone Mode, sélectionnez Entrer les paramètres manuellement.
- Dans la zone Domaine, tapez l'URI de l'application de test. Ici, c’est https://contoso-test.com:7777/.
- Dans le cadre de cette procédure, vous pouvez laisser la zone URL d'erreur (facultative) vide.
- Pour les propriétés Format du jeton, Stratégie de chiffrement de jeton et Durée de vie du jeton (en secondes), ainsi que pour la section Paramètres de signature du jeton, utilisez les mêmes valeurs que pour ProdContosoApp.
- Assurez-vous que vous avez sélectionné Google comme Fournisseur d'identité.
- Sous Groupes de règles, sélectionnez Créer un groupe de règles.
Cliquez sur Enregistrer au bas de la page.

Étape 2 : Créer un groupe de règles qui simule le format du jeton ACS que l’application recevra une fois l’espace de noms migré pour utiliser l’implémentation d’OpenID de Google Connecter

Dans le portail de gestion ACS, cliquez sur Groupes de règles dans l'arborescence située sur la gauche, ou cliquez sur le lien Groupe de règles dans la section Mise en route. Cliquez ensuite sur Ajouter dans la page Groupes de règles.
Dans la page Ajouter un groupe de règles, indiquez le nom du nouveau groupe de règles ; par exemple GroupeRèglesGoogleManuel. Cliquez sur Save (Enregistrer).
Dans la page Modifier un groupe de règles, cliquez sur le lien Ajouter.
Dans la page Ajouter une règle de revendication, assurez-vous que les valeurs suivantes sont indiquées, puis cliquez sur Enregistrer. Une règle « transférer toutes les revendications » est alors générée pour Google.
- Section Si :
  - Fournisseur d'identité a la valeur Google.
  - Type de revendication d'entrée a la valeur N'importe lequel.
  - Valeur de la revendication d'entrée a la valeur N'importe lequel.
- Section Alors :
  - Type de revendication de sortie a la valeur Transfert du type de la première revendication d'entrée.
  - Valeur de revendication de sortie a la valeur Transférer la valeur de la première revendication d'entrée.
- Section Informations de règle :
  - Laissez le champ Description (facultatif) vide.
Dans la page Modifier un groupe de règles, cliquez de nouveau sur le lien Ajouter.
Dans la page Ajouter une règle de revendication, vérifiez que les valeurs suivantes sont indiquées, puis cliquez sur Enregistrer. Une règle de revendication « statique » est alors générée pour Google qui simule l'ajout d'un nouveau type de revendication, Objet, qui est le nouvel identificateur d'utilisateur OpenID Connect que Google envoie à l'application lors de la migration.
- Section Si :
  - Fournisseur d'identité a la valeur Google.
  - Type de revendication d'entrée a la valeur N'importe lequel.
  - Valeur de la revendication d'entrée a la valeur N'importe lequel.
- Section Alors :
  - Type de revendication de sortie a la valeur Entrez le type. Dans le champ, tapez https://schemas.microsoft.com/identity/claims/subject.
  - Valeur de revendication de sortie a la valeur Entrez la valeur. Dans le champ, tapez 123456.
- Section Informations de règle :
  - Laissez le champ Description (facultatif) vide.
Cliquez sur Enregistrer sur la page Modifier un groupe de règles.

Étape 3 : Associer le nouveau groupe de règles à l’instance de test de l’application

Dans le portail de gestion ACS, cliquez sur Applications par partie de confiance dans l'arborescence située sur la gauche, ou sur le lien Applications par partie de confiance situé sous la section Mise en route. Cliquez ensuite sur TestContosoApp dans la page Applications par partie de confiance.
Dans la page Modifier une application par partie de confiance, sélectionnez GroupeRèglesGoogleManuel dans la section Paramètres d'authentification, puis cliquez sur Enregistrer.

À ce stade, tous les demandes de connexion Google à vos applications de test incluent le nouveau type de revendication.

Étape 4 : Tester pour vous assurer que votre application peut gérer l’ajout du type de revendication Subject

Testez votre application pour vous assurer qu'elle peut gérer correctement la présence du nouveau type de revendication (Objet). Une application bien écrite doit normalement résister à l'ajout de nouveaux types de revendications au jeton. Recherchez et corrigez les problèmes. Si vous le souhaitez, vous pouvez également suivre la procédure : migrer les identificateurs Open ID 2.0 existants de vos utilisateurs vers la nouvelle section OpenID Connecter identificateurs d’utilisateur pour effectuer le mappage des identificateurs utilisateur.

Étape 5 : Migrer votre environnement de production

Régénérez et déployez votre application de production (ProdContosoApp). Migrez l’espace de noms (ns-contoso) pour utiliser l’implémentation d’OpenID de Google Connecter en suivant les étapes décrites dans la procédure pas à pas de migration. Vérifiez que ProdContosoApp fonctionne comme prévu.

Partager via