Partager via


Infrastructure d’identité globale Azure Active Directory B2C

Azure Active Directory B2C est une solution de gestion des identités et des accès clients, 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 Microsoft Entra ID. Il repose sur la même technologie que Microsoft Entra ID, mais à des fins différentes. Il permet aux entreprises de créer des applications orientées client, puis d’autoriser l’inscription en libre-service aux applications.

Azure AD B2C est un service distribué à l’échelle mondiale 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 concerne 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 le maintien de la conformité avec les lois de 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 pour le magasin d’annuaires.

Lorsque votre annuaire Azure AD B2C nécessite des services aux utilisateurs dans le monde entier, la structure régionale pose un défi. Vous devez déterminer l’emplacement dans lequel créer le locataire Azure AD B2C. Tous 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 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 faire face à des délais 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 le répertoire sont optimisées pour la latence. Toutefois et ce faisant, 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 comprennent :

  • Administration de locataire

  • L’isolation du locataire entraînant une expérience de l’utilisateur final qui ne paraît 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 prennent en charge les solutions les plus appropriées pour les clients qui servent des 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 d’où les utilisateurs s’authentifient.

  • Permettre aux clients de fournir facilement des processus, des frameworks ou des kits de développement logiciel (SDK) à leurs équipes de développement avec le moins de configuration possible requise.

  • Les profils utilisateur peuvent être conservés lorsque 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 d’un 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és à l’aide de locataires Azure AD B2C pour un modèle d’entreprise opérationnel à l’échelle mondiale.

  • La première approche utilise des régions géographiques comme 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 interlocataire est utilisée pour effectuer des authentifications interlocataires ou des mises à jour de profil entre locataires, lorsque l’utilisateur a peut-être voyagé dans une autre région.

Orchestration de locataire régional

Orchestration de locataire de synthèse

Dans ce modèle, un locataire Azure AD B2C synthétise les utilisateurs vers des locataires Azure AD B2C régionaux. Le locataire de synthèse fonctionne comme un orchestrateur de redirection vers d’autres locataires Azure AD B2C. Ceci est géré par un composant distribué à l’échelle mondiale du service Azure AD B2C. Par conséquent, les performances ne sont pas affectées. Cette redirection est effectuée à l’aide des fédérations du fournisseur 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 après laquelle vous décidez de modéliser la solution 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 et basée sur la synthèse :

Fonctionnalité Basé sur une région Basé sur la synthèse
Prend en charge l’inscription et la connexion de 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 à partir de l’extérieur 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 disposent d’un ensemble de points de terminaison pour se connecter Case à cocher
Toutes les applications se connectent à un ensemble unique de points de terminaison, quelle que soit la région dans laquelle elles sont hébergées Case à cocher
Prend en charge des 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

    • Une redirection HTTP supplémentaire a été 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 sera 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 en matière de performances de l’utilisation de plusieurs locataires, dans la configuration régionale ou basée sur la synthèse, sera une amélioration par rapport à l’utilisation d’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, dans l’approche basée sur la synthèse, le locataire Azure AD B2C utilisera seulement le moteur de stratégie pour effectuer la redirection vers les locataires Azure AD B2C régionaux. Le composant Moteur de stratégie Azure AD B2C est distribué à l’échelle mondiale. 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 la synthèse et les locataires régionaux dans l’approche basée sur la synthèse.

Dans l’approche basée sur les régions, comme chaque utilisateur est dirigé vers son annuaire Azure AD B2C le plus local, les performances sont constantes 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 n’est rencontrée que lorsque l’utilisateur a effectué une authentification dans une autre région à partir de laquelle il s’était inscrit. Cela est dû au fait que des appels seront effectués entre les régions pour atteindre le Magasin d’annuaires où réside leur profil pour terminer leur authentification.

Étapes suivantes