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

Les composants de XML Signature

Les signatures XML sont des signatures digitales utilisées pour fournir les mécanismes d’authentification, d’intégrité des données et la non répudiation. Le dispositif les plus intéressant de XML Signature et qui lui confère une faculté de flexibilité est la capacité à signer des portions spécifiques du document XML. Cette flexibilité peut être utile pour assurer l’intégrité de certaines parties signées par plusieurs partenaires participants à une seule et même transaction.

XML Signature peut gérer plusieurs types de données, il peut transporter par exemple du code HTML signé, un contenu binaire (un fichier ZIP), du contenu XML ...

Le processus de validation de la signature XML est effectif quand l’objet signé indique la référence de l’objet d’origine. XML Signature permet de gérer ces références à plusieurs niveaux :

• Une URI,
• La même que la ressource d’origine,
• Enveloppée dans l’entête du document signé (la signature est le père),
• Enveloppe l’objet signé (La signature est un enfant).

La signature des documents XML est fortement liée au cryptage.

D'un concept similaire à celles des certificats de sécurité, les signatures XML servent à garantir que l’intégrité du contenu d'un document XML et d’assurer au destinataire que ce dernier n’a pas changé en cours de route. La signature des fichiers XML utilise une notion appelée « canonicalization » pour compenser les différences typographiques des systèmes de fichiers et parseurs correspondants.

Lorsqu'une signature est appliquée au contenu, la canonicalization utilise les données et balises du fichier XML pour créer une signature unique, ignorant des informations telles que les sauts de ligne et les tabulations.

Lors de la réception d'un document, le système client effectue une "transformation de la signature XML", qui fait la distinction entre le contenu crypté avant signature et le contenu crypté après. Toutes les données cryptées après la signature sont décryptées ; l'intégrité des données est vérifiée en appliquant la même méthode de canonicalization au contenu, par comparaison du résultat à la signature incluse dans le document XML.

XML est un format riche en terme de sémantique, fournit une représentation structurée des données, se décrit en fichiers texte et présente la facilité d’être utilisé dans un contexte Web. Tout ceci permet à XML de devenir un standard incontournable dans les échanges de type e-Business entre une entreprise et ses partenaires. Ceci dit, cet échange ouvre une difficulté ou un challenge, celui de sécuriser les données de ces échanges. Cette sécurisation consiste en le cryptage des données véhiculées dans le document XML ainsi que leur signature digitale.

Prenons un exemple très parlant : Dans le cas ou plusieurs partenaires participent à une transaction donnée, chaque partenaire veut garder les données de la transaction qui le concerne sécurisée et identifiable. Les standards usuels de sécurisation ne permettent pas de choisir une portion des données à sécuriser vu leur pauvreté syntaxique à ce niveau.

Les initiatives de sécurité qui permettent de répondre à ces besoins sont les suivants : XML Signature et XML Encryption. Tous deux sont standards. Les chapitres à venir traitent de ces standards ainsi que les différentes étapes d’utilisation.

XML Signature et XML Encryption sont des spécifications fondamentales pour la protection des données relatives à des services web. C’est parce que les spécifications relatives aux services Web sont basées sur XML que ces technologies sont indispensables et intéressantes en même temps. Par exemple vous pouvez crypter un document WSDL pour le protéger des accès qui ne sont pas autorisés ou le signer si vous voulez le protéger contre la manipulation.

Les spécifications SAML, XACML et XKMS ne sont pas relatives aux services Web directement, elles sont adaptables pour ces derniers. C’est le cas contraire de XML Signature et XML Encryption, d’où l’intérêt de ces technologies.

Il est fondamental d’utiliser ces technologies quand des données XML doivent être protégées en dehors des messages SOAP et quand les metadata des services Web doivent être protégés de tout accès non autorisé. Ws-Security utilise XML Signature et XML Enryption afin d’assurer la confidentialité et l’intégrité des messages SOAP, mais il ne décrit pas comment utiliser ces technologies pour les données en dehors du contexte SOAP et WSDL, par exemple dans le cas d’applications qui passent par des formats intermédiaires de documents XML.

Utilisée conjointement avec le cryptage XML, une signature XML garantit que les données reçues correspondent exactement aux données transmises

Ci-dessous la réponse de Pierre Bonet à une question que j'ai posté sur le site http://www.orchestranetworks.com/fr.

Bonne lecture.

Question

Bonjour,

Merci de mettre votre expertise au service des questions posées par les visiteurs du site. Ma question est rapide, mais je doute bien que la réponse soit pas de même.

Comment peut-on concrètement aligner MDA sur SOA ou vice versa?

Merci de votre réponse et bonne journée.

Réponse
C’est une question d’actualité. Je travaille depuis plusieurs mois sur un projet de grande ampleur qui met en place une stratégie SOA + MDA.

Nous pensons qu’il faut distinguer le MDA de la couche SOA métier (profiles XSD, WSDL et BPEL) et le MDA de la couche SOA de l’architecture applicative (par exemple profiles Pojo, EJB, Mapping Hibernate, Pattern State Machine…).

L’alignement dont vous parlez s’opère donc selon ces deux couches. Pour le SOA métier, il faut bien noter que l’implémentation des profiles XML restent encore peu matures ; il faut souvent assurer un développement spécifique des générateurs et accepter l’usage de profiles non standards (stéréotypes, tagged values). Malheureusement, l’OMG ne propose pas encore de profiles sur cette couche, sans doute à venir sur 2006. Attention, l’aspect génération XML pour les règles de type pré- et post-conditions à partir, par exemple, d’une représentation formelle en OCL dans les modèles UML n’est pas possible, à ma connaissance et malheureusement, aujourd’hui, sauf en laboratoire.

Pour le SOA de l’architecture applicative, il existe des profiles UML standards publiés par l’OMG (Corba, Ejb, Test…) et d’autres assez répandus sur le marché (pattern State machine, Factory…).

Il ne faut pas négliger le profile UML pour la génération du MLD et MPD à partir d’un modèle de classe du niveau conceptuel.

Sur la partie IHM, on trouve aussi des profiles UML pour Struts (le framework MVC en Java) par exemple.

Au-delà de la génération de code dont je viens de parler, le MDA concerne aussi la génération automatique de la documentation ou plus précisément le packaging de la documentation. Par exemple, le pseudo-code est positionné directement dans les modèles puis repris dans les documentations générées. Du côté ingénierie, on peut envisager de remonter le code source logiciel dans les modèles selon un mécanisme de type round-trip ou assimilé. Mais ce mécanisme est loin d’être évident à grande échelle… De même, l’idée d’une génération automatique de code Java pour le corps des méthodes reste encore théorique. Au mieux, on peut trouver des générateurs pour les assertions OCL, utilisées comme pré- et post-conditions des services.

Sur ces points et d’autres il y a beaucoup de sujets à détailler et je manque d’espace pour les présenter ici ; j’ai écris il y a quelques mois une contribution sur le thème Offshore + MDA + SOA qui apporte des compléments. Je vous invite à le consulter en téléchargement libre sur notre site : http://www.orchestranetworks.com/fr/soa/extraitoffshore.cfm

Vous pouvez aussi rester attentif aux publications sur notre site. Nous allons proposer en téléchargement libre, début Septembre, un document complet de synthèse de nos meilleures pratiques SOA et Web services qui détaille l’architecture logique SOA que nous préconisons. C’est une base de départ qui peut être utile pour contribuer à la mise en place d’une stratégie MDA.

Espérant contribuer à vos réflexions et merci pour votre question ouverte.

Pierre Bonnet