Partager via

Infrastructure d’identité globale Azure Active Directory B2C

Important

À compter du 1er mai 2025, Azure AD B2C ne sera plus disponible pour les nouveaux clients. Pour plus d’informations, consultez notre FAQ.

Azure Active Directory B2C est une solution de gestion des accès aux identités client (CIAM) capable de prendre en charge des millions d’utilisateurs et des milliards d’authentifications par jour. Elle prend en charge la mise à l’échelle et la sécurité de la plateforme d’authentification, surveillant et gérant automatiquement les menaces, telles que les attaques par déni de service, pulvérisation de mot de passe ou force brute.

Azure Active Directory B2C (Azure AD B2C) est un service distinct de l’ID Microsoft Entra. Elle repose sur la même technologie que Microsoft Entra ID, mais à des fins différentes. Elle permet aux entreprises de créer des applications accessibles aux clients, puis d’autoriser l’inscription en libre-service aux applications.

Azure AD B2C est un service distribué globalement composé de plusieurs composants :

Lors de la création d’une solution Azure AD B2C, vous devez fournir un emplacement pour héberger le service. Cet emplacement se rapporte uniquement à la région dans laquelle les données de profil utilisateur seront stockées, tandis que le reste du service qui traite votre connexion s’exécute globalement.

Vous déployez généralement un locataire Azure AD B2C dans la région la plus proche de votre base d’utilisateurs. Cela facilite la conformité aux lois relatives à la résidence des données, car le profil utilisateur n’est répliqué que dans la région sélectionnée. Cela offre également les meilleures performances lors de la connexion, car les latences réseau sont optimisées dans le magasin d’annuaires.

Lorsque votre annuaire Azure AD B2C nécessite de servir les utilisateurs dans le monde entier, la structure régionale pose un défi. Vous devez déterminer dans quel emplacement créer le client Azure AD B2C. Les utilisateurs en dehors de la région sélectionnée peuvent ne pas être conformes aux exigences de résidence des données et peuvent également rencontrer une latence accrue lors de la vérification de leurs informations d’identification ou de la lecture de leurs données de profil utilisateur.

Par exemple, considérez une application qui prend en charge les utilisateurs en Australie et en Amérique du Nord, et l’annuaire Azure AD B2C est créé dans la région Amérique du Nord. Les utilisateurs qui se connectent à partir de l’Australie peuvent rencontrer des temps de traitement plus longs pour terminer leur authentification.

Pour mieux répondre aux exigences de résidence des données et atténuer les problèmes de performances, vous devez déployer plusieurs locataires Azure AD B2C. En plaçant un locataire dans chaque région où votre entreprise opère, les opérations dans l’annuaire sont optimisées pour la latence. Toutefois, en procédant ainsi, la solution crée d’autres surcharges pour configurer, gérer et protéger ces ressources de locataire sensibles dans chaque région. D’autres surcharges sont les suivantes :

  • Administration des locataires

  • Isolation du locataire entraînant une expérience utilisateur final qui ne se sent pas globale

  • Facturation

  • Processus CI/CD pour gérer les stratégies/inscriptions d’applications/clés

Ce document propose des architectures avec Azure AD B2C qui conviennent le mieux aux solutions pour les clients qui servent les utilisateurs dans le monde entier. Les solutions répondent aux exigences suivantes :

  • Les utilisateurs peuvent conserver le même ensemble d’informations d’identification, quel que soit l’endroit où ils accèdent aux applications.

  • Performances et latence cohérentes, quel que soit l’endroit à partir duquel les utilisateurs s’authentifient.

  • Facilitez la livraison de processus, d’infrastructures ou de kits sdk à leurs équipes de développement avec la configuration la moins possible nécessaire.

  • Les profils utilisateur peuvent être conservés pendant que les utilisateurs voyagent dans le monde entier. Cela crée plus de valeur dans l’analytique générée par les interactions utilisateur au sein de n’importe quel service.

  • Les données utilisateur client sont stockées dans des magasins de données régionaux.

Voici deux approches à prendre en compte lors de l’implémentation d’une plateforme d’identité à l’aide de locataires Azure AD B2C pour un modèle d’entreprise global.

  • La première approche utilise des régions géographiques, car la limite et les applications sont configurées spécifiquement pour la région.

  • La deuxième approche a une limite globale pour les applications et utilise un locataire Azure AD B2C supplémentaire pour orchestrer l’interaction entre les locataires régionaux.

Orchestration de locataire régional

Dans ce modèle, les applications sont hébergées par région ou ont une configuration par région pour se connecter à un locataire régional. Les applications envoient directement l’utilisateur à un locataire spécifique à une région. La communication entre locataires est utilisée pour effectuer des authentifications entre locataires ou des mises à jour de profil entre locataires, lorsque l’utilisateur peut avoir voyagé vers une autre région.

Orchestration de locataire régional

Orchestration de locataire de synthèse

Dans ce modèle, un compte Azure AD B2C achemine les utilisateurs vers des comptes Azure AD B2C régionaux. Le locataire de synthèse fonctionne comme un orchestrateur de redirection vers d’autres locataires Azure AD B2C. Cela est géré par un composant distribué globalement du service Azure AD B2C. Par conséquent, les performances ne sont pas affectées. Cette redirection est effectuée à l’aide de fédérations de fournisseurs d’identité OpenId Connect.

La communication entre locataires est utilisée pour effectuer des authentifications entre locataires ou des mises à jour de profil entre locataires. Le locataire de synthèse fournit aux applications un point de terminaison unique avec lequel communiquer.

Orchestration de locataire de synthèse

L’architecture que vous décidez de modéliser la solution après, nécessite de faire des choix en fonction des compromis entre les deux modèles décrits. Par exemple, le modèle d’entonnoir vous permet de gérer une seule instance d’applications. La section suivante décrit les fonctionnalités, les critères de sélection et les performances qui peuvent avoir un impact sur la conception que vous choisissez.

Fonctionnalités et considérations

Le tableau suivant décrit les fonctionnalités fournies à l’aide d’une conception régionale ou en entonnoir :

Capacité Basé sur une région Basé sur la synthèse
Prend en charge l’inscription et la connexion au compte local case à cocher case à cocher
Prend en charge l’inscription et la connexion au compte fédéré case à cocher case à cocher
Prend en charge l’authentification des comptes locaux pour les utilisateurs qui se connectent en dehors de leur région inscrite case à cocher case à cocher
Prend en charge l’authentification des comptes fédérés pour les utilisateurs qui se connectent à partir de l’extérieur de leur région inscrite à l’aide de la recherche basée sur l’API interlocataire case à cocher case à cocher
Empêche l’inscription à partir de plusieurs régions différentes case à cocher case à cocher
Les applications de chaque région ont un ensemble de points de terminaison pour se connecter à case à cocher
Toutes les applications se connectent à un seul ensemble de points de terminaison, quelle que soit la région hébergée case à cocher
Prend en charge les stratégies d’accès conditionnel affinées. case à cocher
Optimisé pour les coûts. case à cocher

En fonction des fonctionnalités, les considérations suivantes doivent être prises en compte :

  • Lorsque vous utilisez l’approche basée sur une région, la principale considération est que l’approche exige que les applications couvrant plusieurs régions aient des configurations respectives pour chaque locataire Azure AD B2C régional.

  • Lors de l’utilisation de l’approche basée sur la synthèse

    • Il y a un coût à deux jetons

    • Il existe une redirection HTTP supplémentaire introduite

    • Des domaines personnalisés sont requis pour de nombreux locataires

    • L’accès conditionnel est appliqué au niveau du locataire, et non au niveau de l’application

    • La déconnexion unique via plusieurs IdP peut présenter des défis

L’approche que vous choisissez est basée sur le nombre d’applications que vous hébergez et les exigences spécifiques pour l’accès aux applications.

Performances

L'avantage de performance lié à l'utilisation de plusieurs locataires, que ce soit dans une configuration régionale ou basée sur l’entonnoir, sera supérieur à celui d'utiliser un seul locataire Azure AD B2C pour les entreprises opérant à l'échelle mondiale.

Lors de l’utilisation de l’approche basée sur la synthèse, le locataire de synthèse se trouve dans une région spécifique, et sert les utilisateurs de façon globale. Comme l’opération des locataires de synthèse utilise un composant global du service Azure AD B2C, elle maintient un niveau de performances constant, quel que soit le lieu de connexion des utilisateurs.

Capture d’écran montrant l’architecture Azure AD B2C.

Comme indiqué dans le diagramme ci-dessus, le locataire Azure AD B2C dans l’approche basée sur l’entonnoir utilise uniquement le moteur de stratégie pour effectuer la redirection vers des locataires Azure AD B2C régionaux. Le composant moteur de stratégie Azure AD B2C est distribué globalement. Par conséquent, la synthèse n’est pas limitée du point de vue des performances, quel que soit l’emplacement où le locataire de synthèse Azure AD B2C est approvisionné. Une perte de performances est rencontrée en raison de la redirection supplémentaire entre les locataires de synthèse et les locataires régionaux dans l’approche basée sur la synthèse.

Dans l’approche régionale, étant donné que chaque utilisateur est dirigé vers son azure AD B2C le plus local, les performances sont cohérentes pour tous les utilisateurs qui se connectent.

Les locataires régionaux effectuent des appels d’annuaires dans le magasin d’annuaires, qui est le seul composant régionalisé à la fois dans les architectures basées sur la synthèse et dans les architectures basée sur les régions.

Une latence supplémentaire est uniquement rencontrée lorsque l’utilisateur a effectué une authentification dans une autre région que celle à laquelle il s’est inscrit. Cela est dû au fait que des appels seront effectués à travers différentes régions pour accéder au Magasin d’annuaires où se trouve leur profil, afin de finaliser leur authentification.

Étapes suivantes