Au début des services Web, leurs fournisseurs considéraient que la sécurité serait entièrement gérée au niveau de la couche transport, au moyen de SSL/TLS (HTTPS). C’est pourquoi les standards de services Web initiaux n’abordaient pas la sécurité. Mais celle-ci a pris de l’importance dès lors que les services Web se sont multipliés. Une transaction de service Web passe souvent par de nombreuses mains, dont chacune a besoin d’accéder à certaines parties de la transaction mais pas à d’autres.En 2002, IBM, Microsoft et VeriSign ont proposé un standard de sécurité pour répondre à ces besoins. Appelé WS-Security, la spécification résultante est vaste et compliquée parce qu’elle couvre un large éventail d’aspects de sécurité des services Web. En 2004, apparaissait la version 1.1 du standard, plus dépouillée et plus puissante que le premier jet, mais encore volumineuse.
Heureusement, vous pouvez utiliser le standard dans vos applications de services Web sans le comprendre entièrement. WebSphere Application Server (WAS) 5.0 et ultérieure supportent WS-Security et se chargent virtuellement de tout l’aspect configuration. D’autres environnements de développement de services Web ont des fonctionnalités comparables. Une fois que vous aurez compris ce qu’apporte WS-Security et comment il fonctionne, vous pourrez commencer votre propre expérience.
WS-SECURITY : rôle et fonctionnement
Les transactions de services Web contiennent souvent des données sensibles réservées à certains interlocuteurs. Le cryptage SSL/TLS concernant toute la transaction ne fonctionne que si la transaction du service Web intéresse deux parties : un initiateur et un récepteur. Mais les messages de services Web ne vont pas forcément directement au serveur de destination. Ils passent souvent par des intermédiaires : pare-feu d’application, agents de courtage, et autres.
Ces intermédiaires ont besoin d’accéder à certaines parties du contenu SOAP (Simple Object Access Protocol) et peuvent en fait modifier ce contenu. La seule exigence de SOAP vis-à-vis des agents transmettant des messages SOAP, est que la logique du contenu reste homogène. Par conséquent, un intermédiaire peut réécrire le message, changer l’espace vierge, les fins de lignes et même l’ordre des éléments, tant que le XML résultant est l’équivalent logique de l’original. Il est évident que cela exclut tout cryptage de bout en bout ou tout contrôle d’intégrité fondé sur des signatures numériques.
Pour résoudre ce problème, WS-Security offre une double possibilité : protéger certaines parties du message SOAP et prendre en compte les changements susceptibles de se produire quand le message change de mains. Il fournit toute la protection des mécanismes de sécurité classiques, comme SL/TLS et IPSec, tout en permettant aux parties concernées de mener à bien une transaction de service Web.
Téléchargez cette ressource
Sécuriser votre système d’impression
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
