Créer une solution d’identité globale avec une approche basée sur la synthèse

Dans cet article, nous décrivons les scénarios d’approche de conception basée sur la synthèse. Avant de commencer à concevoir, il est recommandé de passer en revue les fonctionnalités et les performances de l’approche de conception basée sur la synthèse et la région. Cet article vous aidera à déterminer quelle conception conviendra le mieux à votre organisation.

Les conceptions comptent pour :

• Inscription et connexion au compte local
• Inscription et connexion de compte fédéré
• Authentification des comptes locaux pour les utilisateurs qui se connectent à partir de l’extérieur de leur région inscrite, prise en charge par l’authentification basée sur l’API entre locataires
• Authentification des comptes fédérés pour les utilisateurs qui se connectent à partir de l’extérieur de leur région inscrite, prise en charge par l’authentification basée sur l’API entre locataires
• Empêche l’inscription à partir de plusieurs régions différentes
• Les applications de chaque région ont un point de terminaison unique avec lequel se connecter

Cas d’utilisation de la connexion de compte local

Les cas d’usage suivants sont typiques dans un environnement Azure AD B2C global. Les cas d’utilisation du compte local couvrent également les comptes où l’utilisateur se déplace. Nous fournissons un diagramme et des étapes de flux de travail pour chaque cas d’usage.

Inscription de l’utilisateur local

Ce cas d’usage montre comment un utilisateur de son pays/région d’origine effectue une inscription avec un compte local Azure AD B2C.

1. Un utilisateur d’Europe, Moyen-Orient et Afrique (EMEA) tente de s’inscrire sur myapp.fr. Si l’utilisateur n’est pas renvoyé vers son instance d’application locale, le gestionnaire de trafic applique une redirection.

2. L’utilisateur atteint le locataire Azure AD B2C de synthèse globale. Ce locataire est configuré pour rediriger vers un locataire Azure AD B2C régional en fonction de critères définis à l’aide de la fédération OpenId. Il peut s’agir d’une recherche basée sur Application clientId.

3. L’utilisateur tente de s’inscrire. Le processus d’inscription vérifie la table de recherche globale pour déterminer si l’utilisateur existe dans l’un des locataires Azure AD B2C régionaux.

4. L’utilisateur est introuvable dans la table de recherche globale. Le compte de l’utilisateur est écrit dans Azure AD B2C et un enregistrement est créé dans la table de choix globale pour suivre la région dans laquelle l’utilisateur s’est inscrit.

5. Le locataire régional émet un jeton au locataire de synthèse.

6. Le locataire de synthèse émet un jeton pour l’application.

Tentatives d’inscription des utilisateurs locaux existants

Ce cas d’usage montre comment un utilisateur qui réinscrit le même e-mail à partir de son propre pays ou de sa propre région, ou d’une autre région, est bloqué.

1. Un utilisateur de la région EMEA tente de s’inscrire à myapp.fr. Si l’utilisateur n’est pas renvoyé vers son instance d’application locale, le gestionnaire de trafic applique une redirection.

2. L’utilisateur atteint le locataire Azure AD B2C de synthèse globale. Ce locataire est configuré pour rediriger vers un locataire Azure AD B2C régional en fonction de certains critères à l’aide de la fédération OpenId. Il peut s’agir d’une recherche basée sur Application clientId.

3. L’utilisateur tente de s’inscrire. Le processus d’inscription vérifie la table de recherche globale pour déterminer si l’utilisateur existe dans l’un des locataires Azure AD B2C régionaux.

4. L’e-mail de l’utilisateur se trouve dans la table de choix globale, indiquant que l’utilisateur a inscrit cet e-mail dans la solution à un moment donné.

5. Une erreur s’affiche à l’utilisateur, indiquant que son compte existe.

Connexion de l’utilisateur local

Ce cas d’usage montre comment un utilisateur de son pays/région d’origine effectue une connexion avec un compte local Azure AD B2C.

1. Un utilisateur de la région EMEA tente de se connecter à myapp.fr. Si l’utilisateur n’est pas renvoyé vers son instance d’application locale, le gestionnaire de trafic applique une redirection.

2. L’utilisateur atteint le locataire Azure AD B2C de synthèse globale. Ce locataire est configuré pour rediriger vers un locataire Azure AD B2C régional en fonction de certains critères à l’aide de la fédération OpenId. Il peut s’agir d’une recherche basée sur l’id client de l’application.

3. Un utilisateur entre ses informations d’identification au niveau du locataire régional.

4. Le locataire régional émet un jeton au locataire de synthèse.

5. Le locataire de synthèse émet un jeton pour l’application.

Connexion de l’utilisateur itinérant

Ce cas d’usage montre comment un utilisateur peut voyager entre les régions et conserver son profil utilisateur et ses informations d’identification stockées dans son locataire régional, respectivement à son inscription.

1. Un utilisateur d’Amérique du Nord (NOAM) tente de se connecter à myapp.fr, alors qu’il est en vacances en France. Si l’utilisateur n’est pas renvoyé vers son instance d’application locale, le gestionnaire de trafic applique une redirection.

2. L’utilisateur atteint le locataire Azure AD B2C de synthèse globale. Ce locataire est configuré pour rediriger vers un locataire Azure AD B2C régional en fonction de certains critères à l’aide de la fédération OpenId. Il peut s’agir d’une recherche basée sur Application clientId.

3. Un utilisateur entre ses informations d’identification au niveau du locataire régional.

4. Le locataire régional effectue une recherche dans la table de choix globale, car l’e-mail de l’utilisateur n’a pas été trouvé dans le répertoire Azure AD B2C EMEA.

5. L’e-mail de l’utilisateur a été détecté comme inscrit dans le locataire NOAM Azure AD B2C.

6. Le locataire EMEA Azure AD B2C effectue un flux Microsoft Entra ROPC sur le locataire NOAM Azure AD B2C pour vérifier les informations d’identification.

   Notes

   Cet appel récupère également un jeton pour que l’utilisateur effectue un appel API Graph. Le locataire Azure AD B2C EMEA effectue un appel API Graph au locataire NOAM Azure AD B2C pour récupérer le profil de l’utilisateur. Cet appel est authentifié par le jeton d’accès pour API Graph acquis à la dernière étape.

7. Le locataire régional émet un jeton au locataire de synthèse.

8. Le locataire de synthèse émet un jeton pour l’application.

Mot de passe oublié de l’utilisateur local

Ce cas d’usage montre comment un utilisateur peut réinitialiser son mot de passe quand il se trouve dans son pays ou sa région d’origine.

1. Un utilisateur de la région EMEA tente de se connecter à myapp.fr. Si l’utilisateur n’est pas renvoyé vers son instance d’application locale, le gestionnaire de trafic applique une redirection.

2. L’utilisateur atteint le locataire Azure AD B2C de synthèse globale. Ce locataire est configuré pour rediriger vers un locataire Azure AD B2C régional en fonction de certains critères à l’aide de la fédération OpenId. Il peut s’agir d’une recherche basée sur l’id client de l’application.

3. L’utilisateur arrive au locataire Azure AD B2C EMEA et sélectionne le mot de passe oublié. L’utilisateur entre et vérifie son e-mail.

4. Une recherche e-mail est effectuée pour déterminer le locataire régional dans lequel l’utilisateur existe.

5. L’utilisateur fournit un nouveau mot de passe.

6. Le nouveau mot de passe est écrit dans le locataire Azure AD B2C EMEA.

7. Le locataire régional émet un jeton au locataire de synthèse.

8. Le locataire de synthèse émet un jeton pour l’application.

Mot de passe oublié de l’utilisateur itinérant

Ce cas d’usage montre comment un utilisateur peut réinitialiser son mot de passe lorsqu’il quitte la région dans laquelle il a inscrit son compte.

1. Un utilisateur NOAM tente de se connecter à myapp.fr alors qu’il est en vacances en France. Si l’utilisateur n’est pas renvoyé vers son instance d’application locale, le gestionnaire de trafic applique une redirection.

2. L’utilisateur atteint le locataire Azure AD B2C de synthèse globale. Ce locataire est configuré pour rediriger vers un locataire Azure AD B2C régional en fonction de certains critères à l’aide de la fédération OpenId. Il peut s’agir d’une recherche basée sur l’id client de l’application.

3. L’utilisateur arrive au locataire Azure AD B2C EMEA et sélectionne le mot de passe oublié. L’utilisateur entre et vérifie son e-mail.

4. Une recherche e-mail est effectuée pour déterminer le locataire régional dans lequel l’utilisateur existe.

5. L’e-mail existe dans le locataire NOAM Azure AD B2C. L’utilisateur fournit un nouveau mot de passe.

6. Le nouveau mot de passe est écrit dans le locataire NOAM Azure AD B2C par le biais d’un appel API Graph.

7. Le locataire régional émet un jeton au locataire de synthèse.

8. Le locataire de synthèse émet un jeton pour l’application.

Modification du mot de passe de l’utilisateur local

Ce cas d’usage montre comment un utilisateur peut modifier son mot de passe après s’être connecté à la région dans laquelle il a inscrit son compte.

1. Un utilisateur de la région EMEA tente de sélectionner modifier le mot de passe après s’être connecté à myapp.fr.

2. L’utilisateur atteint le locataire Azure AD B2C de synthèse globale. Ce locataire est configuré pour rediriger vers un locataire Azure AD B2C régional en fonction de certains critères à l’aide de la fédération OpenId. Il peut s’agir d’une recherche basée sur l’id client de l’application.

3. L’utilisateur arrive au locataire Azure AD B2C EMEA et le cookie Single-Sign On (SSO) permet à l’utilisateur de modifier son mot de passe immédiatement.

4. Le nouveau mot de passe est écrit dans le compte des utilisateurs dans le locataire Azure AD B2C EMEA.

5. Le locataire régional émet un jeton au locataire de synthèse.

6. Le locataire de synthèse émet un jeton pour l’application.

Modification du mot de passe de l’utilisateur itinérant

Ce cas d’usage montre comment un utilisateur peut modifier son mot de passe après s’être connecté, en dehors de la région dans laquelle il a inscrit son compte.

1. Un utilisateur NOAM tente de modifier le mot de passe après s’être connecté à myapp.fr.

2. L’utilisateur atteint le locataire Azure AD B2C de synthèse globale. Ce locataire est configuré pour rediriger vers un locataire Azure AD B2C régional en fonction de certains critères à l’aide de la fédération OpenId. Il peut s’agir d’une recherche basée sur l’id client de l’application.

3. L’utilisateur arrive au locataire Azure AD B2C EMEA, et l’ensemble de cookies d’authentification unique permet à l’utilisateur de modifier son mot de passe immédiatement.

4. L’e-mail de l’utilisateur se trouve dans le locataire NOAM après vérification de la table de choix globale.

5. Le nouveau mot de passe est écrit dans le compte des utilisateurs dans le locataire NOAM Azure AD B2C par appel MS API Graph.

6. Le locataire régional émet un jeton au locataire de synthèse.

7. Le locataire de synthèse émet un jeton pour l’application.

Authentifications du fournisseur d’identité fédérée

Les cas d’usage suivants illustrent des exemples d’utilisation d’identités fédérées pour s’inscrire ou se connecter en tant que client Azure AD B2C.

Inscription d’ID fédéré local

Ce cas d’usage montre comment un utilisateur peut s’inscrire au service depuis sa région locale à l’aide d’un ID fédéré.

1. Un utilisateur de la région EMEA tente de s’inscrire à myapp.fr. Si l’utilisateur n’est pas renvoyé vers son instance d’application locale, le gestionnaire de trafic applique une redirection.

2. L’utilisateur atteint le locataire Azure AD B2C de synthèse globale. Ce locataire est configuré pour rediriger vers un locataire Azure AD B2C régional en fonction de certains critères à l’aide de la fédération OpenId. Il peut s’agir d’une recherche basée sur l’id client de l’application.

3. Un utilisateur choisit de se connecter avec un fournisseur d’identité fédéré (IdP).

4. Effectuez une recherche dans la table de recherche globale.

   • Si la liaison de compte est dans l’étendue : poursuivez si l’identificateur IdP fédéré ou l’e-mail qui est revenu à partir de l’IdP fédéré n’existent pas dans la table de recherche.

   • Si la liaison de compte n’est pas dans l’étendue: procédez si l’identificateur IdP fédéré qui est revenu du fournisseur d’identité fédéré n’existe pas dans la table de choix.

5. Écrivez le compte d’utilisateurs dans le locataire Azure AD B2C EMEA.

6. Le locataire régional émet un jeton au locataire de synthèse.

7. Le locataire de synthèse émet un jeton pour l’application.

Connexion utilisateur fédérée locale

Ce cas d’usage montre comment un utilisateur de sa région locale se connecte au service à l’aide d’un ID fédéré.

1. Un utilisateur de la région EMEA tente de se connecter à myapp.fr. Si l’utilisateur n’est pas renvoyé vers son instance d’application locale, le gestionnaire de trafic applique une redirection.

2. L’utilisateur atteint le locataire Azure AD B2C de synthèse globale. Ce locataire est configuré pour rediriger vers un locataire Azure AD B2C régional en fonction de certains critères à l’aide de la fédération OpenId. Il peut s’agir d’une recherche basée sur Application clientId.

3. Un utilisateur choisit de se connecter avec un fournisseur d’identité fédéré.

4. Effectuez une recherche dans la table de choix globale et vérifiez que l’ID fédéré de l’utilisateur est inscrit dans la région EMEA.

5. Le locataire régional émet un jeton au locataire de synthèse.

6. Le locataire de synthèse émet un jeton pour l’application.

Connexion utilisateur fédérée itinérante

Ce cas d’usage montre comment un utilisateur peut se connecter à son compte avec un fournisseur d’identité fédéré, alors qu’il se trouve loin de la région dans laquelle il s’est inscrit.

1. Un utilisateur NOAM tente de se connecter à myapp.fr. Si l’utilisateur n’est pas renvoyé vers son instance d’application locale, le gestionnaire de trafic applique une redirection.

2. L’utilisateur atteint le locataire Azure AD B2C de synthèse globale. Ce locataire est configuré pour rediriger vers un locataire Azure AD B2C régional en fonction de certains critères à l’aide de la fédération OpenId. Il peut s’agir d’une recherche basée sur Application clientId.

3. Un utilisateur choisit de se connecter avec un fournisseur d’identité fédéré.

   Notes

   Utilisez le même ID d’application que celui de l’inscription de l’application sur l’IdP social sur tous les locataires régionaux Azure AD B2C. Cela garantit que l’ID provenant du fournisseur d’identité social est toujours le même.

4. Effectuez une recherche dans la table de choix globale et déterminez que l’ID fédéré de l’utilisateur est inscrit dans NOAM.

5. Lisez les données de compte du locataire NOAM Azure AD B2C à l’aide de MS API Graph.

6. Le locataire régional émet un jeton au locataire de synthèse.

7. Le locataire de synthèse émet un jeton pour l’application.

Liaison de compte avec des critères de correspondance

Ce cas d’usage montre comment les utilisateurs peuvent effectuer une liaison de compte lorsque les critères correspondants sont satisfaits. Les critères correspondants sont généralement l’adresse e-mail des utilisateurs. Lorsque les critères de correspondance d’une connexion à partir d’un nouveau fournisseur d’identité ont la même valeur qu’un compte existant dans Azure AD B2C, le processus de liaison de compte peut commencer.

1. Un utilisateur de la région EMEA tente de se connecter à myapp.fr. Si l’utilisateur n’est pas renvoyé vers son instance d’application locale, le gestionnaire de trafic applique une redirection.

2. L’utilisateur atteint le locataire Azure AD B2C de synthèse globale. Ce locataire est configuré pour rediriger vers un locataire Azure AD B2C régional en fonction de certains critères à l’aide de la fédération OpenId. Il peut s’agir d’une recherche basée sur Application clientId.

3. Un utilisateur choisit de se connecter avec un fournisseur d’identité fédéré ou un IdP social.

4. Une recherche est effectuée dans la table de recherche globale pour l’ID retourné par le fournisseur d’identité fédéré.

5. Si l’ID n’existe pas, mais que l’e-mail du fournisseur d’identité fédéré existe dans Azure AD B2C EMEA, il s’agit d’un cas d’usage de liaison de compte.

6. Lisez l’utilisateur à partir de l’annuaire et déterminez les méthodes d’authentification activées sur le compte. Présentez un écran permettant à l’utilisateur de se connecter avec une méthode d’authentification existante sur ce compte.

7. Une fois que l’utilisateur a prouvé qu’il est propriétaire du compte dans Azure AD B2C, ajoutez le nouvel ID social au compte existant, puis ajoutez l’ID social au compte dans la table de recherche globale.

8. Le locataire régional émet un jeton au locataire de synthèse.

9. Le locataire de synthèse émet un jeton pour l’application.

Liaison de compte d’utilisateur itinérant avec des critères correspondants

Ce cas d’usage montre comment les utilisateurs non locaux sont en mesure d’effectuer une liaison de compte lorsque les critères de correspondance sont satisfaits. Les critères correspondants sont généralement l’adresse e-mail des utilisateurs. Lorsque les critères de correspondance d’une connexion à partir d’un nouveau fournisseur d’identité ont la même valeur qu’un compte existant dans Azure AD B2C, le processus de liaison de compte peut commencer.

1. Un utilisateur NOAM tente de se connecter à myapp.fr. Si l’utilisateur n’est pas renvoyé vers son instance d’application locale, le gestionnaire de trafic applique une redirection.

2. L’utilisateur atteint le locataire Azure AD B2C de synthèse globale. Ce locataire est configuré pour rediriger vers un locataire Azure AD B2C régional en fonction de certains critères à l’aide de la fédération OpenId. Il peut s’agir d’une recherche basée sur Application clientId.

3. Un utilisateur choisit de se connecter avec un fournisseur d’identité fédéré ou un IdP social.

4. Une recherche est effectuée dans la table de recherche globale pour l’ID retourné par le fournisseur d’identité fédéré.

5. Lorsque l’ID n’existe pas et que l’e-mail du fournisseur d’identité fédéré existe dans une autre région, il s’agit d’un cas d’usage lié à un compte d’utilisateur itinérant.

6. Créez un lien id_token_hint qui affirme les revendications actuellement collectées par les utilisateurs. Démarrez un parcours dans le locataire NOAM Azure AD B2C à l’aide de la fédération. L’utilisateur prouvera qu’il est propriétaire du compte via le locataire NOAM Azure AD B2C.

   Notes

   Cette méthode est utilisée pour réutiliser la logique de liaison de compte existante dans le locataire d’origine et réduire les appels d’API externes afin de manipuler la collection d’identités. Un exemple de stratégie personnalisée qui utilise id_token_hint est disponible ici.

7. Une fois que l’utilisateur a prouvé qu’il est propriétaire du compte dans Azure AD B2C, ajoutez le nouvel ID social au compte existant en effectuant un appel API Graph au locataire NOAM Azure AD B2C. Ajoutez l’ID social au compte dans la table de recherche globale.

8. Le locataire régional émet un jeton au locataire de synthèse.

9. Le locataire de synthèse émet un jeton pour l’application.

Étapes suivantes

• Solutions d’identité globale Azure AD B2C

• Créer une solution d’identité globale avec une approche basée sur les régions

• Configuration de preuve de concept d’identité globale Azure AD B2C basée sur la région

• Configuration basée sur la synthèse d’identité globale Azure AD B2C