Partager via


Vue d'ensemble de l'authentification Windows Azure Pack

 

S’applique à : Windows Azure Pack

Windows Azure Pack pour Windows Server utilise l’authentification basée sur les revendications pour accorder l’accès au portail de gestion pour les administrateurs, le portail de gestion pour les locataires et l’API REST Gestion des services. Cette section fournit une vue d’ensemble de la façon dont Windows Azure Pack implémente l’authentification basée sur les revendications. Le kit de développement Azure Pack Windows inclut un exemple, SampleAuthApplication, qui montre comment s’authentifier auprès des portails Administration et locataires d’Azure Pack Windows. Pour plus d’informations sur Windows Azure Pack et l’authentification, consultez https://go.microsoft.com/fwlink/?LinkId=331159.

Vue d’ensemble

La couche d’administration Windows Azure Pack fournit une API REST étendue et un large éventail d’applets de commande Windows PowerShell qui fournissent un accès par programme pour contrôler et exploiter les composants de gestion d’administration. Ces API et applets de commande nécessitent que l’appelant soit authentifié en fournissant un jeton de sécurité signé par une source approuvée. Dans l’authentification basée sur les revendications, ce jeton est fourni par une entité externe appelée service d’émission de jeton de sécurité (STS). Une relation d’approbation est établie entre Windows Azure Pack, appelé partie de confiance (RP) et STS qui permet au STS de signer des jetons de sécurité et d’autoriser Windows Azure Pack à vérifier l’authenticité des jetons. Pour que stS émette un jeton, il doit d’abord vérifier l’identité de l’utilisateur. Pour ce faire, vous pouvez recevoir un jeton signé approuvé à partir d’un autre STS approuvé (dans le cas de la fédération), garantissant l’identité de l’utilisateur. Vous pouvez également le faire en consultant une entité appelée fournisseur d’identité (IdP), qui sait interagir avec les utilisateurs et authentifier leurs identités.

Il est possible de créer différentes topologies dans un déploiement Windows Azure Pack.

Exemple - Un

Le portail d’administration pour les locataires peut être configuré pour approuver le site d’authentification du locataire Azure Pack (appartenance) Windows et le portail d’administration pour les administrateurs peut être configuré pour approuver le site d’authentification Windows Administration Azure Pack Administration (Windows). Dans cet exemple, le Windows site d’authentification du locataire Azure Pack (appartenance) agit comme fournisseur d’identité/STS. Il s’agit d’un fournisseur d’identité, car il peut vérifier les noms d’utilisateur et les mots de passe par rapport à un magasin d’appartenances et il s’agit d’un STS, car après avoir vérifié l’identité de l’utilisateur, il peut émettre et signer un jeton de sécurité qui identifie l’utilisateur. Cela s’applique également au site d’authentification Administration.

Exemple - Deux

Le portail de gestion pour les administrateurs et le portail de gestion pour les locataires peuvent être configurés pour approuver Services ADFS 2.0 pour Window Server 2012 R2 (AD FS 2.0) Il s’agit de la topologie recommandée pour les scénarios de production.

  • Il est possible de configurer AD FS 2.0 pour authentifier les utilisateurs par leurs informations d’identification Active Directory (AD). Dans ce scénario, AD joue le rôle IdP et AD FS 2.0 joue le rôle STS. Ensemble, ils forment la fonctionnalité IDP/STS.

  • Il est possible de configurer AD FS 2.0 pour qu’il se fédère avec un STS externe. Dans ce scénario, AD FS 2.0 joue le rôle STS.

La chaîne d’approbation entre Windows Azure Pack et le fournisseur d’identité final peut être très longue. La chaîne peut avoir un nombre illimité de STS entre Windows Azure Pack (en tant que rp) et le fournisseur d’identité final.

Pour authentifier un utilisateur, l’utilisateur doit accéder au dernier fournisseur d’identité/STS pour fournir ses informations d’identification. En retour, il obtient un jeton. Le jeton doit être échangé pour un nouveau jeton par chaque STS de la chaîne d’approbation et enfin, le jeton émis par le dernier STS peut être présenté à Windows Azure Pack.

Fournisseurs d’identité pris en charge

Avec Windows Azure Pack, vous pouvez utiliser n’importe quel STS qui peut satisfaire aux conditions suivantes :

  • WS-Federation de support

  • Expose un point de terminaison de métadonnées de fédération

  • Être capable de générer des jetons JWT avec au moins « UPN » et éventuellement des revendications « Groups »

Important

Cela s’applique uniquement au premier STS de la chaîne (le plus proche de Windows Azure Pack). D’autres nœuds de la chaîne n’ont pas besoin de ces exigences. Ils doivent simplement être en mesure d’interagir avec les nœuds précédents et suivants dans la chaîne d’approbation.

Un exemple d’utilisation d’un fournisseur d’identité tiers est documenté dans Windows fournisseurs d’identité tiers Azure Pack.

Prête à l’emploi, Windows Azure Pack pour Windows Server est fourni avec deux types de STS.

  • Site d’authentification du locataire

  • site d’authentification Administration

Services ADFS 2.0 pour Window Server 2012 R2 peut être utilisé pour fournir des identités avec Windows Azure Pack. Les versions antérieures d’AD FS ne sont pas compatibles, car elles ne génèrent pas de jetons JWT. Le guide d’installation d’Azure Pack Windows contient plus d’informations sur la façon de fédérer AD FS 2.0 avec Windows Azure Pack. Vous pouvez utiliser des fournisseurs d’identité tiers pour fournir des identités à Windows Azure Pack en fédérant avec AD FS.

Pour plus d’informations sur la configuration d’AD FS 2.0 et Windows Azure Pack, consultez https://technet.microsoft.com/en-us/library/dn296436.aspx.

Site d’authentification du locataire

Le site d’authentification du locataire est un fournisseur d’appartenances ASP.Net idP/STS. L’utilisateur client entre son nom d’utilisateur et son mot de passe sur la page de connexion. Ils sont ensuite vérifiés dans la base de données du fournisseur d’appartenances ASP.Net. Le fournisseur d’appartenances dispose d’une tête STS qui est capable de valider l’utilisateur et d’émettre des jetons de sécurité JWT signés pour les utilisateurs autorisés. Il prend en charge le protocole WS-Federation : Passive Requestor Profile XE " WS-Federation Protocol: Passive Requestor Profile " (authentification via le navigateur) et WS-Trust Protocol: Active Requestor Profile XE « WS-Trust Protocol: Active Requestor Profile » (authentification via Smart Clients).

site d’authentification Administration

Le site d’authentification Administration est un STS basé sur l’authentification Windows (Kerberos/NTLM) qui récupère les informations d’identification de l’utilisateur actuellement connecté et émet des jetons de sécurité signésJWT pour les utilisateurs autorisés. Il prend en charge le protocole WS-Fed pour les flux passifs (authentification via le navigateur) et WS-Trust Protocole pour les flux actifs (authentification par le biais de clients intelligents).

Avertissement

Bien que théoriquement ces deux stS puissent être utilisés indifféremment, les sites d’authentification des Administration et des locataires doivent être utilisés uniquement pour les sites Administration et locataires respectivement. L’échange de cette disposition entraîne l’arrêt des scénarios de locataire. Dans les scénarios de déploiement de production, il est vivement recommandé d’utiliser AD FS.

Voir aussi

Authentification Azure Pack Windows