Partager via


Migration d’espaces de noms ACS vers Google OpenID Connect

Cette rubrique concerne les propriétaires d’espaces de noms ACS (Access Control Service) 2.0 qui utilisent actuellement Google comme fournisseur d’identité. ACS fournit cette fonctionnalité à l’aide de l’implémentation OpenID 2.0 de Google. Google prévoit d’interrompre le support OpenID 2.0 d’ici le 20 avril 2015. Les espaces de noms ACS continueront de fonctionner avec l’implémentation d’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 Connect de Google 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îne pas le temps d’arrêt de l’application. À une exception près (voir la remarque ci-dessous), cette migration est possible sans modifier le code de l’application. Après avoir migré vos espaces de noms ACS pour utiliser OpenID Connect, vous devez migrer les identificateurs de vos utilisateurs dans votre back-end vers les identificateurs OpenID Connect. Cette migration doit être effectuée le 1er janvier 2017. Il nécessite des modifications de code dans votre back-end. Pour plus d’informations sur les deux phases de migration, consultez la note importante ci-dessous.

Important

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

  • 1er juin 2015 - Les espaces de noms ACS cesseront de travailler avec l’implémentation OpenID 2.0 de Google. Vous devez effectuer la migration de l’espace de noms ACS pour utiliser Google 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 que OpenID 2.0 pour les comptes Google a disparu. Pour restaurer la fonctionnalité de connexion avec les comptes Google, vous devez migrer l’espace de noms.

    Dans la plupart des cas, aucune modification du code d’application ne doit être nécessaire. Si vous avez la règle «passer toutes les revendications» pour Google en tant que fournisseur d’identité dans un groupe de règles associé à votre application, toutefois, vous devrez peut-être apporter des modifications de code. Cela est dû au fait que, lors de la migration, un nouveau type de revendication (Subject) devient disponible pour ACS à partir de Google, et vous devrez peut-être apporter des modifications de code pour vous assurer que votre application peut gérer la présence du nouveau type de revendication correctement. Pour terminer la migration, il n’est pas nécessaire de traiter le nouveau type de revendication dans votre application.

  • 1er janvier 2017 : les implémentations OpenID 2.0 et OpenID Connect de Google utilisent différents identificateurs pour identifier de manière unique les utilisateurs Google. Lorsque vous migrez votre espace de noms ACS, ACS effectue deux identificateurs, à la fois l’identificateur OpenID 2.0 actuel et le nouvel identificateur OpenID Connect, disponibles pour votre application. Vous devez basculer les identificateurs de vos utilisateurs dans votre système principal vers les identificateurs OpenID Connect à cette date et commencer à utiliser uniquement les identificateurs OpenID Connect à l’avenir. Cela nécessite des modifications de code d’application.

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

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

Liste de contrôle de migration

Le tableau suivant contient une liste de contrôle qui résume les étapes nécessaires à la migration de votre espace de noms ACS pour utiliser l’implémentation OpenID Connect de Google :

Pas Description Doit être terminé par

1

Créez une application Google+ à l'console Google Developers.

1er juin 2015

2

Si vous disposez de la règle «passez toutes les revendications» pour Google en tant que fournisseur d’identité dans un groupe de règles associé à votre application, testez votre application pour vous assurer qu’elle est prête pour la migration ; sinon, cette étape est facultative.

1er juin 2015

3

Utilisez le portail de gestion ACS pour changer votre espace de noms ACS pour utiliser l’implémentation OpenID Connect de Google en lui fournissant les paramètres de votre application Google+ (ID client et secret client). Si vous rencontrez des problèmes avec votre migration, la restauration vers OpenID 2.0 est possible jusqu’au 1er juin 2015.

1er juin 2015

4

Migrez les identificateurs de vos utilisateurs dans votre système principal à partir des identificateurs Google OpenID 2.0 actuels vers les nouveaux identificateurs Google OpenID Connect. Cela nécessite des modifications de code.

1er janvier 2017

Procédure pas à pas de migration

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

  1. Créer une application Google+

    Pour obtenir des instructions détaillées sur la procédure à suivre, consultez la section Guide pratique pour créer une application Google+.

  2. Vérifiez que votre application est prête pour la migration

    Si vous disposez de la règle «passer toutes les revendications» 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. Cela est dû au fait que lors de la migration, un nouveau type de revendication (Subject) devient disponible pour ACS à partir de Google.

    Note

    Une règle «passthrough all claims» est une règle où type de revendication d’entrée et valeur de revendication d’entrée sont définies sur Tout et Les et valeur de revendication sortie sont définies sur passer au premier type de revendication d’entrée et Valeur de revendication d’entrée respectivement. La règle est répertoriée sur le du portail de gestion ACS , comme indiqué ci-dessous, avec la colonne Revendication de sortie définie sur passthrough.

    règle pas à pas

    Si vous avez précédemment généré des règles ou ajouté des règles manuellement pour Google en tant que fournisseur d’identité dans un groupe de règles associé à votre application, vous pouvez ignorer cette étape. Cela est dû au fait que, dans ces cas, lors de la migration, le nouveau type de revendication Objet n’est pas envoyé à l’application.

    Pour en savoir plus sur ces options, consultez groupes de règles et règles.

  3. Changer l’espace de noms ACS pour utiliser l’implémentation OpenID Connect de Google

    1. Accédez audu portail de gestion Microsoft Azure , connectez-vous, 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 ledu portail de gestion ACS , cliquez sur fournisseurs d’identité dans l’arborescence sur le côté gauche ou cliquez sur le lien Identity Providers sous la section Prise en main. Cliquez sur Google.

      boîte de dialogue Access Control Service Identity Providers

    3. Dans la page Modifier le fournisseur d’identité Google, cochez Utiliser openID Connect.

      boîte de dialogue Modifier le fournisseur d’identité Google

    4. Dans les champs ID client et clé secrète client (désormais activé), copiez les valeurs correspondantes à partir de votre application Google+.

      boîte de dialogue Modifier le fournisseur d’identité Google

      Note

      À ce stade, si vous cliquez sur Enregistrer, toutes les demandes de fournisseur d’identité Google de votre espace de noms ACS utilisent automatiquement l’implémentation OpenID Connect de Google. Si vous avez besoin de restaurer, vous pouvez décocher Utiliser OpenID Connect. L’ID client et la clé secrète client restent enregistrés et peuvent être réutilisés ultérieurement.

    5. Cliquez sur Enregistrer.

    6. Essayez de vous connecter avec un ID Google pour vous assurer que le passage à l’utilisation d’OpenID Connect a réussi. Si vous ne parvenez pas à vous connecter, revenez à la page Modifier le fournisseur d’identité Google et décoché Utiliser openID Connect pour revenir à OpenID 2.0. Après la restauration, vérifiez que les d’ID client et Secret que vous avez copiés à partir de la console de développement Google sont correctement entrés pour votre espace de noms ; par exemple, vérifiez les fautes de frappe.

  4. migrer les identificateurs de vos utilisateurs dans votre système principal depuis Open ID 2.0 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 Connect 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 Connect

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.

  1. Dans une fenêtre de navigateur, accédez à la console Google Developers et connectez-vous avec vos informations d’identification de compte Google.

  2. Cliquez sur Créer unde projet, puis entrez un nom de projet et ID de projet. Cochez la case Conditions d’utilisation. Cliquez ensuite sur Créer. Cela inscrit l’application auprès de Google.

    boîte de dialogue Nouveau projet de la console développeur Google

  3. Cliquez sur API & d’authentification dans le volet gauche. Cliquez ensuite sur informations d’identification. Sous OAuth, cliquez sur Créer un id client. Sélectionnez d’application web, puis cliquez sur 'écran Configurer le consentement. Fournissez un nom de produit , puis cliquez sur Enregistrer.

    écran Consentement de la console de développement Google

  4. Cliquez sur API & d’authentification dans le volet gauche. Cliquez ensuite sur API. Sous Parcourir les API, recherchez et recherchez API Google+. Activez le d’état sur .

    API Parcourir les API Google Developer Console

  5. Dans la boîte de dialogue Créer un ID client, sélectionnez application web commetype 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 ID client.

    écran Créer un ID client

  6. Notez les valeurs de ID client et clé secrète client à partir de l’ID client pour la page de l’application web. Vous en aurez besoin pour configurer l’implémentation OpenID Connect de Google sur le portail de gestion ACS .

    ID client de la console de développement Google pour l’application web

    Important

    clé secrète client est une information d’identification de sécurité importante. Gardez-le secret.

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

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

Le tableau suivant présente les types de revendications qui deviennent disponibles pour ACS à partir de Google une fois que l’espace de noms ACS a été migré pour utiliser l’implémentation OpenID Connect de Google :

Type de revendication URI Description Disponibilité du protocole

Identificateur de nom

https://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

Identificateur unique du 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 du compte d’utilisateur fourni par Google. Il s’agit de l’identificateur (nouveau) 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 courriel

https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Adresse e-mail du compte d’utilisateur fourni par Google

OpenID 2.0, OpenID Connect

Fournisseur d’identité

https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/IdentityProvider

Revendication fournie par ACS qui indique à l’application de 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 via le champ Domaine dans la page Modifier le fournisseur d’identité.

OpenID 2.0, OpenID Connect

Note

Pour un utilisateur Google qui n’a pas de profil Google+ (inscrit), la valeur du type de revendication Name est identique à la valeur de l’adresse e-mail type de revendication dans OpenID Connect.

Les Identificateur de nom et types de revendication Objet peuvent être utilisés pour suivre et changer les identificateurs uniques des utilisateurs existants dans votre back-end en mappant (ancien) les identificateurs OpenID 2.0 aux identificateurs OpenID Connect (nouveau).

Si vous avez la règle «passer toutes les revendications» pour Google en tant que fournisseur d’identité dans un groupe de règles associé à votre application, votre application commence automatiquement à recevoir le type de revendication Objet.

Si vous avez précédemment généré des règles ou ajouté des règles manuellement pour Google en tant que fournisseur d’identité dans un groupe de règles associé à votre application, vous devez ajouter manuellement le type de revendication Objet. Pour plus d’informations sur la procédure à suivre, consultez groupes de règles et règles.

configuration des revendications d’entrée

Par exemple, si vous aviez précédemment généré des règles pour Google en tant que 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.

revendications passthrough Google

L’application qui utilise ce groupe de règles reçoit le type de revendication Objet, ainsi que d’autres types de revendications.

Note

Après le 1er janvier 2017, lorsque Google interrompt sa prise en charge du mappage des identificateurs, ACS remplit à la fois les NameIdentifier et Objet types de revendications avec le même identificateur d’utilisateur OpenID Connect.

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

À une exception près, la migration de votre espace de noms ACS pour utiliser l’implémentation OpenID Connect de Google est possible sans modifier le code de l’application. Le cas d’exception est si vous disposez de la règle «passer toutes les revendications» pour Google en tant que fournisseur d’identité dans un groupe de règles associé à votre application. Cela est dû au fait que, dans ce cas, lors de la migration, un nouveau type de revendication (Objet) est automatiquement envoyé à l’application.

Cette section décrit la procédure de modification et de test recommandée que vous pouvez suivre pour vous assurer que chaque application qui sera affectée par la migration est prête à gérer le nouveau type de revendication.

Dans le cadre de cette procédure, supposons que vous êtes le propriétaire d’un espace de noms ACS appelé ns-contoso et que votre application en production est appelée ProdContosoApp. Supposons également que cette application utilise Google comme fournisseur d’identité et a «passthrough all claims» rule enabled for Google.

Coup monté

  1. Pour commencer, accédez au portail de gestion Microsoft Azure, connectez-vous, 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 .

  2. Dans ledu portail de gestion ACS , cliquez sur applications de partie de confiance dans l’arborescence sur le côté gauche ou cliquez sur le lien applications de partie de confiance sous la section Prise en main. Cliquez ensuite sur votre application de production (ProdContosoApp).

  3. Notez les propriétés de ProdContosoApp, vous en aurez besoin ultérieurement.

    boîte de dialogue Modifier l’application de partie de confiance

  4. Cliquez sur groupe de règles par défaut pour ProdContosoApp sous groupes de règles pour vérifier qu’elle contient la règle «passer toutes les revendications» activées pour Google.

    revendication de passthrough 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 AUTRE URI racine ; 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.

  1. Dans ledu portail de gestion ACS , cliquez sur applications de partie de confiance dans l’arborescence sur le côté gauche ou cliquez sur le lien applications de partie de confiance sous la section Prise en main. Cliquez ensuite sur Ajouter dans la page applications de partie de confiance .

  2. Dans la page Ajouter une application de partie de confiance, procédez comme suit :

    • Dans Nom, tapez le nom de l’application de test. Voici TestContosoApp.

    • En mode , sélectionnez Entrer manuellement les paramètres.

    • Dans Domaine, tapez l’URI de l’application de test. Ici, il est https://contoso-test.com:7777/.

    • Pour les besoins de cette procédure, vous pouvez laisser 'URL d’erreur (facultatif) vide.

    • Pour le format de jeton , stratégie de chiffrement de jetonet durée de vie du jeton (ss) et la section Paramètres de signature de jeton, utilisez les mêmes valeurs que celles que vous avez utilisées pour ProdContosoApp.

    • Vérifiez que vous avez sélectionné Google en tant quefournisseur d’identité .

    • Sous groupes de règles, sélectionnez Créer un groupe de règles.

    boîte de dialogue Ajouter une application de partie de confiance

  3. Cliquez sur Enregistrer en 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 OpenID Connect de Google

  1. Dans ledu portail de gestion ACS , cliquez sur groupes de règles dans l’arborescence sur le côté gauche ou cliquez sur le lien groupe de règles sous la section Prise en main. Cliquez ensuite sur Ajouter dans la page groupes de règles .

  2. Dans la page Ajouter un groupe de règles, fournissez un nom pour le nouveau groupe de règles, par exemple ManualGoogleRuleGroup. Cliquez sur Enregistrer.

    boîte de dialogue Ajouter un groupe de règles

  3. Dans la page Modifier le groupe de règles, cliquez sur le lien Ajouter.

    boîte de dialogue Modifier le groupe de règles

  4. Dans la page Ajouter une règle de revendication, vérifiez que vous avez les valeurs suivantes en place, puis cliquez sur Enregistrer. Cela génère une règle de «passthrough all claims» pour Google.

    • Section If :

      • identity Provider est Google.

      • type de revendication d’entrée sélection est Tout.

      • valeur de revendication d’entrée est Tout.

    • section Puis :

      • type de revendication de sortie est Pass through first claim type.

      • valeur de revendication de sortie est Pass through first input claim value.

    • section informations sur la règle :

      • Laissez le champ description (facultatif) vide.

    boîte de dialogue Ajouter une règle de revendicationboîte de dialogue Ajouter une règle de revendication

  5. Dans la page Modifier le groupe de règles, cliquez à nouveau sur le lien Ajouter.

  6. Dans la page Ajouter une règle de revendication, vérifiez que vous avez les valeurs suivantes en place, puis cliquez sur Enregistrer. Cela génère une règle de revendication « statique » pour Google qui simule l’ajout d’un nouveau type de revendication, Objet, qui est le nouvel identificateur OpenID Connect utilisateur que Google envoie l’application lors de la migration.

    • Section If :

      • identity Provider est Google.

      • type de revendication d’entrée sélection est Tout.

      • valeur de revendication d’entrée est Tout.

    • section Puis :

    • section informations sur la règle :

      • Laissez le champ description (facultatif) vide.

    boîte de dialogue Ajouter une revendication Rull

  7. Cliquez sur Enregistrer dans la page Modifier le groupe de règles .

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

  1. Dans ledu portail de gestion ACS , cliquez sur applications de partie de confiance dans l’arborescence sur le côté gauche ou cliquez sur le lien applications de partie de confiance sous la section Prise en main. Cliquez ensuite sur TestContosoApp sur la page applications de partie de confiance.

  2. Dans la page Modifier la partie de confiance, sélectionnez ManualGoogleRuleGroup dans la section Paramètres d’authentification, puis cliquez sur Enregistrer.

    paramètres d’authentification

À ce stade, toutes 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 (Subject). Normalement, une application bien écrite doit être robuste pour les nouveaux types de revendications ajoutés 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 section nouveaux identificateurs d’utilisateur OpenID Connect pour effectuer le mappage des identificateurs utilisateur.

Étape 5 : Migrer votre environnement de production

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