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 commercial suivant : la société de fabrication de pièces automobiles Contoso Ltd souhaite permettre aux employés autorisés de son client Fabrikam Inc d’accéder en toute sécurité au service Web de commande de pièces de Contoso. Une solution de sécurité pour ce scénario consiste pour Contoso à configurer 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 de convenir du type de jeton de sécurité et du contenu qui représenteront l’autorisation de Fabrikam et qui seront acceptables pour Contoso. Par exemple, il peut être décidé qu’un certificat X.509 approuvé avec le nom d’objet « CN=Fabrikam Inc Supplier STS » doit signer un jeton SAML pour que ce 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 de partie) ou «https://schemas.contoso.com/claims/order » (pour l’autorisation d’ordre partiel).
  • 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 de domaine Windows), son autorisation à commander des parties est vérifiée et un jeton SAML de courte durée contenant les revendications appropriées est émis et signé par le certificat X.509 décidé ci-dessus. L’application de classement des pièces contacte ensuite le service Contoso présentant le jeton SAML émis pour s’authentifier et effectuer la tâche de classement.

Ici, le STS Fabrikam agit en tant que « partie émettrice » et le service de pièces Contoso en tant que « 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 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, vous pouvez utiliser la fonction WsRequestSecurityToken . Vous pouvez également utiliser une bibliothèque de fournisseur de jetons de sécurité côté client, telle que 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 dispose du jeton de sécurité, il peut créer un canal vers le service spécifiant WS_XML_TOKEN_MESSAGE_SECURITY_BINDING pour 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 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 structure de description de sécurité au moment de la création de l’écouteur, comme tout autre service Web sécurisé. Il peut ensuite analyser les charges utiles des messages de requête entrants pour valider les demandes de jeton et renvoyer les jetons émis en tant que charges utiles de message de réponse. Actuellement, aucune fonctionnalité n’est fournie pour faciliter 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 pour le comprendre et le traiter. Les étapes de demande et de réponse de 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 de LiveID STS à 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, les STS LiveID, 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 les exemples de tels rôles fonctionnels STS, citons le fournisseur d’identité, le décideur d’autorisation, l’anonymiseur et le gestionnaire de ressources.

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

Pour que le client effectue un appel WsRequestSecurityToken réussi, il doit connaître les paramètres de cet appel (tels que le type de jeton et les types de revendication requis), les exigences de description de sécurité 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 de 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 au moment 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 la fédération, considérez l’exemple 3 STS ci-dessus. Le client effectue d’abord un MEX dynamique avec S pour obtenir des informations sur T3 (c’est-à-dire, ce qu’il faut demander à STS2) ainsi que l’adresse MEX dynamique STS2 (c’est-à-dire, où trouver STS2). Il utilisera ensuite ces informations pour effectuer un MEX dynamique avec STS2 afin de découvrir des informations sur T2 et STS1, et ainsi de suite.

Ainsi, les étapes MEX dynamiques ont lieu 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 ont lieu dans l’ordre 1, 2, 3, 4 pour dérouler la chaîne de fédération.

Notes

Windows 7 et Windows Server 2008 R2 : WWSAPI prend uniquement en charge Ws-Trust et Ws-SecureConversation tels que définis par le 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.