Partager via

Considérations architecturales pour une solution multilocataire

  • Article

L’identité est un aspect important de toute solution IoT. Les composants d’identité de votre application sont responsables des deux éléments suivants :

  • Vérification de l’identité d’un utilisateur (authentification).
  • Application des autorisations de l’utilisateur dans l’étendue d’un locataire (autorisation).

Vos clients peuvent également autoriser des applications externes à accéder à leurs données ou à s’intégrer à votre solution. L’identité d’un utilisateur détermine les informations à laquelle un utilisateur ou un service accède. Il est important que vous considériez vos besoins en matière d’identité afin d’isoler votre application et vos données entre les locataires.

Attention

Les services d’authentification et d’autorisation, dans les applications multilocataires et SaaS, sont généralement fournis par un fournisseur d’identité tiers (IdP). Un fournisseur d’identité fait généralement partie intégrante d’une plateforme IDaaS (Identity as a Service).

La création de votre propre fournisseur d’identité est complexe, coûteuse et difficile à construire en toute sécurité. La création de votre propre fournisseur d’identité est un antimodèle. Nous ne le recommandons pas.

Avant de définir une stratégie d’identité multilocataire, vous devez d’abord prendre en compte les exigences générales du service en matière d’identité, notamment les exigences suivantes :

  • Les identités d’utilisateur ou de charge de travail seront-elles utilisées pour accéder à une seule application ou plusieurs applications au sein d’une famille de produits ? Par exemple, une famille de produits de vente au détail peut avoir à la fois une application de point de vente et une application de gestion des stocks, qui partagent la même solution d’identité.
  • Envisagez-vous d’implémenter l’authentification et l’autorisation modernes, telles que OAuth2 et OpenID Connecter ?
  • Votre solution fournit-elle uniquement l’authentification à vos applications basées sur l’interface utilisateur ? Ou bien, fournissez-vous également un accès API à vos locataires et tiers ?
  • Les locataires doivent-ils fédérer avec leur propre fournisseur d’identité et plusieurs fournisseurs d’identité différents doivent-ils être pris en charge pour chaque locataire ? Par exemple, vous pouvez avoir des locataires avec Microsoft Entra ID, Auth0 et Services ADFS (ADFS), où chacun souhaite fédérer avec votre solution. Vous devez également comprendre les protocoles de fédération des fournisseurs d’identité de vos locataires que vous allez prendre en charge, car les protocoles influencent les exigences de votre propre fournisseur d’identité.
  • Existe-t-il des exigences de conformité spécifiques qu’elles doivent respecter, telles que le RGPD ?
  • Vos locataires nécessitent-ils que leurs informations d’identité se trouvent dans une région géographique spécifique ?
  • Les utilisateurs de votre solution ont-ils besoin d’accéder aux données d’un locataire ou de plusieurs locataires au sein de votre application ? Ont-ils besoin de la possibilité de basculer rapidement entre les locataires ou d’afficher des informations consolidées à partir de plusieurs locataires ? Par exemple, les utilisateurs connectés au portail Azure peuvent facilement passer d’un répertoire Microsoft Entra ID à un autre et d’un abonnement à un autre auxquels ils ont accès.

Lorsque vous avez établi vos exigences générales, vous pouvez commencer à planifier des détails et des exigences plus spécifiques, tels que des sources d’annuaire utilisateur et des flux d’inscription/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 contenir des références à des identités externes stockées dans le répertoire d’un autre fournisseur d’identité.

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 s’inscrire 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.
  • Fournisseurs 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.
  • Utilisez le répertoire Microsoft Entra ID du tenant. Les locataires peuvent déjà avoir leur propre répertoire Microsoft Entra ID, et ils peuvent vouloir que votre solution utilise leur répertoire comme IdP pour accéder à votre solution. Cette approche est possible lorsque votre solution est générée en tant qu’application Microsoft Entra multilocataire.
  • Fédération avec le fournisseur d’identité d’un locataire. Les locataires peuvent avoir leur propre IdP, autre que Microsoft Entra ID, et ils peuvent vouloir que votre solution se fédère avec celui-ci. La fédération active les expériences d’authentification unique (SSO) et permet aux locataires de gérer le cycle de vie et les stratégies de sécurité de leurs utilisateurs, indépendamment de votre solution.

Vous devez prendre en compte si vos locataires doivent prendre en charge plusieurs fournisseurs d’identité. Par exemple, vous devrez peut-être prendre en charge les identités locales, les identités sociales et les identités fédérées, dans un seul locataire. Cette exigence est courante lorsque les entreprises utilisent une solution à la fois pour leurs propres employés et pour les entrepreneurs. Ils peuvent utiliser la fédération pour l’accès de leurs propres employés à la solution, tout en autorisant l’accès aux sous-traitants ou aux utilisateurs invités, qui n’ont pas de compte dans le fournisseur d’identité fédéré.

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 requises par vos locataires.
  • Les informations nécessaires pour authentifier vos utilisateurs en toute sécurité, y compris les informations nécessaires pour fournir l’authentification multifactorielle (MFA).
  • Informations spécifiques au locataire, telles que les rôles de locataire et les autorisations. Ces informations sont utilisées pour l’autorisation.

Attention

Nous vous déconseillons de créer vous-même des processus d’authentification. Les fournisseurs d’identité modernes fournissent ces services d’authentification à votre application et incluent également d’autres fonctionnalités importantes, telles que l’authentification multifacteur et l’accès conditionnel. La création de votre propre fournisseur d’identité est un antimodèle. Nous ne le recommandons pas.

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

  • Stockez toutes les informations d’identité et d’autorisation dans le répertoire de fournisseurs d’identité et partagez-les entre plusieurs locataires.
  • Stockez les informations d’identification de l’utilisateur dans le répertoire IdP et stockez les informations d’autorisation dans la couche Application, ainsi que les informations de locataire.

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

Il est courant que les solutions multilocataires permettent à un utilisateur ou à une identité de charge de travail d’accéder à l’application et aux données de plusieurs locataires. Déterminez si cette approche est requise pour votre solution. Si c’est le cas, vous pouvez tenir compte des questions suivantes :

  • Devez-vous créer une identité d’utilisateur unique pour chaque personne ou créer des identités distinctes pour chaque combinaison client-utilisateur ?
    • Il est préférable d’utiliser une identité unique pour chaque personne, dans la mesure du possible. Il devient difficile de gérer plusieurs comptes d’utilisateur, à la fois pour vous, en tant que fournisseur de solutions et également pour vos utilisateurs. En outre, la plupart des protections intelligentes contre les menaces offertes par un fournisseur d’identité moderne s’appuient sur chaque personne ayant un seul compte d’utilisateur.
    • Toutefois, dans certaines situations, il peut être nécessaire qu’un utilisateur ait plusieurs identités distinctes. 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 ait plusieurs identités afin qu’elle puisse se conformer aux réglementations ou aux lois.
  • Si vous utilisez des identités par locataire, évitez de stocker les informations d’identification plusieurs fois. 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 les utilisateurs seront mappés à un locataire. Par exemple, pendant le processus d’inscription, vous pouvez utiliser un code d’invitation unique qu’ils entrent la première fois qu’ils accèdent à un locataire. Dans certaines solutions, vous pouvez utiliser le nom de domaine des adresses e-mail d’inscription des utilisateurs comme moyen d’identifier le locataire auquel ils appartiennent. Vous pouvez également utiliser un autre attribut de l’enregistrement d’identité de l’utilisateur pour mapper l’utilisateur à un locataire. Vous devez ensuite stocker le mappage en fonction des identificateurs uniques immuables sous-jacents pour le locataire et l’utilisateur.

Si votre solution est conçue pour qu’un seul utilisateur n’accède jamais aux données d’un seul locataire, prenez les décisions suivantes :

  • Comment le fournisseur d’identité détecte-t-il le locataire auquel un utilisateur accède ?
  • Comment le fournisseur d’identité communique-t-il l’identificateur de 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, vous devez prendre les décisions suivantes :

  • Comment votre solution identifie-t-elle et accorde-t-elle des autorisations à un utilisateur ayant accès à plusieurs locataires ? Par exemple, un utilisateur peut-il être administrateur dans un locataire de formation et avoir un accès en lecture seule à un locataire de production ? Ou bien, pouvez-vous avoir des locataires distincts pour différents services d’une organisation, mais vous devez maintenir des identités utilisateur cohérentes entre tous les locataires ?
  • Comment un utilisateur passe-t-il d’un locataire à l’autre ?
  • Si vous utilisez des identités de charge de travail, comment une identité de charge de travail spécifie-t-elle le locataire auquel il doit accéder ?
  • Existe-t-il des informations spécifiques au locataire stockées dans l’enregistrement d’identité de l’utilisateur qui pourraient laisser fuiter des informations entre les locataires ? Par exemple, supposons qu’un utilisateur s’est inscrit à une identité sociale et qu’il a ensuite obtenu l’accès à deux locataires. Locataire A enrichi l’identité de l’utilisateur avec plus d’informations. Le locataire B doit-il avoir accès aux informations enrichies ?

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

Certains locataires peuvent avoir besoin d’autoriser les utilisateurs à s’inscrire à 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 questions suivantes :

  • Quelles sont les sources d’identité auxquelles les utilisateurs sont autorisés à s’inscrire ? Par exemple, un utilisateur peut-il créer une identité locale et utiliser également un fournisseur d’identité sociale ?
  • Si seules les identités locales sont autorisées, seuls les domaines de messagerie spécifiques sont-ils autorisés ? Par exemple, un locataire peut-il spécifier que seuls les utilisateurs disposant d’une adresse e-mail @contoso.com sont autorisés à s’inscrire ?
  • Quel est le nom d’utilisateur principal (UPN) qui doit être utilisé pour identifier de manière unique chaque identité locale pendant le processus de connexion ? Par exemple, une adresse e-mail, un nom d’utilisateur, un numéro de téléphone et un numéro de carte de récompense sont tous des choix courants pour les UPN. Toutefois, les UPN peuvent changer au fil du temps. Lorsque vous faites référence à l’identité dans les règles d’autorisation ou les journaux d’audit de votre application, il est recommandé d’utiliser l’identificateur unique immuable sous-jacent de l’identité. Microsoft Entra ID fournit un ID d’objet (OID), qui est un identificateur immuable.
  • Un utilisateur sera-t-il obligé de vérifier son UPN ? Par exemple, si l’adresse e-mail ou le numéro de téléphone de l’utilisateur est utilisé comme UPN, comment vérifier que les informations sont exactes ?
  • Les administrateurs de locataires doivent-ils approuver les inscriptions ?
  • Les locataires nécessitent-ils une expérience d’inscription ou une URL spécifique au locataire ? Par exemple, vos locataires nécessitent-ils une expérience d’inscription personnalisée lorsque les utilisateurs s’inscrivent ? Vos locataires nécessitent-ils 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

Lorsque les utilisateurs sont autorisés à s’inscrire à une identité, il doit généralement y avoir un processus pour qu’ils soient autorisés à accéder à un locataire. Le flux d’inscription peut inclure un processus d’octroi d’accès, ou il peut être 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 questions suivantes :

  • Comment le flux d’inscription détermine-t-il qu’un utilisateur doit avoir accès à un locataire spécifique ?
  • Si les utilisateurs ne doivent plus avoir accès à un locataire, votre solution révoquera-t-elle automatiquement son accès ? Par exemple, lorsque les utilisateurs quittent une organisation, il doit y avoir un processus manuel ou automatisé qui supprime leur accès du locataire.
  • Devez-vous fournir un moyen pour les locataires d’auditer les utilisateurs qui ont accès à leurs locataires et à leurs autorisations ?

Gestion automatisée du cycle de vie des comptes

Une exigence courante pour les clients d’entreprise ou d’entreprise d’une solution est un ensemble de fonctionnalités qui leur permettent d’automatiser l’intégration des comptes et la désactivation. 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 non seulement la création et la suppression des enregistrements d’identité, mais également la gestion des autorisations du locataire. Tenez compte des questions suivantes lorsque vous implémentez la gestion automatisée du cycle de vie des comptes dans une solution multilocataire :

  • Vos clients doivent-ils configurer et gérer un processus de cycle de vie automatisé par 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.
  • Avez-vous besoin d’implémenter SCIM, ou pouvez-vous fournir une fédération de locataires à la place, pour conserver la source de vérité pour les utilisateurs sous le contrôle du locataire, au lieu de gérer les utilisateurs locaux ?

Processus d’authentification de l’utilisateur

Lorsqu’un utilisateur se connecte à une application multilocataire, votre système d’identité authentifie l’utilisateur. Vous devez prendre en compte les questions suivantes lorsque vous planifiez votre processus d’authentification :

  • Vos locataires doivent-ils configurer leurs propres politiques d’authentification multifactorielle (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.
  • Vos locataires doivent-ils configurer leurs propres règles d’accès conditionnel ? Par exemple, différents locataires peuvent avoir besoin de bloquer les tentatives de connexion à partir de régions géographiques spécifiques.
  • Vos locataires doivent-ils personnaliser le processus de connexion pour chaque locataire ? Par exemple, avez-vous besoin d’afficher le logo d’un client ? Ou, les informations relatives à chaque utilisateur doivent-elles être extraites d’un autre système, comme un numéro de récompense, et retournées au fournisseur d’identité pour ajouter au profil utilisateur ?
  • Vos utilisateurs doivent-ils 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.
  • Vos utilisateurs doivent-ils accéder aux API de votre solution ? Par exemple, les utilisateurs ou les applications tierces peuvent avoir besoin d’appeler directement vos API pour étendre votre solution, sans interface utilisateur pour fournir un flux d’authentification.

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, afin d’accéder à vos ressources d’application. Par exemple, vos locataires peuvent avoir besoin d’accéder à une API fournie par votre solution, afin qu’elles puissent automatiser certaines de leurs tâches de gestion.

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 s’attendent à pouvoir activer l’accès aux identités de charge de travail à votre solution multilocataire, vous devez prendre en compte les questions suivantes :

  • Comment les identités de charge de travail seront-elles créées et gérées dans chaque locataire ?
  • Comment les demandes d’identité de charge de travail seront-elles étendues au locataire ?
  • Devez-vous limiter le nombre d’identités de charge de travail créées par chaque locataire ?
  • Devez-vous fournir des contrôles d’accès conditionnel sur les identités de charge de travail pour chaque locataire ? Par exemple, un locataire peut vouloir limiter une identité de charge de travail à partir de l’extérieur d’une région spécifique.
  • Quels contrôles de sécurité fournissez-vous aux locataires pour vous assurer que les identités de charge de travail sont conservées sécurisées ? Par exemple, le déploiement de clés automatisées, l’expiration de clé, l’expiration du certificat et la surveillance des risques de connexion sont toutes les méthodes permettant de réduire le risque, où une identité de charge de travail peut être mal utilisée.

Fédérer avec un fournisseur d’identité pour l’authentification unique (SSO)

Les locataires, qui ont déjà leurs propres répertoires d’utilisateurs, peuvent souhaiter que votre solution se fédère à 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 pour activer des expériences d’authentification unique.

Si vous attendez des locataires à fédérer avec votre solution, vous devez prendre en compte les questions suivantes :

  • Quel est le processus de configuration de la fédération pour un locataire ? Les locataires peuvent-ils configurer la fédération eux-mêmes ou le processus nécessite-t-il une configuration et une maintenance manuelles par votre équipe ?
  • Quels protocoles de fédération prendre en charge ?
  • Quels sont les processus en place pour garantir que la fédération ne peut pas être mal configurée, pour accorder l’accès à un autre locataire ?
  • Le fournisseur d’identité d’un seul locataire doit-il être fédéré à plusieurs locataires de 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é aux deux locataires.

Modèles d’autorisation

Décidez du modèle d’autorisation qui est le plus judicieux pour votre solution. Voici deux approches liées aux autorisations :

  • 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 pouvez utiliser des licences par utilisateur dans le cadre de votre modèle tarifaire commercial. Vous fourniriez différents niveaux de licences utilisateur avec différentes fonctionnalités. 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 que des utilisateurs spécifiques sont autorisés à accéder, en fonction de leurs licences, sont parfois appelées droits.

Bien que le suivi et l’application des droits soient similaires à l’autorisation, il est généralement géré par le code de l’application ou par un système de droits dédiés, plutôt que géré par le système d’identité.

Volume d’authentification et d’échelle d’identité

À mesure que les solutions multilocataires augmentent, le nombre d’utilisateurs et les demandes de connexion qui doivent être traitées par la solution augmenteront. Vous devez envisager les techniques suivantes :

  • Le répertoire utilisateur sera-t-il mis à l’échelle au nombre d’utilisateurs requis ?
  • Le processus d’authentification gère-t-il le nombre attendu de connexions et d’inscriptions ?
  • Y aura-t-il des pics que le système d’authentification ne peut pas gérer ? Par exemple, à 9 heures PST, tout le monde dans la région ouest États-Unis peut commencer à travailler et se connecter à votre solution, ce qui entraîne un pic de demandes de connexion. Ces situations sont parfois appelées tempêtes de connexion.
  • La charge élevée dans d’autres parties de votre solution peut-elle avoir un impact sur les performances du processus d’authentification ? Par exemple, si votre processus d’authentification nécessite l’appel à une API de la couche Application, un nombre élevé de demandes d’authentification entraîne-t-il des problèmes pour le reste de votre solution ?
  • Que se passe-t-il si votre fournisseur d’identité devient indisponible ? Existe-t-il un service d’authentification de sauvegarde qui peut prendre le relais pour assurer la continuité de l’activité, alors que le fournisseur d’identité n’est pas disponible ?

Contributeurs

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

Principaux auteurs :

Autres contributeurs :

Étapes suivantes

Passez en revue les Approches architecturales concernant l’identité dans les solutions multilocataires.