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.

Figure 1. Présentation du flux entre le client, le service Web et le service de jeton de sécuritéCette figure présente le flux entre le client, le service de jeton de sécurité et le service Web
En général, pour utiliser la conversation sécurisée, les étapes suivantes doivent être suivies :
  1. 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.

  2. 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.

  3. 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.

  4. 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.
  5. 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.
  6. 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.
  7. 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.

Remarque : La procédure suivante doit être utilisée uniquement dans des environnements de développement et de test.

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

  1. Effectuez une copie d'une règle de conversation sécurisée par défaut afin de pouvoir personnaliser l'ensemble de règles pour votre propre environnement.
    1. Lancez la console d'administration et cliquez sur Services > Ensembles de règles > Ensembles de règles de l'application.
    2. Sélectionnez la case à cocher en regard d'un ensemble de règles existant qui suit les spécifications WS-SecureConversation. Par exemple, vous pouvez cliquer sur la case à cocher en regard de SecureConversation. Cet ensemble de règles est un des ensembles de règles d'application liés à la conversation sécurisée préconfigurée qui est répertoriée dans le tableau. L'ensemble de règles SecureConversation a une règle d'amorçage qui permet de faire correspondre l'ensemble de règles par défaut pour le service d'accréditation afin d'émettre et de renouveler des jetons.
    3. Cliquez sur Copier.
    4. Entrez un nom unique pour la nouvelle copie de l'ensemble de règles d'application SecureConversation. Par exemple : CopyOfSCPolicySet
    5. Facultatif : Changez la description de la version personnalisée de cet ensemble de règles.
  2. Associez l'ensemble de règles et la liaison à l'application.
    1. Cliquez sur Applications > Types d'application > Applications WebSphere enterprise > nom_application.
    2. Cliquez sur Liaisons et ensembles de règles du fournisseur de services ou Liaisons et ensembles de règles de client de service pour associer des ressources à l'ensemble de règles CopyOfSCPolicySet. La liaison générale est attribuée automatiquement comme liaison par défaut.
    3. Vous pouvez utiliser les options Lier un ensemble de règles et Affecter une liaison pour sélectionner une liaison ou un ensemble de règles différent.

Résultats

Une fois ces instructions suivies, la conversation sécurisée est configurée.

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.


Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twbs_enablesecureconv
Nom du fichier : twbs_enablesecureconv.html