L'Architecture Orientée Services et J2EE. Ahmed ALAMI's WEBLOG.

Il existe plusieurs formats des jetons de sécurité (Certificats X 509, Ticket Kerberos, Assertions SAML, politiques XACML, etc), ceci nécessite de la part des acteurs d’un service Web de comprendre ces différents jetons. Par conséquent, il n’existe aucune garantie qu’un récepteur de message SOAP puisse comprendre un jeton de sécurité envoyé par un client d’un service web. Un nouveau problème se pose, celui de l’interopérabilité en terme de sécurité. Comment sera mappé un jeton de sécurité reçu de la part d’un intervenant dans le service Web ? Par quel jeton sera-t-il remplacé ? Quel type de jeton renvoyer pour qu’il soit compréhensible par le client ?

Pour repondre à ce besoin d’interopérabilté et pour installer une confiance entre les intervenants dans le service web, deux specifications ont été introduites : WS-Trust et WS-SecurityPolicy. On se concentrera sur la premiere specification : WS-Trust.

Introduction à WS-Trust :

WS-Trust est utilisé afin d’assurer l’interopérabilité entre les multiples jetons de sécurité qui peuvent être transportés dans un message sécurisé via WS-Security. Cette interopérabilité ne se place pas qu’au niveau syntaxique. Par exemple, un service peut accepter des jetons Kerberos mais peut ne pas comprendre des jetons générés par des centres de distribution arbitraires.

En général, un service qui reçoit un message SOAP de type WS-Security doit gérer trois problématiques principales :

• Le format : le format peut être incompréhensible.
• La confiance : Le récepteur peut ne pas établir une chaîne de confiance.
• L’espace de nommage : Le récepteur peut avoir une syntaxe différente de celle de l’émetteur.

WS-Trust resout ces problématiques potentielles en établissant un système d’échange basé sur un protocole request/response. Le client envoie une RequestSecurityToken au STS (Security Token Service), la requête comporte le jeton de sécurité utilisé pour l’échange. Le STS répond avec une RequestSecurityTokenResponse contenant le nouveau jeton.

Les trois problématiques sont donc gérées comme suit :

• Le format : Le STS renvoie un jeton totalement compréhensible par le service récepteur.
• La confiance : Le jeton retourné a été signé par le STS ; le service récepteur s’attend à avoir en retour un jeton valide afin d’établir une relation de confiance.
• L’espace de nommage : La syntaxe correspond à celle attendue par le récepteur. En plus de l’échange des jetons de sécurité, WS-Trust permet de demander de jetons de sécurité et de les valider.

Ci-dessous, une figure représentant les différents échanges effectués entre le STS et le client du service sécurisé.