L'Architecture Orientée Services et J2EE. Ahmed ALAMI's WEBLOG.

Dans ce chapitre on va décrire un modèle de sécurité faisant intervenir les concepts de l’architecture orientée services, des spécifications WS-* et plus particulièrement WS-Security et la plate-forme J2EE.

La sécurité des services Web fait partie intégrante de la stack des spécifications WS-*.

Plusieurs standards lui sont associés. Les plus importants et les plus stables en terme de spécifications sont cités ci-dessous. Pour plus de détails concernant chaque spécification se reporter aux autres livres blancs sur la sécurité niveau données et messages.

Afin de comprendre l’interaction entre les participants à une transaction basée sur un service Web, il conviendrait de dresser la cinématique relative au flux de messages transportés entre l’infrastructure Client et l’infrastructure Serveur. Ensuite seront associées les différentes spécifications, standards et outils associés à chaque étape de ce flux.

Les schémas mettent en jeu un client et un serveur, la cinématique peut être adaptée dans le cas d’un échange avec un intermédiaire ou plusieurs.

La cinématique ci-dessous ne fait pas référence au contexte de sécurité partagé et constitue un modèle dont la topologie reste simple et compréhensible.

Ci-dessous Le flux des messages

1. Le code client initialise l’environnement relatif à l’infrastructure client en récupérant des informations sur le proxy de connexion et soumet la requête désirée. Dans le contexte de la plate-forme J2EE, le client utiliserait l’api Jax-RPC.
2. Une fois l’infrastructure client alertée de la requête du client, cette dernière associe un processus à cette requête. Le processus correspond à un ensemble de services coordonnés et orchestrés. Pour chaque service, l’infrastructure client se connecte à l’annuaire des services et récupère la définition liée au service en téléchargeant le fichier WSDL représentatif.
3. une fois le fichier WSDL récupéré, l’infrastructure client se connecte à l’annuaire de policy (politique ou stratégies) puis récupérer les stratégies associées à l’appel du service Web. Ces stratégies peuvent contenir des exigences en terme de sécurité.
4. L’infrastructure Client Interprète les stratégies de sécurité de l’invocation du service, par exemple savoir quelle partie du message doit être cryptée. En ayant le fichier de policy, l’infrastructure client identifie le type de jetons de sécurité attendus par l’infrastructure serveur.
5. L’infrastructure client demande au client de spécifier son identité afin de l’autoriser.
6. Une fois l’identité du client validée, un jeton de sécurité est récupère via le fournisseur d’identité.
7. Lors de cette étape, le client constitue le message de la requête SOAP. Il signe le message, crypte les parties sensibles et associe le jeton de sécurité à l’entête du message. Une fois le message sécurisé créé il est enfin envoyé à l’infrastructure du serveur.
8. L’infrastructure serveur s’occupe de valider le message de le décrypter et de vérifier le jeton de sécurité afin d’installer une relation de confiance. Une fois la confiance établie, le service final est invoqué.

Ci-dessous sont associés à chaque étape de cette des technologies, standards et spécifications.