Vue d’ensemble des fournisseurs d’identité pour Azure Stack Hub

Azure Stack Hub nécessite Microsoft Entra ID ou les services de fédération Active Directory (AD FS), avec Active Directory en tant que fournisseur d’identité. Le choix d’un fournisseur est une décision unique que vous prenez lorsque vous déployez Azure Stack Hub pour la première fois. Les concepts et les détails d’autorisation de cet article peuvent vous aider à choisir un fournisseur d’identité.

Votre choix entre Microsoft Entra ID et AD FS est déterminé par le mode de déploiement d’Azure Stack Hub :

• Lorsque vous le déployez en mode connecté, vous pouvez utiliser Microsoft Entra ID ou AD FS.
• Lorsque vous le déployez en mode déconnecté sans connexion internet, seul AD FS est pris en charge.

Pour plus d’informations sur ces options, qui dépendent de votre environnement Azure Stack Hub, consultez les articles suivants :

• Kit de développement Azure Stack Hub : considérations relatives à l’identité.
• Systèmes intégrés Azure Stack Hub : décisions de planification du déploiement pour les systèmes intégrés Azure Stack Hub.

Important

Azure AD Graph est déconseillé et sera mis hors service le 30 juin 2023. Pour plus d’informations, consultez cettesection.

Concepts courants pour les fournisseurs d’identité

Les sections suivantes décrivent les concepts communs relatifs aux fournisseurs d’identité et à leur utilisation dans Azure Stack Hub.

Les locataires d’annuaire et les organisations

Un répertoire est un conteneur qui conserve des informations sur les utilisateurs, les applications, les groupes, et les principaux de service.

Un locataire d’annuaire est une organisation, comme Microsoft ou votre propre entreprise.

• Microsoft Entra ID prend en charge plusieurs locataires et peut prendre en charge plusieurs organisations, chacune dans son propre annuaire. Si vous utilisez Microsoft Entra ID et que vous avez plusieurs locataires, vous pouvez accorder un accès à d’autres locataires du même annuaire pour des applications et des utilisateurs d’un autre locataire.
• AD FS ne prend en charge qu’un seul locataire, et donc une seule organisation.

Utilisateurs et groupes

Les comptes d’utilisateur (identités) sont des comptes standard qui authentifient des individus à l’aide d’un ID utilisateur et d’un mot de passe. Les groupes peuvent inclure des utilisateurs ou d’autres groupes.

La façon de créer et de gérer les utilisateurs et les groupes dépend de la solution d’identité que vous utilisez.

Dans Azure Stack Hub, des comptes d’utilisateur :

• Sont créés au format nom_utilisateur@domaine. Bien qu’AD FS mappe les comptes d’utilisateur à une instance Active Directory, AD FS ne prend pas en charge le format \<domaine>\<alias>.
• Peuvent être configurés pour utiliser l’authentification multifacteur.
• Sont limités au répertoire où ils se sont inscrits en premier lieu, qui est le répertoire de leur organisation.
• Peuvent être importés à partir de vos répertoires locaux. Pour plus d’informations, consultez Intégrer vos répertoires locaux à l’ID Microsoft Entra.

Lorsque vous vous connectez au portail utilisateur de votre organisation, vous utilisez l’URL https://portal.local.azurestack.external. Lorsque vous vous connectez au portail Azure Stack Hub à partir d’autres domaines que celui utilisé pour l’inscription à Azure Stack Hub, le nom de domaine utilisé pour l’inscription à Azure Stack Hub doit être ajouté à l’URL du portail. Par exemple, si Azure Stack Hub a été inscrit avec fabrikam.onmicrosoft.com et que le compte d’utilisateur est admin@contoso.com, voici l’URL à utiliser pour se connecter au portail utilisateur : https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

Utilisateurs invités

Les utilisateurs invités sont des comptes d’utilisateur pour des locataires d’annuaire ayant reçu un accès aux ressources de votre répertoire. Pour prendre en charge les utilisateurs invités, utilisez Microsoft Entra ID et activez la prise en charge de l’architecture multilocataire. Lorsqu’elle est prise en charge, vous pouvez inviter un utilisateur invité à accéder aux ressources de votre locataire d’annuaire, ce qui permet la collaboration avec des organisations externes.

Pour inviter des utilisateurs invités, des opérateurs cloud et des utilisateurs peuvent utiliser Microsoft Entra B2B Collaboration. Les utilisateurs invités ont accès aux documents, aux ressources et aux applications à partir de votre annuaire et vous gardez le contrôle de vos propres ressources et données.

En tant qu’utilisateur invité, vous pouvez vous connecter à un locataire d’annuaire d’autres organisations. Pour ce faire, vous devez ajouter le nom de répertoire de ces organisations à l’URL du portail. Par exemple, si vous appartenez à l'organisation Contoso et que vous souhaitez vous connecter à l'annuaire de Fabrikam, utilisez https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

Applications

Vous pouvez inscrire des applications à Microsoft Entra ID ou AD FS et les offrir à des utilisateurs de votre organisation.

Les applications sont les suivantes :

• Application web : le portail Azure et Azure Resource Manager sont des exemples. Elles prennent en charge les appels d’API web.
• Client natif : Azure PowerShell, Visual Studio et Azure CLI sont des exemples.

Les applications peuvent prendre en charge deux types de location :

• Monolocataire : prend uniquement en charge les utilisateurs et services du même annuaire que celui où l’application est inscrite.

  Remarque

  Étant donné qu’AD FS prend seulement en charge un annuaire unique, les applications que vous créez dans une topologie AD FS sont, par défaut, des applications à locataire unique.

• Multilocataire : prend en charge les utilisateurs et les services faisant partie à la fois de l’annuaire où l’application est inscrite et d’autres annuaires de locataire. Avec les applications multilocataires, les utilisateurs d’un autre annuaire (un autre locataire Microsoft Entra) peuvent se connecter à votre application.

  Pour plus d’informations sur la mutualisation, consultez Activer la mutualisation.

  Pour plus d’informations sur le développement d’une application multilocataire, consultez Applications multilocataires.

Quand vous inscrivez une application, vous créez deux objets :

• Objet application : représentation globale de l’application sur tous les locataires. Cette relation est de type un à un avec l’application logicielle et existe uniquement dans le premier annuaire d’inscription de l’application.

• Objet principal de service : informations d’identification créées pour une application dans le premier annuaire d’inscription de l’application. Un principal de service est également créé dans l’annuaire de chaque locataire supplémentaire où cette application est utilisée. Cette relation peut être du type un à plusieurs avec l’application.

Pour en savoir plus sur les objets d’application et de principal de service, consultez Les objets d’application et de principal de service dans l’ID Microsoft Entra.

Principaux de service

Un principal de service est un ensemble d’informations d’identification pour une application ou un service qui accorde l’accès aux ressources dans Azure Stack Hub. L’utilisation d’un principal de service sépare les autorisations de l’application et celles de l’utilisateur de l’application.

Un principal de service est créé dans chaque locataire où l’application est utilisée. Le principal de service établit une identité pour se connecter et accéder aux ressources (comme les utilisateurs) sécurisées par ce locataire.

• Une application monolocataire dispose d’un seul principal de service, qui se trouve dans l’annuaire où elle a été créée. Ce principal de service est créé et donne son consentement à être utilisé lors de l’inscription de l’application.
• Une application web ou une API multilocataire dispose également d’un principal de service créé dans chaque locataire où un utilisateur de ce locataire consent à utiliser l’application.

Les informations d’identification pour les principaux de service peuvent être un certificat ou une clé générée via le portail Azure. L’utilisation d’un certificat est adaptée à l’automatisation, car les certificats sont considérés comme plus sûrs que des clés.

Remarque

Lorsque vous utilisez AD FS avec Azure Stack Hub, seul l’administrateur peut créer des principaux de service. Avec AD FS, les principaux de service nécessitent des certificats et sont créés via le point de terminaison privilégié (PEP). Pour plus d’informations, consultez Utiliser une identité d’application pour accéder à des ressources.

Pour en savoir plus sur les principaux de service pour Azure Stack Hub, consultez Créer des principaux de service.

Services

Dans Azure Stack Hub, les services qui interagissent avec le fournisseur d’identité sont enregistrés comme des applications avec le fournisseur d’identité. Comme les applications, l’inscription permet l’authentification par un service avec le système d’identité.

Tous les services Azure utilisent les protocoles OpenID Connect et JSON Web Tokens pour établir leur identité. Étant donné que Microsoft Entra ID et AD FS utilisent des protocoles de manière cohérente, vous pouvez utiliser la bibliothèque d’authentification Microsoft (MSAL) pour obtenir un jeton de sécurité pour authentifier localement ou auprès d’Azure (dans un scénario connecté). Avec MSAL, vous pouvez également utiliser des outils tels qu’Azure PowerShell et Azure CLI pour la gestion des ressources interclouds et locales.

Les identités et votre système d’identité

Les identités pour Azure Stack Hub comprennent les comptes d’utilisateurs, les groupes et les principaux de service.

Quand vous installez Azure Stack Hub, plusieurs services et applications intégrés s’inscrivent automatiquement avec votre fournisseur d’identité dans le locataire d’annuaire. Certains services inscrits sont utilisés pour l’administration. D’autres services sont disponibles pour les utilisateurs. Les inscriptions par défaut affichent les identités des services de base qui peuvent interagir entre eux et avec des identités ajoutées plus tard.

Si vous configurez Microsoft Entra ID avec une architecture multilocataire, certaines applications se propagent sur les nouveaux annuaires.

Authentification et autorisation

Authentification par les applications et les utilisateurs

Pour les applications et les utilisateurs, l’architecture d’Azure Stack Hub est décrite par quatre couches. Les interactions entre chacune de ces couches peuvent utiliser différents types d’authentification.

Couche	Authentification entre les couches
Outils et clients, comme le portail de l’administrateur	Pour consulter ou modifier une ressource dans Azure Stack Hub, les outils et les clients utilisent un JSON Web Token pour passer un appel à Azure Resource Manager. Azure Resource Manager valide le JSON Web Token et lit furtivement les revendications dans le jeton émis pour estimer le niveau d’autorisation de l’utilisateur ou du principal de service dans Azure Stack Hub.
Azure Resource Manager et ses services de base	Azure Resource Manager communique avec les fournisseurs de ressources pour transférer les communications des utilisateurs. Les transferts utilisent des appels impératifs directs ou des appels déclaratifs via des modèles Azure Resource Manager.
Fournisseurs de ressources	Les appels passés à des fournisseurs de ressources sont sécurisés avec l’authentification par certificat. Azure Resource Manager et le fournisseur de ressources restent ensuite en communication via une API. Pour chaque appel reçu depuis Azure Resource Manager, le fournisseur de ressources valide l’appel avec ce certificat.
Infrastructure et logique métier	Les fournisseurs de ressources communiquent avec une logique métier et une infrastructure à l’aide du mode d’authentification de leur choix. Les fournisseurs de ressources par défaut fournis avec Azure Stack Hub utilisent l’authentification Windows pour sécuriser cette communication.

S’authentifier à Azure Resource Manager

Pour s’authentifier auprès du fournisseur d’identité et recevoir un JSON Web Token, vous devez disposer des informations suivantes :

1. URL du système d’identité (autorité) : URL d’accès à votre fournisseur d’identité. Par exemple : https://login.windows.net.
2. URI ID d’application pour Azure Resource Manager : identificateur unique pour l’instance Azure Resource Manager inscrite avec votre fournisseur d’identité. Il est également unique pour chaque installation Azure Stack Hub.
3. Informations d’identification : informations d’identification utilisées pour l’authentification avec le fournisseur d’identité.
4. URL pour Azure Resource Manager : URL correspondant à l’emplacement du service Azure Resource Manager. Par exemple, https://management.azure.com ou https://management.local.azurestack.external.

Quand un principal (un client, une application ou un utilisateur) effectue une demande d’authentification pour accéder à une ressource, cette demande doit inclure :

• Les informations d’identification du principal.
• L’URI de l’ID d’application de la ressource à laquelle le principal demande l’accès.

Les informations d’identification sont validées par le fournisseur d’identité. Le fournisseur d’identité valide également que l’URI ID d’application concerne une application inscrite, et que le principal possède les privilèges corrects pour obtenir un jeton pour cette ressource. Si la demande est valide, un JWT est accordé.

Le jeton doit passer dans l’en-tête d’une demande à Azure Resource Manager. Azure Resource Manager effectue les actions suivantes sans ordre spécifique :

• Valide la revendication issuer (iss) pour confirmer que le jeton vient du fournisseur d’identité correct.
• Valides la revendication audience (aud) pour confirmer que le jeton a été émis pour Azure Resource Manager.
• Vérifie que le JSON Web Token est signé avec un certificat configuré via OpenID et connu d’Azure Resource Manager.
• Examine les revendications issued at (iat) et expiration (exp) pour confirmer que le jeton est actif et peut être accepté.

Une fois toutes les validations terminées, Azure Resource Manager utilise les revendications objecte id (oid) et groups pour dresser la liste des ressources auxquelles le principal peut accéder.

Utiliser le contrôle d’accès en fonction du rôle

Le contrôle d’accès en fonction du rôle (RBAC) dans Azure Stack Hub est cohérent avec l’implémentation dans Microsoft Azure. Vous pouvez gérer l’accès aux ressources en assignant le rôle RBAC approprié aux utilisateurs, groupes et applications. Pour plus d’informations sur l’utilisation de RBAC avec Azure Stack Hub, consultez les articles suivants :

• Découvrir le contrôle d’accès en fonction du rôle dans le portail Azure.
• Utiliser le contrôle d’accès en fonction du rôle pour gérer l’accès aux ressources d’un abonnement Azure.
• Créer des rôles personnalisés pour le contrôle d’accès en fonction du rôle Azure.
• Gérer le contrôle d’accès en fonction du rôle dans Azure Stack Hub

S’authentifier avec Azure PowerShell

Pour plus de détails sur l’utilisation de Azure PowerShell pour s’authentifier auprès de Azure Stack Hub, consultez Configurer l’environnement PowerShell de l’utilisateur de Azure Stack Hub.

S’authentifier avec Azure CLI

Pour en savoir plus sur l’utilisation d’Azure PowerShell pour s’authentifier auprès d’Azure Stack Hub, consultez Installer et configurer Azure CLI pour l’utiliser avec Azure Stack Hub.

Azure Policy

Azure Policy aide à appliquer les normes organisationnelles et à évaluer la conformité à grande échelle. Avec son tableau de bord de conformité, il fournit une vue agrégée permettant d’évaluer l’état général de l’environnement, avec la possibilité d’explorer au niveau de chaque ressource et stratégie. Il vous aide également à mettre vos ressources en conformité par le biais de la correction en bloc pour les ressources existantes et de la correction automatique pour les nouvelles ressources.

Les cas d’usage courants pour Azure Policy incluent la mise en œuvre de la gouvernance pour la cohérence des ressources, la conformité réglementaire, la sécurité, le coût et la gestion. Les définitions de stratégie de ces cas d’usage courants sont déjà intégrées dans votre environnement Azure pour vous aider à démarrer.

Remarque

Azure Policy n’est actuellement pas pris en charge dans Azure Stack Hub.

Azure AD Graph

Microsoft Azure a annoncé la dépréciation d’Azure AD Graph le 30 juin 2020 et sa date de mise hors service du 30 juin 2023. Microsoft a informé les clients par e-mail de ce changement. Pour plus d’informations, consultez le blog de dépréciation du module Azure AD Graph et de la suppression du module PowerShell.

La section suivante décrit la façon dont cet abandon affecte Azure Stack Hub.

L’équipe Azure Stack Hub travaille en étroite collaboration avec l’équipe Azure Graph pour vous assurer que vos systèmes continuent de fonctionner au-delà du 30 juin 2023 si nécessaire, afin de garantir une transition fluide. L’action la plus importante consiste à vous assurer que vous respectez la stratégie de maintenance Azure Stack Hub. Les clients recevront une alerte dans le portail d’administration d’Azure Stack Hub et seront tenus de mettre à jour le répertoire de base et tous les annuaires invités intégrés.

La majorité de la migration elle-même sera effectuée par l’expérience de mise à jour système intégrée ; Une étape manuelle est requise par les clients pour accorder de nouvelles autorisations à ces applications, ce qui nécessite des autorisations d’administrateur d’application dans chaque annuaire Microsoft Entra utilisé avec vos environnements Azure Stack Hub. Une fois le package de mise à jour avec ces modifications terminée l’installation, une alerte est déclenchée dans le portail d’administration pour effectuer cette étape à l’aide de l’interface utilisateur mutualisée ou des scripts PowerShell. Il s’agit de la même opération que celle que vous effectuez lors de l’intégration d’annuaires ou de fournisseurs de ressources supplémentaires ; Pour plus d’informations, consultez Configurer l’architecture mutualisée dans Azure Stack Hub.

Si vous utilisez AD FS comme système d’identité avec Azure Stack Hub, ces changements concernant Graph n’affecteront pas votre système directement. Toutefois, les dernières versions d’outils telles qu’Azure CLI, Azure PowerShell, etc., nécessitent les nouvelles API Graph et ne fonctionneront pas. Veillez à utiliser uniquement les versions de ces outils explicitement prises en charge par votre version d’Azure Stack Hub.

Outre l’alerte dans le portail d’administration, nous communiquerons les changements dans les notes de publication de mise à jour, ainsi que le package de mise à jour nécessaire à la mise à jour du répertoire de base et des répertoires invités intégrés.

Étapes suivantes

• Architecture d’identités
• Intégration au centre de données - Identité