Alors que le marché a les yeux rivés sur le concept d'architecture orientée services ou SOA, les travaux en cours dans le domaine des Web Services passent quasiment inaperçus.

Les technologies Web Services sont pourtant le fer de lance de ces architectures, puisqu'elles leur permettent de "briser" les frontières des systèmes d'information. Soyons tout de même indulgents : plus les éditeurs avancent dans le domaine de Web Services, moins il est facile de décrypter ces travaux, d'identifier les spécifications structurantes, de connaître l'état des implémentations…

Compte tenu du nombre de spécifications publiées ou à venir, le temps où les éditeurs se glorifiaient d'implémenter telle ou telle spécification est révolu.

Il est pourtant fondamental d'avoir à sa disposition les outils techniques permettant d'implémenter les services incontournables, comme la sécurité. Cela fait maintenant trois ans que Microsoft et IBM ont publié leur roadmap concernant la sécurité des Web Services, roadmap qui se proposait d'adresser les fondamentaux de la sécurité (authentification et habilitation, confidentialité, intégrité, relations de confiance, etc.) par de nouvelles spécifications.

Où en sont ces travaux ? Les outils et technologies sont-ils arrivés à maturité ?

Comment trouver l'aiguille…
Le premier obstacle auquel on se heurte lorsque l'on essaye de faire une synthèse des travaux sur les Web Services - et en particulier sur la sécurité - est le nombre invraisemblable de spécifications, embryonnaires ou finalisées, et de "spécifiants".

On dénombre aujourd'hui une cinquantaine d'initiatives, dans des domaines tels que la gestion transactionnelle, le monitoring, la qualité de service, le transport, et bien entendu la sécurité.

La plupart de ces initiatives sont désignées par un acronyme débutant par " WS- ", et peuvent être organisées de manière hiérarchique, dans le sens où certaines spécifications (comme WS-Security) constituent le socle d'autres spécifications.

D'ailleurs, le terme "WS-Security" ne devrait plus être utilisé ; cette spécification fait partie de celles qui ont changé de nom au cours de leur évolution, ajoutant à la confusion (le nouveau nom consacré étant, depuis 2004, SOAP Message Security). Le terme WS-Security reste néanmoins utilisé pour désigner SOAP Message Security et les spécifications qui lui sont complémentaires.

Enfin, parmi cette constellation de spécifications, certaines sont à l'initiative d'un seul éditeur, ce qui laisse penser que le chemin vers la standardisation sera long… si standardisation il y a.

En ce qui concerne les implémentations, WS-Security peut d'ores et déjà être mis en œuvre avec les technologies actuelles : les implémentations de Microsoft (le package Web Service Enhancements) ou bien de la communauté Apache (le package WSS4J) sont fonctionnelles, même si leur utilisation nécessite un temps de compréhension et d'appropriation important.

Dans un scenario "full Microsoft", il est possible d'envisager WS-Security en production, même si l'API continue à évoluer fortement : les exemples sont nombreux, la documentation assez complète. Pour l'environnement J2EE, il est difficile d'apporter un jugement argumenté ; cela supposerait de tester toutes les implémentations du marché, qu'elles soient commerciales ou non. Quoi qu'il en soit, l'implémentation Open Source la plus plébiscitée (celle d'Apache) est peu intuitive, et la documentation assez obscure.

Les désillusions
En examinant ces diverses spécifications, et l'outillage qui les accompagne, on est obligé de constater que la maturité de ces technologies est encore loin d'être atteinte. Les implémentations de WS-Security peuvent être mises en œuvre, le principal obstacle étant l'interopérabilité.

Pour les autres spécifications, même si elles sont terminées et publiées, le plus dur reste à faire : proposer des implémentations stables et interopérables, les intégrer dans les principaux outils de développement du marché, fournir de la documentation claire pour accompagner la mise en œuvre des cas d'utilisation classiques, etc.

Même avec WS-Security, le travail de mise en œuvre peut être ralenti par de nombreuses désillusions. Tout d'abord, il faut bien comprendre que les spécifications officielles - celles qui détaillent la sémantique de dialogue avec SOAP - s'adressent avant tout aux éditeurs, et non aux intégrateurs.

Pourquoi le développeur final aurait-il à comprendre la sémantique de communication, s'il a à sa disposition des API de haut niveau permettant de s'en abstraire ? Combien de développeurs en technologies Microsoft connaissent le fonctionnement interne du protocole DCOM ?

On trouve sur Internet quantité d'articles et de présentations sur le vocabulaire SOAP de WS-Security, de XML Signature, ou XML Encryption… alors que la documentation réellement importante est celle de l'implémentation que l'on utilise.

On pourrait avoir l'impression qu'il est facile de trouver de l'information et des exemples, alors qu'il n'en est rien. En clair, il ne faut pas mélanger les rôles : aux éditeurs la charge de créer des API de haut niveau documentées et garantissant l'interopérabilité, et aux intégrateurs la responsabilité des les utiliser à bon escient.

Seconde désillusion dans le travail d'implémentation : la lisibilité des documents XML échangés. Il y a quelques temps, on vantait parmi les mérites de XML sa grande lisibilité, le fait qu'il soit compréhensible par un être humain.

Soyons clair : les messages échangés avec un Web Service sont longs et horriblement compliqués. La syntaxe SOAP était déjà complexe ; l'ajout des éléments propres à WS-Security et aux autres spécifications n'arrange évidemment rien. En allant plus loin, on pourrait même s'interroger sur la raison d'être d'un formalisme textuel comme XML au sein des Web Services…

Enfin, autre constat que l'on peut faire à l'utilisation des implémentations de WS-Security, l'enjeu de l'interopérabilité repose complètement sur les épaules des éditeurs. Ils sont les garants du caractère standard de la communication SOAP mise en place avec leurs API, et l'aspect standardisation se limite à cela.

Ne cherchons pas dans les Web Services un moyen de capitaliser des compétences techniques : d'une implémentation à l'autre les API et les outils sont fondamentalement différents. Elles conduiront naturellement à une spécialisation des compétences, même si le vocabulaire sera commun à tous les développeurs de Web Services.

Vers une consolidation ?
Ce panorama, un peu morose, permet de faire le point sur la mise en œuvre d'architectures sécurisées à base de Web Services. Des solutions techniques existent pour les spécifications fondamentales comme WS-Security, alors que pour les autres les solutions sont plus anecdotiques.

En mettant en œuvre des cas d'utilisation simples, on commence à entrevoir quelques unes des limites du modèle : les échanges SOAP sont de moins en moins accessibles à cause de leur complexité, et les API qui permettent de les mettre en œuvre sont peu matures et mal documentées.

L'interopérabilité est encore une cible lointaine ; elle dépend essentiellement des éditeurs qui doivent prouver leur capacité à respecter des standards et à les communiquer efficacement à leurs clients.

Enfin, il est important de noter que cet article se limite volontairement aux spécifications intégrées dans GXA (Global XML Architecture), le modèle d'architecture de Microsoft et IBM. Le marché contient en effet de nombreuses autres initiatives, parfois complémentaires, parfois concurrentes, traitant de la sécurité des échanges XML.

Au mieux, ces spécifications sont compatibles avec le modèle GXA ; c'est le cas notamment de SAML, puisqu'il est possible d'utiliser une assertion SAML comme preuve d'identité WS-Security. Au pire, les spécifications sont en concurrence directe, comme le sont WS-Federation et Liberty Alliance. Cela donne naissance à des initiatives déconcertantes, comme la spécification Web SSO MEX publiée par Microsoft et Sun, qui définit un protocole de SSO permettant de rendre interopérables les implémentations WS-Federation et Liberty...