Partager via

Considérations relatives à l’utilisation d’Azure Active Directory B2C dans une architecture multilocataire

  • Article

Azure Active Directory (Azure AD B2C) fournit une identité entreprise-client en tant que service. L’identité de l’utilisateur est généralement l’une des principales considérations à prendre en compte lorsque vous concevez une application multilocataire. Votre solution d’identité est la gardienne de votre application et garantie que vos locataires restent dans les limites que vous définissez pour eux. Cet article décrit les considérations et les approches relatives à l’utilisation d’Azure AD B2C dans une solution multilocataire.

L’une des raisons les plus courantes de l’utilisation d’Azure AD B2C est d’activer la fédération des identités pour une application. La fédération des identités est le processus pour établir de la confiance entre deux fournisseurs d’identité pour que vos utilisateurs puissent se connecter avec un compte préexistant. Si vous utilisez Azure AD B2C, vous pouvez implémenter la fédération des identités pour permettre à vos utilisateurs de se connecter à l’aide de leurs comptes de réseaux sociaux ou d’entreprise. Si vous utilisez la fédération, vos utilisateurs n’ont pas besoin de créer un compte local distinct spécifique à votre application.

Si vous débutez dans ce domaine, nous vous recommandons de consulter les ressources suivantes :

Notes

Dans cet article, deux concepts au nom similaire sont abordés : les locataires d’application et les locataires Azure AD B2C.

Le terme locataire est utilisé pour faire référence à vos locataires, qui peuvent être vos clients ou des groupes d’utilisateurs.

Azure AD B2C utilise également le concept de locataire en référence à des répertoires individuels, et le terme multilocataire est utilisé pour faire référence aux interactions entre plusieurs locataires Azure AD B2C. Bien que les termes soient les mêmes, les concepts ne le sont pas. Lorsqu’un locataire Azure AD B2C est mentionné dans cet article, le terme complet locataire Azure AD B2C est utilisé.

Identité dans les solutions multilocataires

Dans les solutions multilocataires, il est courant de combiner plusieurs services d’identité pour répondre à différents ensembles d’exigences. De nombreuses solutions ont deux ensembles distincts d’identités :

  • Les identités client qui sont destinées aux comptes d’utilisateur final. Elles contrôlent la façon dont les utilisateurs de vos locataires accèdent à vos applications.
  • Les identités internes qui gèrent la façon dont votre propre équipe gère votre solution.

Ces différents types d’identité utilisent généralement des services d’identité distincts. Azure AD B2C est de Gestion des identités et des accès des clients que les utilisateurs de vos locataires utilisent pour accéder à la solution. Microsoft Entra ID (Azure AD) est un service de gestion des identités et des accès que vous et votre équipe utilisez pour gérer vos ressources Azure et contrôler votre application.

Prenons l’exemple d’une solution multilocataire conçue par Fabrikam. La solution utilise une combinaison des deux services pour répondre aux exigences de Fabrikam :

  • Fabrikam implémente Azure AD B2C afin que les clients (locataires) de l’entreprise puissent se connecter aux applications.
  • Les employés de Fabrikam utilisent le répertoire Microsoft Entra de leur organisation pour accéder à leur solution à des fins de gestion et d’administration. Ils utilisent les mêmes identités que celles qu’ils utilisent pour accéder à d’autres ressources Fabrikam, comme Microsoft Office.

Le schéma suivant illustre cet exemple :

Diagramme illustrant deux applications avec deux méthodes de connexion.

Modèles d’isolation

Lorsque vous utilisez Azure AD B2C, vous devez décider comment isoler vos comptes d’utilisateur entre différents locataires d’application.

Vous devez tenir compte de questions telles que celles-ci :

  • Avez-vous besoin de fédérer les connexions aux fournisseurs d’identité de votre client ? Par exemple, devez-vous activer la fédération vers SAML, Microsoft Entra ID, les fournisseurs de connexion sociale ou d’autres sources ?
  • Vos locataires ou vous-même avez-vous des exigences en matière de résidence des données ?
  • L’utilisateur doit-il accéder à plusieurs locataires d’application ?
  • Avez-vous besoin d’autorisations complexes et/ou de contrôle d’accès en fonction du rôle (RBAC) ?
  • Qui se connecte à votre application ? Différentes catégories d’utilisateurs sont souvent appelées personnages d’utilisateur.

Le tableau suivant récapitule les différences parmi les principaux modèles de location pour Azure AD B2C :

Considération Un locataire partagé Azure AD B2C Un locataire Azure AD B2C partitionné verticalement Un locataire Azure AD B2C par locataire d’application
Isolation des données Les données de chaque locataire d’application sont stockées dans un seul locataire Azure AD B2C, mais sont accessibles uniquement par les administrateurs Les données de chaque locataire d’application sont distribuées entre plusieurs locataires Azure AD B2C, mais sont accessibles uniquement par les administrateurs Les données de chaque locataire d’application sont stockées dans un locataire Azure AD B2C dédié, mais sont accessibles uniquement par les administrateurs
Complexité du déploiement Faible Moyen à élevé, selon votre stratégie de partitionnement Très élevée
Limites à prendre en compte Demandes par locataire Azure AD B2C, demandes par adresse IP du client Combinaison de demandes, nombre de locataires Azure AD B2C par abonnement et nombre de répertoires pour un seul utilisateur, en fonction de votre stratégie de partitionnement Nombre de locataires Azure AD B2C par abonnement, nombre maximal de répertoires pour un seul utilisateur
Complexité opérationnelle Faible Moyen à élevé, selon votre stratégie de partitionnement Très élevée
Nombre de locataires Azure AD B2C requis Un Entre un et n, en fonction de votre stratégie de partitionnement n, où n est le nombre de locataires d’application
Exemple de scénario Vous créez une offre SaaS pour les consommateurs qui ont peu ou pas d’exigences en matière de résidence des données, comme un service de streaming de musique ou de vidéo. Vous créez une offre SaaS, comme une application de comptabilité et de tenue de dossiers pour les entreprises. Vous devez prendre en charge les exigences en matière de résidence des données ou un grand nombre de fournisseurs d’identité fédérée personnalisée. Vous créez une offre SaaS, comme une application de gestion de dossiers pour les entreprises. Vos clients imposent un degré élevé d’isolation des données des autres locataires d’application.

Un locataire Azure AD B2C

Il est généralement plus facile de gérer un seul locataire partagé Azure AD B2C si vos besoins le permettent. Vous ne devez conserver qu’un seul locataire à long terme, et cette option crée la surcharge la plus faible.

Notes

Nous vous recommandons d’utiliser un locataire Azure AD B2C partagé pour la plupart des scénarios.

Vous devez envisager un locataire Azure AD B2C partagé dans les cas suivants :

  • Vous n’avez pas d’exigences en matière de résidence des données ni d’exigences strictes concernant l’isolation des données.
  • Les exigences de votre application sont dans les limites du service Azure AD B2C.
  • Si vous avez des fournisseurs d’identité fédérée, vous pouvez utiliser la Découverte du domaine d’accueil pour sélectionner automatiquement un fournisseur avec lequel un utilisateur doit se connecter, ou il est possible pour les utilisateurs d’en sélectionner un manuellement dans une liste.
  • Vous disposez d’une expérience de connexion unifiée pour tous les locataires d’application.
  • Vos utilisateurs finaux doivent accéder à plusieurs locataires d’application à l’aide d’un seul compte.

Ce diagramme illustre le modèle de locataire Azure AD B2C partagé :

Diagramme montrant trois applications se connectant à un seul locataire Partagé Azure AD B2C.

Locataires Azure AD B2C partitionnés verticalement

L’approvisionnement de locataires Azure AD B2C partitionnés verticalement est une stratégie conçue pour réduire, si possible, le nombre nécessaire de locataires Azure AD B2C. C’est un juste milieu entre les autres modèles de location. Le partitionnement vertical offre une plus grande flexibilité dans la personnalisation pour des locataires spécifiques lorsque cela est nécessaire. Toutefois, il ne crée pas la surcharge opérationnelle associée à l’approvisionnement d’un locataire Azure AD B2C pour chaque locataire d’application.

Les exigences de déploiement et de maintenance pour ce modèle de location sont supérieures à celles d’un seul locataire Azure AD B2C, mais elles sont inférieures à ce qu’elles sont quand vous utilisez un locataire Azure AD B2C par locataire d’application. Vous devez toujours concevoir et implémenter une stratégie de déploiement et de maintenance pour plusieurs locataires dans votre environnement.

Le partitionnement vertical est similaire au modèle de partitionnement des données. Pour partitionner verticalement vos locataires Azure AD B2C, vous devez organiser vos locataires d’application en groupes logiques. Cette catégorisation des locataires est souvent appelée stratégie de partitionnement. Votre stratégie de partitionnement doit être basée sur un facteur stable et commun du locataire de l’application, comme la région, la taille ou les exigences personnalisées d’un locataire d’application. Par exemple, si votre objectif est de respecter vos exigences en matière de résidence des données, vous pouvez décider de déployer un locataire Azure AD B2C pour chaque région qui héberge des locataires d’application. Ou, si vous regroupez par taille, vous pouvez décider de localiser la plupart des identités de vos locataires d’application sur un seul locataire Azure AD B2C, mais de localiser vos plus grands locataires d’application sur leurs propres locataires Azure AD B2C dédiés.

Important

Évitez de baser votre stratégie de partitionnement sur des facteurs qui peuvent changer au fil du temps, car il est difficile de déplacer des utilisateurs entre des locataires Azure AD B2C. Par exemple, si vous créez une offre SaaS qui a plusieurs références SKU ou niveaux de produit, vous ne devez pas partitionner vos utilisateurs en fonction de la référence SKU qu’ils sélectionnent, car la référence SKU peut changer si le client met à jour son produit.

Vous devez envisager d’approvisionner vos locataires Azure AD B2C à l’aide d’une stratégie partitionnée verticalement si :

  • Vous avez des exigences en matière de résidence des données ou que vous devez séparer vos utilisateurs par zone géographique.
  • Vous disposez d’un grand nombre de fournisseurs d’identité fédérée et vous ne pouvez pas utiliser la Découverte du domaine d’accueil pour en sélectionner automatiquement un pour qu’un utilisateur se connecte.
  • Votre application est, ou peut être, consciente de la multilocation et sait à quel locataire Azure AD B2C vos utilisateurs doivent se connecter.
  • Vous pensez que vos locataires d’application plus importants peuvent atteindre les limites d’Azure AD B2C.
  • Vous disposez d’une stratégie à long terme pour le déploiement et la maintenance d’un nombre moyen à élevé de locataires Azure AD B2C.
  • Vous disposez d’une stratégie pour partitionner vos locataires d’application parmi un ou plusieurs abonnements Azure afin de respecter la limite du nombre de locataires Azure AD B2C pouvant être déployés dans un abonnement Azure.

Le diagramme suivant illustre le modèle de locataire Azure AD B2C partitionné verticalement :

Diagramme montrant trois applications. Deux sont connectés à un locataire Azure AD B2C partagé. Le troisième est connecté à son propre locataire Azure AD B2C.

Un locataire Azure AD B2C par locataire d’application

Si vous approvisionnez un locataire Azure AD B2C pour chaque locataire d’application, vous pouvez personnaliser de nombreux facteurs pour chaque locataire. Toutefois, cette approche crée une augmentation significative de la surcharge. Vous devez développer une stratégie de déploiement et de maintenance pour un nombre potentiellement important de locataires Azure AD B2C.

Vous devez aussi être au fait des limites du service. Les abonnements Azure vous permettent de déployer uniquement un nombre limité de locataires Azure AD B2C. Si vous devez déployer plus que la limite ne le permet, vous devez penser à la conception de l’abonnement appropriée pour être en mesure d’équilibrer vos locataires Azure AD B2C entre plusieurs abonnements. D’autres limites Microsoft Entra s’appliquent également, comme le nombre de répertoires qu’un utilisateur peut créer et le nombre de répertoires auxquels un utilisateur peut appartenir.

Avertissement

En raison de la complexité de cette approche, nous vous recommandons vivement d’examiner d’abord les autres modèles d’isolation. Cette option est incluse ici par souci d’exhaustivité, mais elle n’est pas la bonne approche dans la plupart des cas d’usage.

Une idée fausse et courante consiste à supposer que, si vous utilisez le Modèle d’empreintes de déploiement, vous devez inclure des services d’identité dans chaque empreinte. Ce n’est pas nécessairement vrai, et souvent, vous pouvez utiliser un autre modèle d’isolation à la place. Faites preuve de diligence et disposez d’une justification métier claire si vous utilisez ce modèle d’isolation. La surcharge de déploiement et de maintenance est importante.

Vous devez envisager d’approvisionner un locataire Azure AD B2C pour chaque locataire d’application uniquement si :

  • Vous avez des exigences strictes en matière d’isolation des données pour les locataires d’application.
  • Vous disposez d’une stratégie à long terme pour le déploiement et la maintenance d’un grand nombre de locataires Azure AD B2C.
  • Vous disposez d’une stratégie pour partitionner vos clients parmi un ou plusieurs abonnements Azure afin de vous conformer à la limite Azure AD B2C par locataire par abonnement.
  • Votre application est, ou peut être, consciente de la multilocation et sait à quel locataire Azure AD B2C vos utilisateurs doivent se connecter.
  • Vous devez effectuer une configuration personnalisée pour chaque locataire d’application.
  • Vos utilisateurs finaux n’ont pas besoin d’accéder à plusieurs locataires d’application via le même compte de connexion.

Le diagramme suivant illustre l’utilisation d’un locataire Azure AD B2C par locataire d’application :

Diagramme montrant trois applications, chacune se connectant à son propre locataire Azure AD B2C.

Fédération des identités

Vous devez configurer chaque fournisseur d’identité fédérée, soit via un flux utilisateur, soit dans une stratégie personnalisée. En règle générale, lors de la connexion, les utilisateurs sélectionnent le fournisseur d’identité qu’ils souhaitent utiliser pour s’authentifier. Si vous utilisez un modèle d’isolation de locataire partagé ou si vous avez un grand nombre de fournisseurs d’identité fédérée, envisagez d’utiliser la Découverte du domaine d’accueil pour sélectionner automatiquement un fournisseur d’identité pendant la connexion.

Vous pouvez également utiliser la fédération d’identité comme outil pour gérer plusieurs locataires Azure AD B2C en fédérant les locataires Azure AD B2C entre eux. Cela permet à votre application d’approuver un seul locataire Azure AD B2C. L’application n’a pas besoin de savoir que vos clients sont répartis entre plusieurs locataires Azure AD B2C. Cette approche est la plus couramment utilisée dans le modèle d’isolation partitionné verticalement, lorsque vos utilisateurs sont partitionnés par région. Vous devez tenir compte de certaines considérations si vous adoptez cette approche. Pour obtenir une vue d’ensemble de cette approche, consultez Solutions d’identité globale.

Découverte du domaine d’accueil

La Découverte du domaine d’accueil est le processus de sélection automatique d’un fournisseur d’identité fédérée pour l’événement de connexion d’un utilisateur. Si vous sélectionnez automatiquement le fournisseur d’identité de l’utilisateur, vous n’avez pas besoin d’inviter l’utilisateur à sélectionner un fournisseur.

La Découverte du domaine d’accueil est importante lorsque vous utilisez un locataire Azure AD B2C partagé et que vous permettez également à vos clients d’apporter leur propre fournisseur d’identité fédérée. Vous souhaiterez peut-être éviter une conception dans laquelle un utilisateur doit sélectionner parmi une liste de fournisseurs d’identité. Cela complique le processus de connexion. En outre, un utilisateur peut sélectionner accidentellement la mauvais fournisseur, ce qui entraîne l’échec de la tentative de connexion.

Vous pouvez configurer la Découverte du domaine d’accueil de différentes manières. L’approche la plus courante consiste à utiliser le suffixe de domaine de l’adresse e-mail de l’utilisateur pour déterminer le fournisseur d’identité. Par exemple, supposons que Northwind Traders est un client de la solution multilocataire de Fabrikam. L’adresse e-mail user@northwindtraders.com inclut le suffixe de domaine northwindtraders.com, qui peut être mappé au fournisseur d’identité fédérée Northwind Traders.

Pour plus d’informations, consultez Découverte du domaine d’accueil. Pour obtenir un exemple d’implémentation de cette approche dans Azure AD B2C, consultez le référentiel GitHub d’exemples Azure AD B2C.

Résidence des données

Lorsque vous approvisionnez un locataire Azure AD B2C, vous sélectionnez, à des fins de résidence des données, une région dans laquelle déployer le locataire. Ce choix est important, car il spécifie la région dans laquelle vos données client résident lorsqu’elles sont au repos. Si vous avez des exigences en matière de résidence des données pour un sous-ensemble de vos clients, pensez à utiliser la stratégie partitionnée verticalement.

Autorisation

Pour une solution d’identité forte, vous devez envisager l’autorisation en plus de l’authentification. Il existe plusieurs approches pour utiliser la Plateforme d’identités Microsoft afin de créer une stratégie d’autorisation pour votre application. L’échantillon AppRoles montre comment utiliser des rôles d’application Azure AD B2C pour implémenter l’autorisation dans une application. Il décrit également d’autres approches d’autorisation.

Il n’existe pas d’approche unique en matière d’autorisation, et vous devez tenir compte des besoins de votre application et de vos clients lorsque vous décidez d’une approche.

Maintenance

Lorsque vous planifiez un déploiement multilocataire d’Azure AD B2C, vous devez réfléchir à la maintenance à long terme de vos ressources Azure AD B2C. Un locataire Azure AD B2C, comme votre locataire Microsoft Entra d’organisation, est une ressource nécessaire pour créer, gérer, exploiter et sécuriser. Bien que la liste suivante ne soit pas exhaustive, vous devez tenir compte de la maintenance effectuée dans des domaines comme ceux-ci :

  • Gouvernance du locataire. Qui gère le locataire Azure AD B2C ? De quels rôles élevés ces administrateurs ont-ils besoin ? Comment configurer des stratégies d’accès conditionnel et d’authentification multifacteur pour les administrateurs ? Comment surveillez-vous le locataire Azure AD B2C à long terme ?
  • Configuration du parcours utilisateur. Comment déployer les modifications apportées à votre ou vos locataires Azure AD B2C ? Comment tester les modifications apportées à vos flux d’utilisateur ou à vos stratégies personnalisées avant de les déployer ?
  • Fournisseur d’identité fédérée. Devez-vous ajouter ou supprimer des fournisseurs d’identité au fil du temps ? Si vous autorisez chacun de vos clients à apporter son propre fournisseur d’identité, comment gérer cela à grande échelle ?
  • Inscriptions d’applications. De nombreuses inscriptions d’applications Microsoft Entra utilisent une clé secrète client ou un certificat pour l’authentification. Comment faire pivoter ces clés secrètes ou ces certificats quand vous en avez besoin ?
  • Clés de stratégies. Si vous utilisez des stratégies personnalisées, comment faire pivoter les clés de stratégie quand vous en avez besoin ?
  • Informations d’identification de l’utilisateur. Comment gérez-vous les informations d’utilisateur et les informations d’identification ? Que se passe-t-il si l’un de vos utilisateurs est verrouillé ou oublie un mot de passe et nécessite l’intervention de l’administrateur ou du service clientèle ?

N’oubliez pas que vous devez tenir compte de ces questions pour chaque locataire Azure AD B2C que vous déployez. Vous devez également tenir compte de la façon dont vos processus changent lorsque vous avez plusieurs locataires Azure AD B2C à gérer. Par exemple, le déploiement manuel des modifications de stratégie personnalisées sur un locataire Azure AD B2C est facile, mais leur déploiement manuel sur cinq locataires prend du temps et est risqué.

Déploiements et DevOps

Un processus DevOps bien défini peut vous aider à réduire la surcharge nécessaire à la maintenance de vos locataires Azure AD B2C. Vous devez implémenter des pratiques DevOps au début de votre processus de développement. Dans l’idéal, vous devez essayer d’automatiser la totalité ou la plupart de vos tâches de maintenance, y compris le déploiement des modifications apportées à vos stratégies personnalisées ou à vos flux d’utilisateur. Vous devez également planifier la création de plusieurs locataires Azure AD B2C pour tester progressivement les modifications dans les environnements inférieurs avant de les déployer sur vos locataires de production. Vos pipelines DevOps peuvent effectuer ces activités de maintenance. Vous pouvez utiliser Microsoft API Graph pour gérer vos locataires Azure AD B2C par programmation.

Pour plus d’informations sur les déploiements automatisés et la gestion d’Azure AD B2C, consultez les ressources suivantes.

Important

Certains des points de terminaison utilisés pour gérer Azure AD B2C par programmation ne sont généralement pas disponibles. Les API de la version bêta de Microsoft Graph peuvent être modifiées à tout moment et sont soumises à la préversion des conditions d’utilisation.

Comparaison de Microsoft Entra B2B à Azure AD B2C

Microsoft Entra B2B collaboration est une fonctionnalité de Microsoft Entra External ID que vous pouvez utiliser pour convier des utilisateurs invités dans votre locataire Microsoft Entra d’organisation pour pouvoir collaborer avec eux. En règle générale, vous utilisez B2B Collaboration lorsque vous devez accorder à un utilisateur externe, comme un fournisseur, l’accès aux ressources de votre locataire Microsoft Entra.

Azure AD B2C est un produit unique, distinct de Microsoft Entra External ID, qui offre un ensemble de fonctionnalités différentes. Azure AD B2C est destiné à être utilisé par les clients de votre produit. Votre locataire Azure AD B2C est distinct de votre locataire Microsoft Entra d’organisation.

Selon vos personnages d’utilisateur et vos scénarios, vous devrez peut-être utiliser Microsoft Entra B2B, Azure AD B2C, voire les deux en même temps. Par exemple, si votre application doit authentifier plusieurs types d’utilisateurs, comme le personnel de votre organisation, les utilisateurs qui travaillent pour un fournisseur et des clients, tout cela au sein de la même application, vous pouvez utiliser Microsoft Entra B2B et Azure AD B2C ensemble pour répondre à cette exigence.

Pour plus d'informations, consultez les pages suivantes :

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Autres contributeurs :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes