A la découverte de WS-Security

Les services Web offrent la possibilité d'échanger des données entre des applications Web à travers le réseau Internet par HTTP. Utilisé pour les services Web, SOAP (Simple Object Access Protocol) est un protocole permettant de faire des appels de procédure sur un ordinateur distant à l'aide d'un serveur d'application et d'échanger des messages entre deux points par HTTP.

Toutefois, le protocole HTTP ne permet pas une sécurisation suffisante des messages. C'est pour pallier ce manque que les spécifications WS-Sécurity (Web Service Security - WSS) ont vu le jour.

Ce que WS-Security ajoute aux spécifications existantes est une structure pour incorporer des mécanismes d'authentification, de signature et de chiffrement dans un message SOAP. WSS permet aux messages SOAP d'identifier celui qui demande, mais également de signe le message et de crypter le contenu du message. Le message doit permettre :

- d'identifier le ou les entités impliquées dans le message,
- de prouver que l'entité vient du bon groupe,
- de prouver que l'entité a les bons droits d'accès,
- de prouver que le message n'a pas changé.

Pour ce faire, un message SOAP contient plusieurs "en-têtes" WSS pour apporter des données liées à sécurité.

Authentification

WSS cherche à encapsuler les interactions de sécurité décrites ci-dessus avec un ensemble d'en-têtes de SOAP. WSS fournit un grand nombre de façons de valider un utilisateur. Mais trois méthodes sortent du lot : soit un jeton utilisateur (Username Token) donne l'identifiant et le mot de passe dans le cas où le service Web utilise l'identification client, soit WSS fournit des jetons de sécurité binaires (BinarySecurity Token) d'authentification comme les tickets Kerberos et les certifications X.509.

Signature

Il faut être sûr que l'identité utilisée dans le message est bien celle qui a créé le message. En utilisant la signature (par exemple XML signature), le receveur du message SOAP peut savoir que les éléments signés n'ont pas changé en cours de route. Chaque méthode (X.509, Kereros ou Username) fournit un élément secret pouvant être utilisé pour signer le message. Par exemple le message utilisant l'authentification du Username Token peut être signé par le mot de passe (voir l'exemple plus bas).

Chiffrement

Pour le chiffrement - procédé grâce auquel on peut rendre la compréhension d'un document impossible à toute personne n'ayant pas la clef de déchiffrement - il est possible d'utiliser XML Encryption. Il existe plusieurs procédés de cryptage :
- le cryptage symétrique : chacune des deux parties dialoguant ont une clef connue par elles seules ; mais ce procédé pose le problème de l'échange de la clef,
- le cryptage asymétrique, utilisant une clé publique pour le cryptage et une clé secrète pour le décryptage.

Exemple

Voici un exemple d'entête pour la méthode avec pour commencer la définition du type de document (DTD) :

<xs:element name="UsernameToken"> 
      <xs:complextype> 
          <xs:sequence>
             <xs:element ref="Username"/>
               <xs:element ref="Password" minoccurs="0"/>
             </xs:sequence>
          <xs:attribute name="Id" type="xs:ID"/>
         <xs:anyattribute namespace="##other"/>
     </xs:complextype>
</xs:element>

Et voila un aperçu en XML:

<wsse:usernametoken>
    <wsse:username>scott</wsse:username>
    <wsse:password type="wsse:PasswordText">
     password</wsse:password>
</wsse:usernametoken>

Mais il est plus judicieux de faire un peu plus sécurisé…

<wsse:UsernameToken>
    <wsse:Username>scott</wsse:Username>
    <wsse:Password Type="wsse:PasswordDigest">
        KE6QugOpkPyT3Eo0SEgT30W4Keg=</wsse:Password>
    <wsse:Nonce>5uW4ABku/m6/S5rnE+L7vg==</wsse:Nonce>
    <wsu:Created xmlns:wsu=
        "http://schemas.xmlsoap.org/ws/2002/07/utility">
            2002-08-19T00:44:02Z
    </wsu:Created>
</wsse:UsernameToken>

Le mot de passe est alors brouillé avec une fonction de hachage SHA-1 - fonction qui convertit un grand ensemble en un plus petit ensemble, l'empreinte. Il est impossible de la déchiffrer pour revenir à l'ensemble d'origine. Le mot de passe "haché" envoyé par l'expéditeur est la concaténation du nonce, de l'heure de création et du mot de passe par la fonction de hachage.

Lorsqu'il le reçoit, le client crée de sont côté un mot de passe du même type avec les mêmes informations à sa disposition. Si les deux mots de passe hachés (celui qu'il a reçu et celui qu'il a généré) concordent, c'est que le mot de passe doit être correct. Cette protection présente l'inconvénient de ne pas protéger des attaques répétitives : il faut inclure une durée d'expiration au-delà de laquelle le mot de passe "haché" devra être regénéré.