Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Déléguer l’authentification utilisateur à un fournisseur d’identité externe pour simplifier le développement, réduire les tâches administratives et améliorer l’expérience utilisateur de l’application.
Contexte et problème
Les utilisateurs doivent généralement travailler avec plusieurs applications que les organisations partenaires fournissent et hébergent. Ils peuvent avoir besoin d’utiliser des informations d’identification de connexion spécifiques et différentes pour chaque application. Cette exigence peut :
Cause une expérience utilisateur disjointe. Les employés oublient souvent plusieurs informations d’identification de connexion.
Exposer les vulnérabilités de sécurité. Lorsqu’un employé quitte l’entreprise, l’organisation doit immédiatement désactiver le compte. Les grandes organisations manquent souvent cette étape critique.
Compliquer la gestion des utilisateurs. Les administrateurs gèrent les informations d’identification de l’utilisateur, émettent des rappels de mot de passe et effectuent d’autres tâches administratives.
Les utilisateurs préfèrent généralement utiliser les mêmes informations d’identification de connexion pour toutes les applications.
Solution
Implémentez un mécanisme d’authentification d’identité fédérée. Séparez l’authentification des utilisateurs du code de l’application et déléguez l’authentification à un IdP de confiance. Ce processus simplifie le développement, réduit la surcharge administrative et fournit l’authentification de l’utilisateur via une plage d’idPs. L’identité fédérée sépare également l’authentification de l’autorisation.
Les fournisseurs d'identité approuvés comprennent les annuaires d'entreprise, les services de fédération locaux, les services d'émission de jetons de sécurité (STS) et les fournisseurs d'identité sociaux tels que Microsoft, Google, Yahoo! ou Facebook.
Le diagramme suivant montre le modèle d’identité fédérée pour une application cliente qui accède à un service qui nécessite une authentification. Le fournisseur d'identité fonctionne avec un STS pour assurer l'authentification. L’IdP émet des jetons de sécurité qui fournissent des informations sur l’utilisateur authentifié. Ces informations, appelées revendications, incluent l’identité de l’utilisateur et peuvent également inclure d’autres revendications, telles que les appartenances aux rôles et les droits d’accès plus granulaires.
Ce modèle est également appelé contrôle d’accès basé sur les revendications. Les applications et les services autorisent l'accès aux fonctionnalités en fonction des revendications. Le service qui requiert une authentification doit approuver l’IdP. L’application cliente contacte l’IdP pour s’authentifier. Si l'authentification réussit, le fournisseur d'identité renvoie au STS un jeton contenant des revendications permettant d'identifier l'utilisateur. L’IdP et le STS peuvent faire partie du même service. Le STS peut transformer et augmenter les revendications en fonction de règles prédéfinies avant de renvoyer le jeton au client. L’application cliente transmet ensuite ce jeton au service comme preuve de son identité.
L’authentification fédérée fournit une méthode basée sur des normes pour établir l’approbation des identités entre les domaines, et prend en charge l’authentification unique (SSO). De nombreuses applications, en particulier les applications hébergées dans le cloud, utilisent l’authentification fédérée, car elle prend en charge l’authentification unique sans connexion réseau directe à un fournisseur d’identité. Cette conception augmente la sécurité, car l’utilisateur n’a pas besoin de créer et d’entrer différentes informations d’identification de connexion pour plusieurs applications. Cela limite également l'exposition des informations d'identification au seul fournisseur d'identité d'origine. Les applications voient uniquement les informations d’identité authentifiées dans le jeton.
Les applications et services qui utilisent l’authentification fédérée n’ont pas besoin de fournir des fonctionnalités de gestion des identités. C’est plutôt l’IdP qui assure la gestion des identités et des informations d’identification. Lorsque l’annuaire d’entreprise approuve l’IDP, il n’est pas nécessaire de gérer l’identité de l’utilisateur. Cette approche élimine la surcharge administrative de la gestion des identités utilisateur basée sur des annuaires.
Problèmes et considérations
Prenez en compte les points suivants lorsque vous choisissez comment implémenter ce modèle :
L’authentification peut être un point de défaillance unique. Pour maintenir la fiabilité et la disponibilité des applications dans plusieurs régions, envisagez de déployer votre mécanisme de gestion des identités dans les mêmes régions que votre application.
Pour configurer le contrôle d’accès en fonction du rôle (RBAC), utilisez les outils d’authentification. RBAC prend en charge le contrôle granulaire sur les fonctionnalités et l’accès aux ressources.
Contrairement à un annuaire d’entreprise, l’authentification basée sur les revendications qui utilise des IDP sociaux fournit généralement uniquement l’adresse e-mail de l’utilisateur authentifié, et parfois son nom. Certains fournisseurs d’identité sociale, tels que Microsoft, fournissent uniquement un identificateur unique. L’application conserve généralement certaines informations sur les utilisateurs inscrits afin qu’elle puisse correspondre à ces informations à l’identificateur dans les revendications. Cette tâche est généralement terminée lors de l’inscription, lorsque l’utilisateur accède d’abord à l’application. Les informations sont ensuite injectées dans le jeton en tant que nouvelles revendications après chaque authentification.
Si plusieurs IdP sont configurés pour le STS, le STS doit déterminer quel IdP doit authentifier l’utilisateur. Ce processus est appelé découverte du domaine d’accueil. Le STS peut déterminer automatiquement l’IdP en fonction des informations fournies par l’utilisateur, telles qu’une adresse e-mail ou un nom d’utilisateur, le sous-domaine de l’application, la plage d’adresses IP de l’utilisateur ou un cookie stocké dans le navigateur de l’utilisateur. Par exemple, si l’utilisateur entre une adresse e-mail Microsoft, par
user@live.comexemple, le STS redirige l’utilisateur vers la page de connexion compte Microsoft. Lors des visites suivantes, le STS peut utiliser un cookie qui indique que l’utilisateur s’est connecté précédemment à l’aide d’un compte Microsoft. Si le STS ne peut pas déterminer automatiquement le domaine d'origine, il affiche une page de découverte du domaine d'origine répertoriant les fournisseurs d'identité approuvés. L’utilisateur sélectionne ensuite un IdP.
Quand utiliser ce modèle
Utilisez ce modèle lorsque vous avez besoin des éléments suivants :
SSO en entreprise. Dans ce scénario, vous devez authentifier les employés pour les applications d’entreprise hébergées dans le cloud en dehors de la limite de sécurité de l’entreprise, sans connexion chaque fois qu’ils visitent une application. L’expérience utilisateur correspond aux applications locales. Les utilisateurs s’authentifient lorsqu’ils se connectent au réseau d’entreprise, puis peuvent accéder aux applications pertinentes sans une autre connexion.
Identité fédérée avec plusieurs partenaires. Dans ce scénario, vous devez authentifier les employés d’entreprise et les partenaires commerciaux qui n’ont pas de comptes dans l’annuaire d’entreprise. Cette pratique est courante dans les applications interentreprises, les applications qui s’intègrent à des services partenaires et les entreprises qui utilisent différents systèmes informatiques ou des ressources fusionnées ou partagées.
Identité fédérée dans les applications SaaS (Software as a Service). Dans ce scénario, les fournisseurs de logiciels indépendants fournissent un service prêt à l’emploi pour plusieurs clients ou locataires. Les clients s’authentifient à l’aide d’un IdP approprié. Par exemple, les utilisateurs professionnels utilisent leurs informations d’identification d’entreprise, tandis que les consommateurs et les clients du locataire utilisent des identifiants d’identité sociale.
Identité fédérée pour l’accès aux charges de travail. Dans ce scénario, les applications clientes, les flux de travail d’automatisation ou les systèmes d’intégration continue et de livraison continue doivent appeler vos API sans qu’un utilisateur soit présent. Les locataires s'authentifient auprès de leurs propres fournisseurs d'identité à l'aide d'identités de charge de travail. L’application autorise l’accès grâce à une validation des revendications limitée au locataire.
Ce modèle peut ne pas convenir lorsque vous avez :
Un IdP. Dans ce scénario, les utilisateurs d’application s’authentifient à l’aide d’un fournisseur d’identité et n’ont pas besoin de s’authentifier à l’aide d’un autre fournisseur d’identité. Cette situation est typique dans les applications qui utilisent un annuaire d’entreprise pour l’authentification, via un VPN ou une connexion de réseau virtuel entre l’application et un annuaire local.
Mécanismes d’authentification incompatibles. Dans ce scénario, l’application utilise un mécanisme d’authentification différent, par exemple en utilisant des magasins d’utilisateurs personnalisés, ou il ne peut pas gérer les normes de négociation de technologies basées sur les revendications. Il peut être complexe et coûteux de moderniser l’authentification basée sur les revendications et le contrôle d’accès dans une application existante.
Conception de la charge de travail
Évaluez comment utiliser le modèle d'identité fédérée dans la conception d'une charge de travail pour répondre aux objectifs et principes abordés dans les piliers de l'infrastructure Azure Well-Architected. Le tableau suivant fournit des conseils sur la façon dont ce modèle prend en charge les objectifs de chaque pilier.
| Pilier | Comment ce modèle soutient les objectifs des piliers. |
|---|---|
| Les décisions de conception de fiabilité aident votre charge de travail à devenir résiliente au dysfonctionnement et à s’assurer qu’elle se rétablit dans un état entièrement opérationnel après une défaillance. | Ce modèle confie la gestion des utilisateurs et l’authentification à l’IdP, qui présente généralement un objectif de niveau de service élevé. Pendant la récupération d’urgence de la charge de travail, le plan de récupération de charge de travail n’a pas besoin de traiter les composants d’authentification. - RE :02 Flux critiques - RE:09 DR |
| Les décisions relatives à la conception de la sécurité permettent de garantir la confidentialité, l’intégrité et la disponibilité des données et des systèmes de votre charge de travail. | Ce modèle fournit des fonctionnalités avancées de détection et de prévention des menaces basées sur les identités sans vous obliger à les implémenter dans votre charge de travail. Les fournisseurs d’identité externes utilisent également des protocoles d’authentification modernes et interopérables. - SE :02 Cycle de vie du développement sécurisé - SE :10 Surveillance et détection des menaces |
| L’efficacité des performances permet à votre charge de travail de répondre efficacement aux demandes par le biais d’optimisations de la mise à l’échelle, des données et du code. | Ce modèle vous aide à consacrer des ressources d’application à d’autres priorités. - PE :03 Sélection de services |
Si ce modèle introduit des compromis au sein d’un pilier, considérez-les contre les objectifs des autres piliers.
Example
Une organisation héberge une application cloud multicomponente qui inclut un serveur frontal web et une API back-end. L’application délègue l’authentification à un fournisseur d’identité centralisé à l’aide de Microsoft Entra ID, plutôt que d’implémenter la logique d’authentification dans chaque composant.
Téléchargez un fichier Visio de cette architecture.
Le flux de travail suivant correspond au diagramme précédent.
L’utilisateur accède à l’application web.
L’application web redirige l’utilisateur vers Microsoft Entra ID pour l’authentification.
Une fois l’authentification réussie, Microsoft Entra ID redirige l’utilisateur vers l’application web avec un code d’autorisation.
L’application web échange le code d’autorisation pour les jetons et envoie une requête POST au point de terminaison de jeton.
Microsoft Entra ID émet un jeton qui contient des revendications relatives à l’utilisateur.
L’application web utilise ce jeton pour appeler une API principale.
L’application web et l’API principale valident le jeton et appliquent leurs règles d’autorisation en fonction des revendications.
L’API retourne la réponse à l’application web.
Principales caractéristiques :
Authentification centralisée. Les composants s’appuient sur Microsoft Entra ID pour authentifier les utilisateurs, ce qui supprime la nécessité d’une logique d’authentification personnalisée dans l’application.
Autorisation décentralisée. Les composants d’application appliquent indépendamment les décisions d’autorisation en fonction des revendications.
Contrôle d’accès basé sur les revendications. L’accès aux fonctionnalités est déterminé en utilisant des déclarations, telles que des rôles ou des portées.
Protocoles basés sur des normes. Les composants utilisent OAuth 2.0 et OpenID Connect pour l’authentification.
Application facultative de l'authentification multifacteur. Si votre profil de risque nécessite une assurance de connexion plus forte, vous pouvez appliquer l’authentification multifacteur à l’aide de stratégies d’accès conditionnel dans Microsoft Entra ID.
Extensibilité facultative via la fédération. Microsoft Entra ID peut être configuré pour faire confiance à un locataire partenaire Microsoft Entra en utilisant les paramètres d’accès inter-locataires. Les utilisateurs partenaires peuvent ensuite accéder à l’application sans modifier les composants de l’application.
Étapes suivantes
- Qu’est-ce que Microsoft Entra ?
- OpenID Connect sur le Plateforme d'identités Microsoft
- Convertir une application monolocataire en application multilocataire à l’aide de Microsoft Entra ID
- Qu’est-ce que l’accès conditionnel ?