Partager via

Approches architecturales concernant l’identité dans les solutions multilocataires

Presque toutes les solutions multilocataires nécessitent un système d’identité. Cet article décrit les composants courants de l’identité, notamment l’authentification et l’autorisation, et la façon dont vous pouvez appliquer ces composants dans une solution mutualisée.

Remarque

Avant de commencer à créer un système d’identité pour une solution multilocataire, consultez considérations architecturales relatives à l’identité dans une solution mutualisée.

Authentification

L’authentification est le processus qui établit l’identité d’un utilisateur. Lorsque vous créez une solution mutualisée, tenez compte des différentes approches pour différents aspects du processus d’authentification.

Fédération

Vous devrez peut-être fédérer avec des fournisseurs d’identité externes (IDP). Vous pouvez utiliser la fédération pour activer les scénarios suivants :

  • Connexion sociale, qui permet aux utilisateurs de se connecter avec leur compte Google, Facebook, GitHub ou personnel Microsoft

  • Répertoires spécifiques au locataire, qui permettent aux locataires de fédérer votre application avec leurs propres idPs afin qu’ils n’ont pas besoin de gérer des comptes dans plusieurs emplacements

Pour plus d’informations, consultez le modèle d’identité fédérée.

Si vous choisissez de prendre en charge des IdP spécifiques aux locataires, veillez à clarifier les services et protocoles pris en charge par votre application. Par exemple, déterminez s’il faut prendre en charge le protocole OpenID Connect et le protocole Security Assertion Markup Language, ou s’il faut limiter la fédération aux instances Microsoft Entra ID.

Lorsque vous implémentez un fournisseur d’identité, tenez compte de la mise à l’échelle et des limites qui peuvent s’appliquer. Par exemple, votre fournisseur d’identité peut être en mesure de fédérer avec un nombre limité d’autres fournisseurs d’identité.

Envisagez également de fournir une fédération en tant que fonctionnalité qui s’applique uniquement aux clients à un niveau de produit supérieur.

Authentification unique

L’authentification unique permet aux utilisateurs de basculer entre les applications de manière transparente sans être invités à se réauthentifier à chaque point.

Lorsque les utilisateurs visitent une application, celle-ci les dirige vers un fournisseur d’identité. Si l'IdP détecte une session existante, il émet un nouveau jeton sans obliger les utilisateurs à participer au processus de connexion. Un modèle d’identité fédérée prend en charge l’authentification unique en permettant aux utilisateurs d’utiliser une identité unique sur plusieurs applications.

Dans une solution mutualisée, vous pouvez activer une autre forme d’authentification unique. Si les utilisateurs sont autorisés à accéder aux données entre plusieurs locataires, vous devrez peut-être fournir une expérience transparente lorsque les utilisateurs changent leur contexte d’un locataire à un autre. Déterminez si votre solution doit prendre en charge des transitions transparentes entre les locataires. Si c’est le cas, déterminez si votre fournisseur d’identité doit réémettre des jetons avec des revendications de locataire spécifiques. Par exemple, lorsqu’un utilisateur se connecte au portail Azure, il peut basculer entre différents répertoires d’ID Microsoft Entra. Cette transition déclenche la réauthentification et génère un nouveau jeton à partir de l’instance Microsoft Entra ID nouvellement sélectionnée.

Évaluation des risques de connexion

Les plateformes d’identité modernes prennent en charge une évaluation des risques pendant le processus de connexion. Par exemple, si un utilisateur se connecte à partir d’un emplacement ou d’un appareil inhabituel, le système d’authentification peut nécessiter des vérifications d’identité supplémentaires, telles que l’authentification multifacteur (MFA), avant d’autoriser la demande de connexion à continuer.

Déterminez si vos locataires peuvent avoir des stratégies de risque différentes qui doivent être appliquées pendant le processus d’authentification. Par exemple, si vous avez des locataires dans un secteur hautement réglementé, ils peuvent avoir des profils de risque et des exigences différents que les locataires qui travaillent dans des environnements moins réglementés. Vous pouvez également autoriser les locataires à des niveaux tarifaires plus élevés à spécifier des stratégies de connexion plus restrictives que les locataires qui achètent un niveau inférieur de votre service.

Si vous devez prendre en charge différentes stratégies de risque pour chaque locataire, votre système d'authentification doit savoir à quel locataire l'utilisateur se connecte afin de pouvoir appliquer les stratégies appropriées.

Si votre fournisseur d’identité inclut ces fonctionnalités, envisagez d’utiliser les fonctionnalités d’évaluation des risques de connexion native du fournisseur d’identité. Ces caractéristiques peuvent être complexes à implémenter soi-même et sujettes aux erreurs.

Sinon, si vous vous fédérez aux fournisseurs d’identité des locataires, leurs politiques de gestion des connexions à risque peuvent être appliquées, ce qui leur permet de gérer les stratégies et les contrôles d’application. Par exemple, la nécessité de deux défis MFA, l’un du fournisseur d’identité de l’utilisateur et l’autre de votre propre, peuvent rendre le processus de connexion plus difficile. Assurez-vous de bien comprendre comment la fédération interagit avec chaque fournisseur d'identité (IdP) de votre locataire et les règles qu'ils ont mises en place.

Usurpation d'identité

L’emprunt d’identité permet à un utilisateur de supposer l’identité d’un autre utilisateur sans utiliser les informations d’identification de cet utilisateur.

L’emprunt d’identité est généralement dangereux et peut être difficile à implémenter et contrôler. Toutefois, dans certains scénarios, l'usurpation d'identité est requise. Par exemple, si vous utilisez un environnement SaaS (Software as a Service), votre personnel du support technique peut avoir besoin d’assumer l’identité d’un utilisateur afin qu’il puisse se connecter en tant qu’utilisateur et résoudre un problème.

Si vous implémentez l’emprunt d’identité, envisagez d’auditer son utilisation. Assurez-vous que vos journaux incluent à la fois l’utilisateur qui a effectué l’action et l’identificateur de l’utilisateur pour lequel il se faisait passer.

Certaines plateformes d’identité prennent en charge l’emprunt d’identité, soit en tant que fonctionnalité intégrée, soit en utilisant du code personnalisé. Par exemple, vous pouvez ajouter une revendication personnalisée dans Microsoft Entra External ID pour l'ID d'utilisateur représenté, ou vous pouvez remplacer la revendication d'identificateur de sujet dans les jetons émis.

Autorisation

L’autorisation est le processus de détermination de ce qu’un utilisateur est autorisé à faire.

Les données d’autorisation peuvent être stockées dans plusieurs emplacements, notamment dans les emplacements suivants :

  • Dans votre fournisseur d’identité : Par exemple, si vous utilisez l’ID Microsoft Entra comme fournisseur d’identité, vous pouvez utiliser des fonctionnalités telles que des rôles d’application et des groupes pour stocker les informations d’autorisation. Votre application peut ensuite utiliser les revendications de jeton associées pour appliquer vos règles d’autorisation.

  • Dans votre application : Vous pouvez créer votre propre logique d’autorisation, puis stocker des informations sur ce que chaque utilisateur peut faire dans une base de données ou un système de stockage similaire. Vous pouvez ensuite concevoir des contrôles affinés pour l’autorisation au niveau du rôle ou au niveau des ressources.

Dans la plupart des solutions mutualisées, le client ou le locataire gère les attributions de rôle et d’autorisation, et non le fournisseur du système multilocataire.

Ajouter des informations sur l’identité et le rôle du locataire aux jetons

Déterminez quelles parties de votre solution doivent gérer les demandes d’autorisation. Évaluez s’il faut autoriser un utilisateur à accéder aux données d’un locataire spécifique.

Une approche courante consiste pour votre système d’identité à intégrer une déclaration d’identificateur de client dans un jeton. Cette approche permet à votre application d’inspecter la revendication et de vérifier que les utilisateurs travaillent avec le locataire auquel ils sont autorisés à accéder. Si vous utilisez le modèle de sécurité en fonction du rôle, vous pouvez étendre le jeton pour inclure des informations sur le rôle de l’utilisateur au sein du locataire.

Toutefois, si un seul utilisateur est autorisé à accéder à plusieurs locataires, vous devrez peut-être indiquer avec quel locataire il envisage de travailler pendant le processus de connexion. Une fois que l’utilisateur a sélectionné son locataire actif, le fournisseur d’identité peut émettre un jeton qui inclut la revendication et le rôle d’identificateur de locataire appropriés pour ce locataire. Vous devez également prendre en compte la façon dont les utilisateurs peuvent basculer entre les locataires, ce qui nécessite l’émission d’un nouveau jeton.

Autorisation basée sur les applications

Une autre approche consiste à rendre le système d’identité indépendant des identificateurs de locataire et des rôles. Les utilisateurs sont identifiés par le biais de leurs identifiants ou d’une relation de fédération, et les jetons n’incluent pas de revendication d'identifiant de locataire. Une liste ou une base de données distincte maintient les enregistrements des utilisateurs auxquels l'accès est accordé pour chaque entité. La couche Application vérifie ensuite si un utilisateur spécifié est autorisé à accéder aux données d’un locataire spécifique en fonction de cette liste.

Utiliser l’ID Microsoft Entra ou l’ID externe

Microsoft Entra ID et ID externe sont des plateformes d’identité managées que vous pouvez utiliser dans votre propre solution multilocataire.

De nombreuses solutions mutualisées fonctionnent en tant que SaaS. Votre choix d’utiliser l’ID Microsoft Entra ou l’ID externe dépend en partie de la façon dont vous définissez vos locataires ou base de clients.

Important

Azure AD B2C prend également en charge la plupart des scénarios de cet article. Toutefois, depuis le 1er mai 2025, il n’est plus disponible pour l’achat de nouveaux clients. Nous ne le recommandons donc pas pour les nouvelles solutions. Pour plus d’informations, consultez faq sur Azure AD B2C.

Antimodèles à éviter

Création ou gestion de votre propre système d’identité

La création d’une plateforme d’identité moderne est complexe. Elle nécessite une prise en charge d’une gamme de protocoles et de normes, et une implémentation incorrecte peut introduire des vulnérabilités de sécurité. Étant donné que les normes et les protocoles changent, vous devez continuellement mettre à jour votre système d’identité pour atténuer les attaques et incorporer les dernières fonctionnalités de sécurité. Il est également important de s’assurer qu’un système d’identité est résilient, car tout temps d’arrêt peut avoir des conséquences graves pour le reste de votre solution. Dans la plupart des scénarios, la mise en œuvre d'un fournisseur d'identité ne profite pas directement à l'entreprise, mais elle est nécessaire pour implémenter un service multilocataire. Il est préférable d’utiliser un système d’identité spécialisé que les experts créent, fonctionnent et sécurisent.

Lorsque vous exécutez votre propre système d’identité, vous devez stocker des hachages de mot de passe ou d’autres formes d’informations d’identification, qui deviennent une cible tentante pour les attaquants. Même le hachage et le sel des mots de passe sont souvent insuffisants, car les attaquants disposent d’une puissance de calcul suffisante pour compromettre potentiellement ces informations d’identification.

Lorsque vous exécutez un système d’identité, vous êtes responsable de la génération et de la distribution de codes MFA ou de mot de passe à usage unique. Vous avez besoin d’un mécanisme pour envoyer ces codes via SMS ou e-mail. Vous êtes également responsable de la détection des attaques ciblées et par force brute, de la limitation des tentatives de connexion et de la maintenance des journaux d’audit.

Au lieu de créer ou de gérer votre propre système d’identité, il est préférable d’utiliser un service ou un composant prédéfini. Par exemple, envisagez des plateformes d’identité managée comme l’ID Microsoft Entra ou l’ID externe. Les fournisseurs de ces plateformes sont responsables de l’exploitation de l’infrastructure et garantissent généralement la prise en charge des normes d’identité et d’authentification actuelles.

Échec de la prise en compte des exigences de vos locataires

Les locataires ont souvent des préférences fortes sur la gestion de l’identité dans les solutions qu’ils utilisent. Par exemple, de nombreux clients d’entreprise nécessitent une fédération avec leurs propres idPs pour activer l’authentification unique et éviter de gérer plusieurs ensembles d’informations d’identification. D’autres locataires peuvent nécessiter une authentification multifacteur ou des mesures de sécurité supplémentaires pour le processus de connexion. Si vous ne tenez pas compte de ces exigences lors de la conception, l’ajout de ces exigences ultérieurement peut être difficile.

Veillez à comprendre les exigences d’identité de vos locataires avant de finaliser la conception de votre système d’identité. Pour plus d’informations sur les exigences spécifiques, consultez Considérations architecturales relatives à l’identité dans une solution mutualisée.

Confondre les utilisateurs et les locataires

Il est important de prendre clairement en compte la façon dont votre solution définit un utilisateur et un locataire. Dans de nombreux scénarios, la relation peut être complexe. Par exemple, un locataire peut contenir plusieurs utilisateurs, et un seul utilisateur peut rejoindre plusieurs locataires.

Assurez-vous que vous disposez d’un processus clair pour le suivi du contexte client au sein de votre application et des demandes. Dans certains scénarios, ce processus vous oblige à inclure un identificateur de locataire dans chaque jeton d’accès et à le valider sur chaque requête. Dans d’autres cas, les informations d’autorisation du locataire sont stockées séparément des identités utilisateur. Cette approche nécessite un système d’autorisation plus complexe pour gérer les utilisateurs qui peuvent effectuer des opérations spécifiques au sein de chaque locataire.

Le suivi du contexte de locataire d’un utilisateur ou d’un jeton s’applique à n’importe quel modèle de location , car une identité utilisateur a toujours un contexte de locataire dans une solution mutualisée. Il est recommandé de suivre le contexte du locataire lorsque vous déployez des instances indépendantes pour un seul locataire, ce qui prépare votre base de code pour l'avenir et pour d'autres formes de multilocation.

Confondre l'autorisation de rôle et l'autorisation de ressources

Il est important de choisir un modèle d’autorisation qui correspond à votre solution. La sécurité basée sur les rôles est simple à implémenter, mais l’autorisation basée sur les ressources fournit un contrôle plus précis. Évaluez les exigences de vos locataires et déterminez s’ils doivent autoriser certains utilisateurs à accéder uniquement à des parties spécifiques de votre solution.

Échec de l’écriture des journaux d’audit

Les journaux d’audit constituent un outil important pour comprendre votre environnement et comment les utilisateurs implémentent votre système. En auditant chaque événement lié à l’identité, vous pouvez souvent déterminer si votre système d’identité est en cours d’attaque et vous pouvez examiner la façon dont votre système est utilisé. Vérifiez que vous écrivez et stockez les journaux d’audit dans votre système d’identité. Déterminez si les journaux d’audit des identités de votre solution doivent être mis à la disposition des locataires à examiner.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Principaux auteurs :

Autres contributeurs :

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