Considérations architecturales relatives à l’identité dans une solution multilocataire

L’identité est un aspect important de toute solution à locataires multiples. Les composants d’identité de votre application sont responsables des tâches suivantes :

• Vérification de l’identité d’un utilisateur, appelée authentification

• Application des autorisations de l’utilisateur dans l’étendue d’un locataire, appelée autorisation.

Vos clients peuvent également souhaiter autoriser des applications externes à accéder à leurs données ou à s’intégrer à votre solution. L’identité d’un utilisateur détermine quelles informations un utilisateur ou un service peut accéder. Il est important que vous considériez vos exigences d’identité pour isoler votre application et vos données entre les locataires.

Avant de définir une stratégie d’identité multilocataire, tenez d’abord compte des exigences d’identité générales suivantes pour votre service :

• Déterminez si les utilisateurs ou les identités de charge de travail accèdent à une application unique ou plusieurs applications au sein d’une famille de produits. Certaines familles de produits peuvent inclure des applications distinctes qui partagent la même infrastructure d’identité, comme les systèmes de point de vente et les plateformes de gestion des stocks.

• Déterminez si votre solution implémente des normes d’authentification et d’autorisation modernes, telles que OAuth2 et OpenID Connect.

• Déterminez si l’authentification est limitée aux applications basées sur l’interface utilisateur ou si l’accès à l’API s’applique également aux locataires et aux systèmes tiers.

• Déterminez si les locataires doivent se fédérer avec leur propre fournisseur d’identité et si plusieurs fournisseurs d’identité doivent être pris en charge pour chaque locataire. Par exemple, vous pouvez avoir des locataires avec microsoft Entra ID, Auth0 et Active Directory Federation Services où chaque locataire fédère avec votre solution. Identifiez les protocoles de fédération utilisés par leurs IdP, car ces protocoles déterminent ce que votre IdP doit prendre en charge.

• Passez en revue les exigences de conformité applicables qu’elles doivent respecter, telles que le Règlement général sur la protection des données (RGPD), qui forment votre stratégie d’identité.

• Déterminez si les locataires exigent que les données d’identité soient stockées dans des régions géographiques spécifiques pour répondre aux besoins juridiques, de conformité ou opérationnels.

• Évaluez si les utilisateurs accèdent aux données de plusieurs locataires au sein de l’application. Si tel est le cas, vous devrez peut-être assurer le changement de locataire transparent ou fournir des vues consolidées entre les locataires pour des utilisateurs spécifiques. Par exemple, les utilisateurs qui se connectent au portail Azure peuvent facilement basculer entre différents répertoires d’ID Microsoft Entra et les abonnements auxquels ils ont accès.

Lorsque vous établissez vos exigences générales, vous pouvez commencer à planifier des détails et des exigences plus spécifiques, tels que les sources d’annuaire utilisateur et les flux d’inscription et de connexion.

Répertoire d’identité

Pour qu’une solution multilocataire s’authentifie et autorise un utilisateur ou un service, elle a besoin d’un emplacement pour stocker les informations d’identité. Un répertoire peut inclure des enregistrements faisant autorité pour chaque identité. Ou il peut contenir des références à des identités externes stockées dans le répertoire d’un autre IdP.

Lorsque vous concevez un système d’identité pour votre solution multilocataire, vous devez prendre en compte les types de fournisseurs d’identité suivants dont vos locataires et clients peuvent avoir besoin :

• Fournisseur d’identité local : Un fournisseur d’identité local permet aux utilisateurs de se créer un compte pour accéder au service. Les utilisateurs fournissent un nom d’utilisateur, une adresse e-mail ou un identificateur, tel qu’un numéro de carte de réduction. Ils fournissent également des informations d’identification, comme un mot de passe. Le fournisseur d’identité stocke à la fois l’identificateur de l’utilisateur et les informations d’identification.

• Fournisseur d’identité sociale : Un fournisseur d’identité sociale permet aux utilisateurs d’utiliser une identité qu’ils ont sur un réseau social ou un autre fournisseur d’identité public, tel que Facebook, Google ou un compte Microsoft personnel. Les fournisseurs d’identité sociaux sont couramment utilisés dans les solutions SaaS B2C.

• Répertoire Microsoft Entra ID du locataire : Dans de nombreuses solutions SaaS (B2B) métier, les locataires peuvent déjà avoir leur propre répertoire d’ID Microsoft Entra, et ils souhaitent peut-être que votre solution utilise son répertoire comme fournisseur d’identité pour accéder à votre solution. Cette approche est possible lorsque votre solution est conçue en tant qu'application Microsoft Entra multilocataire.

• Fédération avec le fournisseur d’identité d’un locataire : dans certaines solutions SaaS B2B, les locataires peuvent vouloir utiliser leur propre fournisseur d’identité pour fédérer leur solution, au lieu de Microsoft Entra ID. La fédération active l’authentification unique (SSO). Il permet également aux locataires de gérer le cycle de vie et les stratégies de sécurité de leurs utilisateurs indépendamment de votre solution.

Déterminez si vos locataires doivent prendre en charge plusieurs fournisseurs d’identité. Par exemple, un seul locataire peut avoir besoin de prendre en charge les identités locales, les identités sociales et les identités fédérées. Cette exigence est typique lorsque les entreprises utilisent une solution destinée à leurs employés et à leurs sous-traitants. Ils peuvent utiliser la fédération pour accorder l'accès aux employés, tout en autorisant l'accès aux sous-traitants ou aux utilisateurs qui n'ont pas de comptes chez le fournisseur d'identités fédérées.

Stocker les informations d’authentification et d’autorisation du locataire

Dans une solution multilocataire, vous devez prendre en compte où stocker plusieurs types d’informations d’identité, notamment les types suivants :

• Détails sur les comptes d’utilisateur et de service, y compris leurs noms et autres informations dont vos locataires ont besoin.

• Informations requises pour authentifier en toute sécurité vos utilisateurs, y compris les informations relatives à l’authentification multifacteur (MFA).

• Informations spécifiques au client, telles que les rôles de client et les permissions, pour gérer les autorisations.

Tenez compte des options suivantes pour stocker les informations d’identité :

• Stocker toutes les informations d’identité et d’autorisation dans le répertoire de fournisseurs d’identité et les partager entre plusieurs locataires.

• Stockez les informations d’identification de l’utilisateur dans le répertoire IdP. Stockez les données d’autorisation dans la couche Application, ainsi que les informations du locataire.

Déterminer le nombre d’identités pour un utilisateur

Les solutions multilocataires permettent souvent à un utilisateur ou à une identité de charge de travail d’accéder aux ressources d’application et aux données sur plusieurs locataires. Lorsque cette approche est requise, tenez compte des facteurs suivants :

• Déterminez s’il faut créer une identité d’utilisateur unique pour chaque personne ou créer des identités distinctes pour chaque combinaison d’utilisateurs locataires.

  • Utilisez une identité unique pour chaque personne si possible. Il simplifie la gestion des comptes pour le fournisseur de solutions et les utilisateurs. En outre, la plupart des protections intelligentes contre les menaces que les fournisseurs d’identité modernes fournissent reposent sur chaque personne ayant un seul compte d’utilisateur.

  • Utilisez plusieurs identités distinctes dans certains scénarios. Par exemple, si les utilisateurs utilisent votre système à des fins professionnelles et personnelles, ils peuvent vouloir séparer leurs comptes d’utilisateur. Ou si vos locataires ont des exigences strictes en matière de stockage des données réglementaires ou géographiques, ils peuvent exiger qu’une personne dispose de plusieurs identités afin qu’elle puisse se conformer aux réglementations ou aux lois.

• Évitez de stocker des informations d’identification plusieurs fois si vous utilisez des identités par locataire. Les utilisateurs doivent disposer de leurs informations d’identification stockées sur une seule identité. Vous devez utiliser des fonctionnalités telles que les identités invitées pour faire référence aux mêmes informations d’identification utilisateur des enregistrements d’identité de plusieurs locataires.

Accorder aux utilisateurs l’accès aux données client

Réfléchissez à la façon dont vous envisagez d'associer des utilisateurs à un locataire. Par exemple, pendant le processus d’inscription, vous pouvez fournir un code d’invitation unique pour que les utilisateurs entrent lorsqu’ils accèdent à un locataire pour la première fois. Dans certaines solutions, le nom de domaine de l’adresse e-mail d’inscription de l’utilisateur peut identifier son locataire associé. Vous pouvez également utiliser un autre attribut de l’enregistrement d’identité de l’utilisateur pour déterminer le mappage du locataire. Cette association doit ensuite être stockée en fonction d’identificateurs uniques immuables pour le locataire et l’utilisateur.

Si votre solution limite à chaque utilisateur l’accès aux données d’un seul locataire, tenez compte des décisions suivantes :

• Déterminez comment l'IdP détecte le locataire auquel un utilisateur accède.

• Expliquez comment le fournisseur d’identité communique l’identificateur du locataire à l’application. En règle générale, une revendication d’identificateur de locataire est ajoutée au jeton.

Si un seul utilisateur doit avoir accès à plusieurs locataires, tenez compte des décisions suivantes :

• La solution doit prendre en charge la logique permettant d’identifier les utilisateurs et d’accorder les autorisations appropriées entre les locataires. Par exemple, un utilisateur peut avoir des droits d’administration dans un locataire, mais un accès limité dans un autre locataire. Par exemple, supposons qu’un utilisateur s’est inscrit à une identité sociale et qu’il a ensuite obtenu l’accès à deux locataires. Le locataire A a enrichi l’identité de l’utilisateur avec davantage d’informations. Le locataire B doit-il avoir accès aux informations enrichies ?

• Un mécanisme clair doit permettre aux utilisateurs de basculer entre les locataires. Cette approche garantit une expérience utilisateur fluide et empêche l’accès accidentel entre locataires.

• Les identités de charge de travail, le cas échéant, doivent spécifier le locataire auquel elles tentent d’accéder. Cette exigence peut inclure l’incorporation d’un contexte spécifique au locataire dans les demandes d’authentification.

• Déterminez si les informations spécifiques au locataire stockées dans l’enregistrement d’identité d’un utilisateur peuvent involontairement fuiter entre les locataires. Par exemple, si un utilisateur s’inscrit avec une identité sociale et obtient l’accès à deux locataires, et que le locataire A enrichit le profil utilisateur, détermine si le locataire B doit avoir accès à ces informations enrichies.

Processus d’inscription de l’utilisateur pour les identités locales ou les identités sociales

Certains clients peuvent avoir besoin de permettre aux utilisateurs de créer eux-mêmes une identité dans votre solution. L’inscription en libre-service peut être requise si vous n’avez pas besoin de fédération avec le fournisseur d’identité d’un locataire. Si un processus d’inscription automatique est nécessaire, vous devez prendre en compte les facteurs suivants :

• Définissez les sources d’identité auxquelles les utilisateurs sont autorisés à s’inscrire. Par exemple, déterminez si les utilisateurs peuvent créer une identité locale et utiliser un fournisseur d’identité social.

• Spécifiez si votre solution autorise uniquement des domaines de messagerie spécifiques si des identités locales sont utilisées. Par exemple, déterminez si un locataire peut restreindre les inscriptions aux utilisateurs avec une @contoso.com adresse e-mail.

• Le nom d’utilisateur principal (UPN) utilisé pour identifier les identités locales doit être clairement établi. Les UPN courants incluent des adresses e-mail, des noms d’utilisateur, des numéros de téléphone ou des identificateurs d’appartenance. Étant donné que les UPN peuvent changer, il est conseillé de référencer l’identificateur unique immuable sous-jacent pour l’autorisation et l’audit. Par exemple, l’ID d’objet (OID) dans Microsoft Entra ID.

• La vérification des UPN peut être nécessaire pour garantir leur exactitude. Ce processus peut inclure la validation de la propriété d’une adresse e-mail ou d’un numéro de téléphone avant d’accorder l’accès.

• Certaines solutions peuvent exiger que les administrateurs clients approuvent les inscriptions des utilisateurs. Ce processus d’approbation permet un contrôle administratif sur les personnes qui rejoignent un locataire.

• Déterminez si les locataires nécessitent une expérience d’inscription ou une URL spécifique au locataire. Par exemple, déterminez si vos locataires nécessitent une expérience d’inscription personnalisée lorsque les utilisateurs s’inscrivent, ou la possibilité d’intercepter une demande d’inscription et d’effectuer une validation supplémentaire avant de continuer.

Accès au locataire pour les utilisateurs d’inscription automatique

Si les utilisateurs peuvent s'inscrire pour un compte utilisateur, définissez un processus pour leur accorder l'accès à un locataire. Le flux d’inscription peut inclure un processus d’octroi d’accès manuel ou un processus automatisé en fonction des informations sur les utilisateurs, telles que leurs adresses e-mail. Il est important de planifier ce processus et de prendre en compte les facteurs suivants :

• Définissez la façon dont le flux d’inscription détermine qu’un utilisateur a accès à un locataire spécifique.

• Définissez si votre solution révoque automatiquement l’accès utilisateur à un locataire le cas échéant. Par exemple, lorsque les utilisateurs quittent une organisation, il doit y avoir un processus manuel ou automatisé en place pour supprimer leur accès.

• Fournissez une fonctionnalité d’audit utilisateur afin que les locataires puissent examiner quels utilisateurs ont accès à leur environnement et comprendre leurs autorisations attribuées.

Gestion automatisée du cycle de vie des comptes

Une exigence courante pour les clients d'entreprise d'une solution est un ensemble de fonctionnalités qui leur permettent d'automatiser l'intégration et la désactivation des comptes. Les protocoles ouverts, tels que System for Cross-Domain Identity Management (SCIM), fournissent une approche standard de l’automatisation. Ce processus automatisé inclut généralement la création et la suppression d’enregistrements d’identité et la gestion des autorisations de locataire. Tenez compte des facteurs suivants lorsque vous implémentez la gestion automatisée du cycle de vie des comptes dans une solution mutualisée :

• Déterminez si vos clients doivent configurer et gérer un processus de cycle de vie automatisé pour chaque locataire. Par exemple, lorsqu’un utilisateur est intégré, vous devrez peut-être créer l’identité au sein de plusieurs locataires de votre application, où chaque locataire dispose d’un ensemble d’autorisations différent.

• Déterminez si vous devez implémenter SCIM ou une fédération d’offre. La fédération permet aux locataires de conserver le contrôle sur la gestion des utilisateurs en conservant la source de vérité dans leurs propres systèmes au lieu de gérer les utilisateurs locaux dans votre solution.

Processus d’authentification de l’utilisateur

Lorsqu’un utilisateur se connecte à une application multilocataire, votre système d’identité authentifie l’utilisateur. Tenez compte des facteurs suivants lorsque vous planifiez votre processus d’authentification :

• Certains locataires peuvent nécessiter la possibilité de configurer leurs propres stratégies MFA. Par exemple, si vos locataires se trouvent dans le secteur des services financiers, ils doivent mettre en œuvre des stratégies MFA strictes, tandis qu’un petit détaillant en ligne n’a peut-être pas les mêmes exigences.

• L’option permettant de définir des règles d’accès conditionnel personnalisées peut être importante pour les locataires. Par exemple, différents locataires peuvent avoir besoin de bloquer les tentatives de connexion à partir de régions géographiques spécifiques.

• Déterminez si les locataires doivent personnaliser le processus de connexion individuellement. Par exemple, votre solution peut avoir besoin d’afficher le logo d’un client. Ou il peut être nécessaire de récupérer des informations utilisateur, telles qu’un numéro de récompense, à partir d’un autre système et de le retourner au fournisseur d’identité pour enrichir le profil utilisateur.

• Certains utilisateurs peuvent avoir besoin d’emprunter l’identité d’autres utilisateurs. Par exemple, un membre de l’équipe de support technique peut souhaiter examiner un problème qu’un autre utilisateur a en empruntant l’identité de son compte d’utilisateur sans avoir à s’authentifier en tant qu’utilisateur.

• L’accès à l’API peut être requis pour certains utilisateurs ou applications externes. Ces scénarios peuvent inclure l’appel direct des API de la solution, qui contournent les flux d’authentification utilisateur standard.

Identités de charge de travail

Dans la plupart des solutions, une identité représente souvent un utilisateur. Certains systèmes multilocataires permettent également aux identités de charge de travail d’être utilisées par les services et les applications pour accéder à vos ressources d’application. Par exemple, vos locataires peuvent avoir besoin d’accéder à une API que votre solution fournit afin qu’elles puissent automatiser leurs tâches de gestion.

Microsoft Entra prend également en charge les identités de charge de travail, tout comme d’autres fournisseurs d’identité.

Les identités de charge de travail sont similaires aux identités utilisateur, mais elles nécessitent généralement différentes méthodes d’authentification, telles que des clés ou des certificats. Les identités de charge de travail n’utilisent pas l’authentification multifacteur. Au lieu de cela, les identités de charge de travail nécessitent généralement d’autres contrôles de sécurité, tels que le déploiement de clés et l’expiration régulière du certificat.

Si vos locataires peuvent activer l’accès des identités de charge de travail à votre solution multilocataire, vous devez prendre en compte les facteurs suivants :

• Déterminez comment les identités de charge de travail sont créées et gérées dans chaque locataire.

• Décidez comment les demandes d’identité de charge de travail seront étendues au locataire.

• Évaluez si vous devez limiter le nombre d’identités de charge de travail créées par chaque locataire.

• Déterminez si des contrôles d'accès conditionnel sont nécessaires pour les identités de charge de travail dans chaque locataire. Par exemple, un locataire peut vouloir empêcher qu'une identité de charge de travail soit authentifiée depuis l'extérieur d'une région spécifique.

• Identifiez les contrôles de sécurité que vous fournissez aux locataires pour vous assurer que les identités de charge de travail restent sécurisées. Par exemple, la rotation automatique des clés, l’expiration des clés, l’expiration des certificats et la surveillance des risques de connexion permettent de réduire le risque d’abus des identités de charge de travail.

Fédération avec un fournisseur d’identité pour l’authentification unique

Les locataires qui ont déjà leurs propres répertoires d’utilisateurs peuvent souhaiter que votre solution soit fédérée avec leurs répertoires. La fédération permet à votre solution d’utiliser les identités dans leur répertoire au lieu de gérer un autre répertoire avec des identités distinctes.

La fédération est particulièrement importante lorsque certains locataires souhaitent spécifier leurs propres stratégies d’identité ou activer des expériences d’authentification unique.

Si vous attendez des locataires à fédérer avec votre solution, tenez compte des facteurs suivants :

• Tenez compte du processus de configuration de la fédération pour un locataire. Déterminez si les locataires configurent eux-mêmes la fédération ou si le processus nécessite une configuration et une maintenance manuelles par votre équipe.

• Définissez les protocoles de fédération pris en charge par votre solution.

• Établissez des processus qui empêchent les erreurs de configuration de fédération d’accorder l’accès à des locataires inattendus.

• Déterminez si l'IdP d'un locataire unique doit être fédéré à plusieurs locataires dans votre solution. Par exemple, si les clients ont à la fois un locataire de formation et de production, ils peuvent avoir besoin de fédérer le même fournisseur d’identité avec chaque locataire.

Modèles d’autorisation

Décidez du modèle d’autorisation qui est le plus judicieux pour votre solution. Tenez compte des approches d’autorisation courantes suivantes :

• Autorisation basée sur les rôles : Les utilisateurs sont affectés aux rôles. Certaines fonctionnalités de l’application sont limitées à des rôles spécifiques. Par exemple, un utilisateur du rôle administrateur peut effectuer n’importe quelle action, tandis qu’un utilisateur dans un rôle inférieur peut avoir un sous-ensemble d’autorisations dans tout le système.

• Autorisation basée sur les ressources : Votre solution fournit un ensemble de ressources distinctes, chacune ayant son propre ensemble d’autorisations. Un utilisateur spécifique peut être un administrateur d’une ressource et n’a pas accès à une autre ressource.

Ces modèles sont distincts et l’approche que vous sélectionnez affecte votre implémentation et la complexité des stratégies d’autorisation que vous pouvez implémenter.

Droits et licences

Dans certaines solutions, vous pourriez utiliser des licences par utilisateur dans le cadre de votre modèle tarifaire commercial. Dans ce scénario, vous fournissez différents niveaux de licences utilisateur qui ont des fonctionnalités différentes. Par exemple, les utilisateurs disposant d’une licence peuvent être autorisés à utiliser un sous-ensemble des fonctionnalités de l’application. Les fonctionnalités auxquelles des utilisateurs spécifiques sont autorisés à accéder, en fonction de leurs licences, sont parfois appelées droits.

Nous vous recommandons de suivre et d’appliquer les droits au sein de votre code d’application ou d’un système de droits dédiés, plutôt que de vous appuyer sur le système d’identité. Ce processus est similaire à l’autorisation, mais se produit en dehors de la couche de gestion des identités.

Il existe plusieurs raisons pour cette séparation :

• Complexité des modèles de licence : Les règles de licence sont souvent complexes et spécifiques au modèle métier. Par exemple, les licences peuvent être par siège, basées sur le temps (affectation quotidienne ou mensuelle), limiter l’utilisation simultanée ou avoir des règles de réaffectation spécifiques. Les fournisseurs d’identité sont généralement conçus pour l’authentification utilisateur et l’autorisation de base, et non pour une logique de licence commerciale complexe.

• Indépendance: L’utilisation des fonctionnalités du fournisseur d’identité pour la gestion des licences peut verrouiller votre solution dans ce fournisseur ou ses contraintes. Si vous prenez en charge les clients qui utilisent différents fournisseurs d’identité, vous devez créer une solution personnalisée pour eux de toute façon.

Un modèle courant consiste à gérer les licences au sein de la base de données de l’application ou d’un service dédié. Lorsqu’un utilisateur se connecte, le fournisseur d’identité récupère ses droits et les injecte dans le jeton d’autorisation en tant que revendications personnalisées qui peuvent être vérifiées par les composants de l’application au moment de l’exécution.

Échelle d'identité et volume d'authentification

À mesure que les solutions mutualisées augmentent, le nombre d’utilisateurs et de demandes de connexion dont la solution a besoin pour traiter augmente. Évaluez ces considérations d’extensibilité :

• Déterminez si l’annuaire utilisateur est mis à l’échelle pour prendre en charge le nombre requis d’utilisateurs.

• Évaluez si le processus d’authentification gère le nombre attendu de connexions et d’inscriptions.

• Déterminez s’il existe des pics que le système d’authentification ne peut pas gérer. Par exemple, à 9 heures du Pacifique, tout le monde dans l’ouest des États-Unis peut commencer à travailler et se connecter à votre solution, ce qui crée un pic de demandes de connexion. Ces scénarios sont parfois appelés tempêtes de connexion.

• Déterminez si la charge élevée dans certaines parties de votre solution affecte les performances du processus d’authentification. Par exemple, si l’authentification nécessite l’appel à une API de niveau application, une augmentation des demandes d’authentification peut affecter les performances globales du système.

• Définissez le comportement de votre solution si l'IdP devient indisponible. Déterminez si un service d’authentification de sauvegarde doit être inclus pour maintenir la continuité de l’activité.

Contributeurs

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

Principaux auteurs :

• John Downs | Ingénieur logiciel principal, modèles Azure & Pratiques
• Daniel Scott-Raynsford | Stratégiste de la technologie des partenaires
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure

Autres contributeurs :

• Jelle Druyts | Ingénieur client principal, FastTrack for Azure
• Landon Pierce | Ingénieur client senior
• Sander van den Hoven | Stratégiste senior de la technologie des partenaires
• Nick Ward | Architecte senior de solutions Cloud

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

Ressource associée

• Approches architecturales pour l’identité dans les solutions mutualisées