Activation de la conversation sécurisée
Utilisation de la conversation sécurisée pour sécuriser les messages des applications de services Web.
Avant de commencer
Les applications qui contiennent des services Web doivent avoir été déployées.
Pourquoi et quand exécuter cette tâche
Le projet de 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. Le projet de spécification WS-SecureConversation définit également comment utiliser le protocole OASIS WS-Trust (Web Services Trust) pour établir un jeton de contexte de sécurité (SCT). Pour plus d'informations, voir la spécification Web Services Secure Conversation d'OASIS.
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.

- 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é.
Dans la spécification WS-SecureConversation, un contexte de sécurité est représenté par le jeton de sécurité <wsc:SecurityContextToken>. L'exemple suivant présente la syntaxe d'assertion pour un élément <wsc:SecurityContextToken>.
<wsc:SecurityContextToken wsu:Id="..." ...>
<wsc:Identifier>...</wsc:Identifier>
<wsc:Instance>...</wsc:Instance>
...
</wsc:SecurityContextToken>
Le jeton de contexte de sécurité ne prend pas en charge les références à lui-même à l'aide d'identificateurs ou de noms de clés. Toutes les références doivent utiliser un ID (désignant un attribut wsu:Id) ou une référence <wsse:Reference> à l'élément <wsc:Identifier>.
WebSphere Application Server fournit ces stratégies préconfigurées connexes à la conversation sécurisée :
- L'ensemble de règles SecureConveration suit les spécifications WS-SecureConversation et WS-Security et fournit un ensemble de règles avec la conversation sécurisée activée et l'utilisation de clés dérivées du jeton de contexte de sécurité pour la signature et le chiffrement des messages d'application.
- L'ensemble de règles Username SecureConversation suit les spécifications WS-SecureConversation et WS-Security et ajoute l'authentification à l'aide du jeton Username.
- La règle LTPA SecureConversation suit les spécifications WS-SecureConversation et WS-Security et fournit l'authentification à l'aide des jetons LTPA.
Dans cet exemple, l'ensemble de règles SecureConversation par défaut, la liaison WS-Security par défaut et la liaison TrustServiceSecurityDefault permettent d'activer la conversation sécurisée. L'ensemble de règles SecureConversation par défaut a à la fois la règle d'application (symmetricBinding) et la règle d'amorçage (asymmetricBinding). La règle d'application permet de sécuriser les messages d'application et la règle d'amorçage permet de sécuriser les messages RequestSecurityToken (RST).
Un service d'accréditation qui émet un jeton de contexte de sécurité est configuré avec la règle système TrustServiceSecurityDefault et la liaison TrustServiceSecurityDefault. La règle de confiance a la charge de la sécurisation des messages RequestSecurityTokenResponse (RSTR). Si la règle d'amorçage est modifiée, la règle de confiance doit être modifiée pour correspondre aux deux configurations.
Les liaisons par défaut WS-Security utilisées par défaut contiennent des exemples de fichiers de clés et elles doivent être personnalisées avant utilisation dans un environnement de production. Pour l'environnement de production, l'utilisation de liaisons personnalisées est conseillée. Si le profil est créé via la sélection de l'option Créer le serveur à l'aide du modèle de développement, vous pouvez ignorer les étapes 2 et 3.
Pour configurer la conversation sécurisée, configurez l'ensemble de règles et ajoutez une assertion de règle à la règle, procédez comme suit :
Procédure
Résultats
Que faire ensuite
Consultez ensuite le scénario exemple pour établir un jeton de contexte de sécurité afin de sécuriser une conversation sécurisée.