Créer une solution d’identité globale avec une approche basée sur les régions
Dans cet article, nous décrivons les scénarios d’approche de conception basée sur les régions. 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.
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 disposent d’un ensemble de points de terminaison pour se connecter
Authentifications 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. Chacune fournit 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.
L’utilisateur d’Europe, du Moyen-Orient et d’Afrique (EMEA) tente de s’inscrire sur myapp.fr. Si l’utilisateur n’est pas envoyé à son nom d’hôte local, le gestionnaire de trafic applique une redirection.
L’utilisateur accède au locataire EMEA.
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.
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.
Le locataire régional émet un jeton à 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é.
L’utilisateur de la région EMEA tente de s’inscrire à myapp.fr. Si l’utilisateur n’est pas envoyé à son nom d’hôte local, le gestionnaire de trafic applique une redirection.
L’utilisateur accède au locataire EMEA.
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.
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é.
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.
L’utilisateur de la région EMEA tente de se connecter à myapp.fr. Si l’utilisateur n’est pas envoyé à son nom d’hôte local, le gestionnaire de trafic applique une redirection.
L’utilisateur accède au locataire EMEA.
L’utilisateur entre ses informations d’identification au niveau du locataire régional.
Le locataire régional émet un jeton à l’application.
L’utilisateur est connecté à 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.
L’utilisateur de Amérique du Nord (NOAM) tente de se connecter à myapp.fr, car il est en vacances en France. Si l’utilisateur n’est pas envoyé à son nom d’hôte local, le gestionnaire de trafic applique une redirection.
L’utilisateur accède au locataire EMEA.
L’utilisateur entre ses informations d’identification au niveau du locataire régional.
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.
L’e-mail de l’utilisateur a été détecté comme inscrit dans le locataire NOAM Azure AD B2C.
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.
Le locataire régional émet un jeton à 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.
L’utilisateur de la région EMEA tente de se connecter à myapp.fr. Si l’utilisateur n’est pas envoyé à son nom d’hôte local, le gestionnaire de trafic applique une redirection.
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.
Une recherche e-mail est effectuée pour déterminer le locataire régional dans lequel l’utilisateur existe.
L’utilisateur fournit un nouveau mot de passe.
Le nouveau mot de passe est écrit dans le locataire Azure AD B2C EMEA.
Le locataire régional émet un jeton à 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.
L’utilisateur de NOAM tente de se connecter à myapp.fr puisqu’il est en vacances en France. Si l’utilisateur n’est pas envoyé à son nom d’hôte local, le gestionnaire de trafic applique une redirection.
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.
Une recherche e-mail est effectuée pour déterminer le locataire régional dans lequel l’utilisateur existe.
L’e-mail existe dans le locataire NOAM Azure AD B2C. L’utilisateur fournit un nouveau mot de passe.
Le nouveau mot de passe est écrit dans le locataire NOAM Azure AD B2C par le biais d’un appel API Graph.
Le locataire régional émet un jeton à 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.
L’utilisateur de la région EMEA tente de sélectionner modifier le mot de passe après s’être connecté à myapp.fr.
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.
Le nouveau mot de passe est écrit dans le compte des utilisateurs dans le locataire Azure AD B2C EMEA.
Le locataire régional émet un jeton à 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.
Les utilisateurs de NOAM tentent de sélectionner modifier le mot de passe après s’être connectés à myapp.fr.
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.
L’e-mail des utilisateurs se trouve dans le locataire NOAM après avoir vérifié la table de recherche globale.
Le nouveau mot de passe est écrit dans le compte des utilisateurs dans le locataire NOAM Azure AD B2C par appel MS API Graph.
Le locataire régional émet un jeton à 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 de sa région locale s’inscrit au service à l’aide d’un ID fédéré.
L’utilisateur de la région EMEA tente de s’inscrire à myapp.fr. Si l’utilisateur n’est pas envoyé à son nom d’hôte local, le gestionnaire de trafic applique une redirection.
L’utilisateur accède au locataire EMEA.
L’utilisateur choisit de se connecter avec un fournisseur d’identité fédéré.
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.
Écrivez le compte d’utilisateurs dans le locataire Azure AD B2C EMEA.
Le locataire régional émet un jeton à 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é.
L’utilisateur de la région EMEA tente de se connecter à myapp.fr. Si l’utilisateur n’est pas envoyé à son nom d’hôte local, le gestionnaire de trafic applique une redirection.
L’utilisateur accède au locataire EMEA.
L’utilisateur choisit de se connecter avec un fournisseur d’identité fédéré.
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.
Le locataire régional émet un jeton à l’application.
Connexion utilisateur fédérée itinérante
Ce scénario montre comment un utilisateur situé loin de la région à partir de laquelle il s’est inscrit effectue une connexion au service à l’aide d’un fournisseur d’identité fédéré.
L’utilisateur de NOAM tente de se connecter à myapp.fr. Si l’utilisateur n’est pas envoyé à son nom d’hôte local, le gestionnaire de trafic applique une redirection.
L’utilisateur accède au locataire EMEA.
L’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.
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.
Lisez les données de compte du locataire NOAM Azure AD B2C à l’aide de MS API Graph.
Le locataire régional émet un jeton à l’application.
Liaison de compte avec des critères de correspondance
Ce scénario montre comment les utilisateurs peuvent effectuer la liaison de compte lorsqu’un critère correspondant est satisfait (généralement l’adresse e-mail).
L’utilisateur de la région EMEA tente de se connecter à myapp.fr. Si l’utilisateur n’est pas envoyé à son nom d’hôte local, le gestionnaire de trafic applique une redirection.
L’utilisateur accède au locataire EMEA.
L’utilisateur choisit de se connecter avec un fournisseur d’identité fédéré/IdP social.
Une recherche est effectuée dans la table de recherche globale pour l’ID retourné par le fournisseur d’identité fédéré.
Si l’ID n’existe pas, mais que l’e-mail du fournisseur d’identité fédéré existe dans EMEA Azure AD B2C, il s’agit d’un scénario de liaison de compte.
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.
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.
Le locataire régional émet un jeton à l’application.
Liaison de compte d’utilisateur itinérant avec des critères correspondants
Ce scénario montre comment les utilisateurs peuvent effectuer la liaison de compte lorsqu’ils sont loin de la région.
L’utilisateur de NOAM tente de se connecter à myapp.fr. Si l’utilisateur n’est pas envoyé à son nom d’hôte local, le gestionnaire de trafic applique une redirection.
L’utilisateur accède au locataire EMEA.
L’utilisateur choisit de se connecter avec un fournisseur d’identité fédéré/IdP social.
Une recherche est effectuée dans la table de recherche globale pour l’ID retourné par le fournisseur d’identité fédéré.
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 scénario de liaison de compte d’utilisateur itinérant.
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.
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.
Le locataire régional émet un jeton à l’application.