Flux pour l'établissement d'un jeton de contexte de sécurité pour la sécurisation des conversations
Ce scénario d'exemple explique comment l'émetteur établit avec le destinataire le jeton de contexte de sécurité (SCT), à l'aide du protocole WS-Trust pour la sécurité basée sur la session. Une fois le jeton de contexte de sécurité établi, des clés dérivées du jeton de contexte de sécurité sont utilisées pour la signature et le chiffrement du message SOAP, afin de fournir une protection au niveau des messages. Cet exemple porte essentiellement sur les échanges de messages qui utilisent le jeton de contexte de sécurité dans le flux global des messages SOAP.
La spécification Web Services Secure Conversation (WS-SecureConversation) d'OASIS (Organization for the Advancement of Structured Information Standards) décrit les méthodes permettant d'établir une session sécurisée entre l'émetteur et le destinataire des messages SOAP. La spécification WS-SecureConversation définit également la façon dont le protocole Web Services Trust (WS-Trust) est utilisé pour établir un jeton de contexte de sécurité. Le produit prend en charge la version 1.3 et la version Draft de la spécification WS-SecureConversation.
WebSphere Application Server permet à un noeud final d'émettre un jeton de contexte de sécurité pour WS-SecureConversation et fournit ainsi une session sécurisée entre l'émetteur et le destinataire des messages SOAP.
La figure ci-dessous décrit le flux requis pour l'établissement d'un contexte sécurisé et l'utilisation de la sécurité basée sur la session.

Echange de messages entre l'émetteur et le destinataire
La figure ci-dessous explique comment les messages sont échangés entre l'émetteur et le destinataire pour établir le jeton de contexte de sécurité. Le deux protocoles WS-Trust, RequestSecurityToken (RST) et RequestSecurityTokenResponse (RSTR), servent à demander le jeton de contexte de sécurité au noeud final de destination.
La règle d'amorce permet de sécuriser le RST et de valider la demande RSTR, ce qui est généralement différent de la stratégie de sécurité de l'application.

Scénario décrivant la procédure d'utilisation de la conversation sécurisée
- Le client envoie une demande de jeton de contexte de sécurité de type RST (RequestSecurityToken) RST) à un noeud final d'application avec sa clé secrète (entropie et longueur de la clé voulue) et demande la clé secrète du service cible.
Cette demande est généralement sécurisée à l'aide de la sécurité de service Web asymétrique qui est définie dans la règle d'amorce.
- Le RST est traité par le service d'accréditation et, si la demande est sécurisée en fonction de la stratégie de sécurité, le service d'accréditation renvoie le jeton de contexte de sécurité comportant la clé secrète du service cible, à l'aide d'un élément WS-Trust RequestSecurityTokenResponse (RSTR).
Cette demande est généralement sécurisée à l'aide de la sécurité de service Web asymétrique. Le client vérifie si le RSTR est digne de confiance, en fonction de la règle d'amorce.
- Si le RequestSecurityTokenResponse est digne de confiance, le client sécurise (signe et chiffre) les messages d'application ultérieurs à l'aide des clés de session.
Les clés de session sont dérivées du secret du jeton de contexte de sécurité qui est obtenu des messages WS-Trust RequestSecurityToken et RequestSecurityTokenResponse initiaux échangés entre l'émetteur et le destinataire.
- La spécification définit un algorithme de la procédure de dérivation de la clé en fonction du secret initial. Le service web cible calcule la clé dérivée à partir des métadonnées calculées dans l'en-tête de sécurité du message SOAP et du secret initial.
- Le service web cible utilise la clé dérivée pour vérifier et déchiffrer le message en fonction de la stratégie de sécurité de l'application.
- Le service web cible utilise la clé dérivée du secret pour signer et chiffrer la réponse en fonction de la stratégie de sécurité de l'application.
- Répétez les étapes 3 à 6 tant que l'échange de messages n'est pas terminé.
Utilisation des clés dérivées du secret du jeton de contexte de sécurité
Une fois le jeton de contexte de sécurité établi, les messages d'application sont sécurisés avec la protection de message à l'aide des clés dérivées du secret du jeton de contexte de sécurité. Les clés dérivées permettent de sécuriser les messages d'application via la signature et le chiffrement de ces messages. Le jeton de contexte de sécurité contient un UUID qui sert à identifier un secret partagé. L'UUID de jeton peut être utilisé dans le message SOAP afin d'identifier le jeton de contexte de sécurité pour les échanges de messages. Le secret doit être stocké en mémoire par les participants à la session (dans ce cas, l'émetteur et le destinataire) et protégé. Le fait d'altérer le secret compromet la conversation sécurisée entre les participants.

Un scénario similaire, sauf dans le cas Web Services Reliable Messaging (WS-ReliableMessaging) est possible du point de vue de WS-SecureConversation. Consultez l'exemple correspondant à l'établissement d'un jeton de contexte de sécurisé pour la sécurisation de la messagerie fiable.