index
SOA : WS-Policy
Interceptor
Un interceptor permet de traiter un message entrant ou sortant.
Concrètement, c'est une classe, dont une méthode est executée lorsque un message arrive (ou sort).
Exemple
- Trace : Un interceptor est un moyen d'avoir une trace de tous les messages qui arrivent ou qui partent.
- Authentification: Un interceptor "intercepte" le message, controlle le user/password (ou autre) puis peut renvoyer une erreur selon le résultat de la procédure d'authentification.
plusieurs interceptors peuvent être chainés.
L'avantage de cette technique est de ne pas mélanger des notions techniques et des notions métier, ou des notions technique de nature différentes. (Par exemple, il ne serait pas pratique de devoir passer en paramètre le user/mot de passe à tout les services... sayHello(user,password,name) n'a pas vraiment de sens... et que se passerait-il si on décidait de passer en plus du user/password une clé ? On devrait réécrire tout les services ? )
Avec un interceptor, le service reste sous la forme sayHello(name), puis l'interceptor peut manipuler le message pour ajouter/retirer des informations comme le user/mot de passe.
On peut trouver des interceptors côté client (pour justement ajouter un mot de passe...) ou côté serveur (pour contrôler le mot de passe)
La notion d'interceptor marche bien tant que l'on est dans la même JVM (le client et l'interceptor, ou le service et l'interceptor.
La notion d'interceptor existe dans la plupart des framework/norme, que se soie cxf, axis2, jax-rpc, jax-ws etc... le nom change parfois de interceptor à handler.
Sécurisation d'un web service
Il y a 2 approches pour traiter les problèmes de sécurité par les Web-Services.
- On peut sécuriser le protocole en utilisant https
- On peut sécuriser les messages SOAP.
Les nouvelles normes WS-Security proposent de normaliser la seconde approche. Les Web-Services et les messages SOAP sont conçus pour être indépendant du protocolle. Il est donc logique d'avoir les moyens de gérer la sécurité sans passer par le protocolle.
Si la notion de sécurité doit être centralisée à travers des services utilisant plusieurs technologie (java, ruby, .NET , php..), on peut alors faire des "intermédiaires", et l'on parle alors de "Security as a Service" (car ce n'est plus un handler qui s'occupe de la securité, mais un service a part entière).
Exemple de mise en oeuvre de ws-policy avec cxf
exemple server avec simple authentification par user password
exemple client
References