Partager via

Fédération

  • Article

La fédération autorise la délégation d’autorité d’autorisation à d’autres membres d’une interprise. Par exemple, considérez le problème métier suivant : La société de fabrication de pièces automatiques Contoso Ltd souhaite autoriser les employés autorisés de son client Fabrikam Inc à accéder en toute sécurité au service Web de commande des composants de Contoso. Une solution de sécurité pour ce scénario est que Contoso configure un mécanisme d’approbation avec Fabrikam pour déléguer la décision d’autorisation d’accès à Fabrikam. Ce processus peut fonctionner comme suit :

  • Fabrikam, lorsqu’il devient partenaire de Contoso, configure un contrat d’approbation avec Contoso. L’objectif de cette étape est d’accepter le type et le contenu du jeton de sécurité qui représenteront l’autorisation de Fabrikam et seront acceptables pour Contoso. Par exemple, il peut être décidé qu’un certificat X.509 approuvé portant le nom d’objet « CN=Fabrikam Inc Supplier STS » doit signer un jeton SAML pour que SAML soit accepté par le service web Contoso. En outre, il peut être décidé que la revendication de sécurité dans le jeton SAML émis doit être «https://schemas.contoso.com/claims/lookup» (pour l’autorisation de recherche en partie) ou «https://schemas.contoso.com/claims/order» (pour l’autorisation de commande de partie).
  • Lorsqu’un employé De Fabrikam utilise l’application de classement des parties internes, il contacte d’abord un service de jeton de sécurité (STS) à l’intérieur de Fabrikam. Cet employé est authentifié à l’aide du mécanisme de sécurité Fabrikam interne (par exemple, nom d’utilisateur/mot de passe du domaine Windows), son autorisation de commander les parties est vérifiée et il est émis un jeton SAML de courte durée contenant les revendications appropriées et signé par le certificat X.509 décidé ci-dessus. L’application de classement des parties contacte ensuite le service Contoso présentant le jeton SAML émis pour s’authentifier et effectuer la tâche de classement.

Ici, fabrikam STS agit en tant que « partie émettrice » et le service de composants Contoso agit comme « partie de confiance ». Diagramme montrant une partie émettrice et une partie de confiance dans une fédération.

Fonctionnalités de fédération

Voici les fonctionnalités de sécurité prises en charge pour les parties ou les rôles impliqués dans un scénario de fédération :

  • Côté client : pour obtenir le jeton de sécurité à partir du STS, il est possible d’utiliser fonction WsRequestSecurityToken. Vous pouvez également utiliser une bibliothèque de fournisseurs de jetons de sécurité côté client comme CardSpace ou LiveID, puis utiliser leur sortie pour créer localement un jeton de sécurité à l’aide de WsCreateXmlSecurityToken. Dans les deux cas, une fois que le client a le jeton de sécurité, il peut ensuite créer un canal vers le service spécifiant WS_XML_TOKEN_MESSAGE_SECURITY_BINDING présenter le jeton, ainsi qu’une liaison de sécurité de transport telle que WS_SSL_TRANSPORT_SECURITY_BINDING pour protéger le canal.
  • Côté serveur : dans un scénario de fédération avec un service de jeton de sécurité qui émet des jetons SAML, le serveur peut utiliser l'WS_SAML_MESSAGE_SECURITY_BINDING, ainsi qu’une liaison de sécurité de transport telle que WS_SSL_TRANSPORT_SECURITY_BINDING pour protéger le canal.
  • Côté STS : notez que le STS est une application de service web et qu’il peut spécifier les exigences de sécurité pour ceux qui demandent un jeton de sécurité à l’aide d’une description de sécurité structure au moment de la création de l’écouteur, tout comme n’importe quel autre service web sécurisé. Il peut ensuite analyser les charges utiles de message de requête entrante pour valider les demandes de jetons et renvoyer des jetons émis en tant que charges utiles de message de réponse. Actuellement, aucune fonctionnalité n’est fournie pour aider ces étapes d’analyse et d’émission.

Notez que le côté client peut gérer le jeton de sécurité émis de manière générique en tant que jeton de sécurité XML sans connaître le type de jeton ou effectuer un traitement spécifique au type de jeton. Toutefois, le serveur doit comprendre le type de jeton de sécurité spécifique afin de le comprendre et de le traiter. Les étapes de demande et de réponse du jeton de sécurité utilisent les constructions définies dans la spécification WS-Trust.

Scénarios de fédération plus complexes

Un scénario de fédération peut impliquer plusieurs STS qui forment une chaîne de fédération. Prenons l’exemple suivant :

  • Le client s’authentifie auprès du STS LiveID à l’aide d’un nom d’utilisateur/mot de passe LiveID et obtient un jeton de sécurité T1.
  • Le client s’authentifie auprès de STS1 à l’aide de T1 et obtient un jeton de sécurité T2.
  • Le client s’authentifie auprès de STS2 à l’aide de T2 et obtient un jeton de sécurité T3.
  • Le client s’authentifie auprès du service cible S à l’aide de T3.

Ici, liveID STS, STS1, STS2 et S forment la chaîne de fédération. Les STS d’une chaîne de fédération peuvent effectuer différents rôles pour le scénario d’application global. Parmi ces rôles fonctionnels STS, citons le fournisseur d’identité, le décideur d’autorisation, l’anonymisateur et le gestionnaire de ressources.

Paramètres de requête STS et échange de métadonnées

Pour que le client réussisse WsRequestSecurityToken appel, il doit connaître les paramètres de cet appel (par exemple, le type de jeton et les types de revendication requis), la description de sécurité exigences du canal de requête vers le STS et l’adresse de point de terminaison du STS. L’application cliente peut utiliser l’une des techniques suivantes pour déterminer ces informations :

  • Codez en dur les informations dans l’application dans le cadre des décisions relatives au temps de conception.
  • Lisez ces informations à partir d’un fichier de configuration au niveau de l’application configuré par le déployeur d’application local.
  • Découvrez dynamiquement ces informations lors de l’exécution à l’aide de la fonctionnalité d’importation de métadonnées avec la structure WS_ISSUED_TOKEN_MESSAGE_SECURITY_BINDING_CONSTRAINT.

Pour illustrer l’utilisation de MEX dynamique avec fédération, tenez compte de l’exemple 3 STS ci-dessus. Le client fera d’abord un MEX dynamique avec S pour obtenir des informations sur T3 (c’est-à-dire sur ce qu’il faut demander à partir de STS2) ainsi que sur l’adresse MEX dynamique STS2 (c’est-à-dire l’emplacement où trouver STS2). Il utilisera ensuite ces informations pour effectuer un MEX dynamique avec STS2 pour découvrir des informations sur T2 et STS1, et ainsi de suite.

Ainsi, les étapes MEX dynamiques se produisent dans l’ordre 4, 3, 2, 1 pour créer la chaîne de fédération et les étapes de demande de jeton et de présentation se produisent dans l’ordre 1, 2, 3, 4 pour décompresser la chaîne de fédération.

Note

Windows 7 et Windows Server 2008 R2 : WWSAPI prend uniquement en charge Ws-Trust et Ws-SecureConversation comme défini par profil de sécurité des services web légers (LWSSP). Pour plus d’informations sur l’implémentation de Microsoft, consultez la section syntaxe message de LWSSP.