Gestion de l'authentification d'un service web via WS-SECURITY

Problème

Comment gérer l'authentification d'un service web via WS-SECURITY avec Adélia Studio ?

Solution

l'authentification WS-SECURITY ne repose pas sur l'authentification HTTP classique par le container web. L'authentification se fait par un échange d'informations via la section <header> du message SOAP.

Pour assurer une authentification du service via un header WS-SECURITY, il existe à ce jour 2 possibilités :

Première possibilité

Création manuelle du header "ws-security" pour l'authentification (via la directive *ENTETE_MSG_MEM ou *ENTETE_MSG_FILE de l'ordre SW_APPELER) [solution la plus simple]

L'en-tête à ajouter est le suivant :

<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken wsu:Id="UsernameToken" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Username>user</wsse:Username>
<wsse:Password>password</wsse:Password> 
</wsse:UsernameToken>
</wsse:Security>

Par défaut, le password est du plain text (correspond au type PasswordText). Si le type doit être absolument renseigné, alors il faut écrire :

<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">password</wsse:Password>

Pour un password de type DIGEST :

<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">AFFFHH==!</wsse:Password>
<wsse:Nonce>ksSedFljK</wsse:Nonce> 
<wsu:Created>2013-09-13T15:34:43.000Z</wsu:Created>

Deuxième possibilité

Génération automatique du header WS-SECURITY avec une configuration du module RAMPART [solution plus compliquée à mettre en oeuvre; nécessite l'écriture en C d'une DLL spécifique].

La solution ci-dessous est non exhaustive mais indique la marche à suivre.

a. Déclarer, dans le fichier CfgWebServices.xml le module "rampart" avec une référence à un fichier "client-policy.xml" contenant la définition des éléments de sécurité :

<service><Module>
   <Name>rampart</Name>
   <Description>
      <PolicyFile>client-policy.xml</PolicyFile>
   </Description>
</Module>
</service>

b. Ecriture du fichier client-policy.xml en question. Le clent-policy.xml devrait s'inspirer/se calquer à celui utiliser par le serveur.
Exemple dans le cas ou la police de sécurité semble requérir uniquement un userToken (user/password avec un mot de passe non chiffré).

client-policy_C.xml

client-policy_java.xml

c. Ecrire la DLL (ou classe) référencée dans le fichier client-policy.xml (cf. élément PasswordCallbackClass) et la déployer dans le dossier ad-hoc.
Cette DLL/Classe assure la gestion des mots de passe et s'appuie sur une interface RAMPART.

Exemples :

pwcb.c

pwcb.java