Tuyaux, protocoles et messaging ne sont que les véhicules des données à transmettre. Encore faut-il que ces moyens de transport se fassent oublier en ne faisant pas obstacle aux différentes informations de "service" qui doivent accompagner les données de business. D'où l'éclosion des frameworks qui assurent la cohérence d'ensemble entre partenaires des échanges électroniques de données, y compris la sécurité, la fiabilité (message envoyé une fois et une seule etc.) et l'enchaînement des messages d'un scénario de business. RosettaNet est un "bon"  framework qui marche, mais qui est payant, et cher. Reste les Services Web (SW) et ebXML, qui sont des frameworks, apparus ensemble et basés tous les deux, en ce qui concerne le messaging, sur les spécifications de SOAP .

Aussi bien les SW que ebXML sont des usines à gaz dont la mise en oeuvre complète se fait attendre. Pléthore de standards du WS-* pour les SW, avec parfois des concurrences comme entre d'une part, WS-ReliableMessaging de Microsoft, IBM et alii, et d'autre part, WS-Reliability de Sun, Oracle etc. Oasis vient d'installer un Web Services Reliable Exchange ( WS-RX) Technical Committee pour réconcilier tout le monde, les deux propositions n'étant pas très éloignées, d'après Gartner. Pour ebXML au contraire, c'est plutôt le retard de spécifications qui a obéré sa mise en oeuvre d'ensemble. Mais avec justement un temps d'avance pour le messaging, dont la spécification ebMS2 est déjà largement mise en place. Alors quel critère de choix en ce qui concerne ce messaging ?

Si l'on s'engage, même prudemment,  dans une SOA interne basée sur les SW, autant se familiariser avec leurs spécifications pour les utiliser ensuite en externe, lorsque WS-* sera stabilisé et reconnu par tous les offreurs à Oasis et au WS-I.

Mais autant utiliser ebMS2 si l'on veut seulement disposer d'un outil opérationnel pour de simples échanges de documents, quand on n'a pas  besoin d'invoquer un service, comme c'est le cas dans les échanges A2A, entre administrations, collectivités locales etc. C'est, en tout cas, ce que ne déconseille pas l'ADAE dans une étude comparative ! D'autant qu'ebMS2 peut emmener dans son header toute la sécurité souhaitable pour les aspects réglementaires.

Une sécurité de base des échanges, surtout quand ils sont automatisés entre applications sous forme de Services Web (SW), c'est que l'application appelée reconnaisse l'application appelante. Mais peut-on se faire reconnaître et authentifier partout avec la même identité, le SSO, single sign-on, pour éviter d'avoir à gérer un portefeuille comportant autant d'identifiants et mots de passe que de destinataires ? Oui, si sites et applications se font confiance, non seulement pour se référer à cette identité unique d'un tiers, mais pour se la passer de l'un à l'autre quand le "tiers" surfe. Etant entendu que, sans sur-veillance humaine, cette "signature unique" assume la responsabilité des échanges.  

Comme un système unique est inacceptable, d'où l'abandon d'un Passport universel par Microsoft, il faut bien un standard pour fédérer des systèmes d'identification autonomes. C'est ce que permet d'assurer un TC d'Oasis avec SAML 2.0 (Security Assertion Markup Language) qui devient la base d'une gestion "fédérée" des identités. Une assertion SAML étant contenue dans l'en-tête d'un message SOAP pour transférer d'un site à l'autre les données d'authentification et d'autorisation (AA) relatives à un utilisateur. La fédération des identités pour les SW devenant ainsi elle-même un SW qui pourra aussi rendre compte de qui a accédé pour faire quoi. A noter que SAML n'est que le moyen de transport et ne fournit pas, par lui-même, les AA qui peuvent provenir "d'autorités" utilisant LDAP, PKI, SSL etc. SAML 2.0 pourra transporter la sécurité fournie par des standards à venir. Par exemple, les précisions complémentaires sur les autorisations apportées par le schéma XACML, autre récent standard d'Oasis. De même, SAML 2.0 permet une meilleure articulation avec la gestion des identités ID-WSF du consortium Liberty Alliance où se retrouvent les offreurs (sauf Microsoft) qui ont d'ailleurs com-mencé à tester l'interopérabilité de leurs produits respectant SAML.

De même que les SW permettent une intégration loose-coupling entre applications par des messages, la fédération des identités par SAML permet l'intégration des identités tout en sauve-gardant la privacy des données qui ne sont pas censées être partagées. Fédération qui est aussi utile en interne, dans une architecture SOA.

Espérons que Liberty Alliance et Microsoft (qui évoque SAML dans sa vision) aboutiront bientôt à une confédération de leurs fédérations d'identités. Sun et Microsoft s'y emploient (cf.page 1).