Avec l’expansion des services en lignes via le cloud ou tout simplement l’interconnexion des SI, le besoin d’exposer des services vers l’extérieur est croissant. Les WebServices sont une solution maintenant éprouvée depuis longtemps pour répondre à ce besoin.

Que l’on utilise SOAP ou REST un problème se pose toujours : comment faire pour sécuriser l’accès à mon SI alors que j’en ouvre une porte en exposant mon métier ?
Souvent utilisés au sein même d’un SI pour gérer des problématiques d’intégration ou d’hétérogénéité des technologies, les Web Services sont aussi de plus en plus souvent exposés sur le web ou à des partenaires.

Lorsque c’est possible, on voit souvent la mise en place d’un canal sécurisé type VPN entre les différents acteurs. Toutefois cela n’est pas toujours possible et cet article a pour but de vous présenter des notions de base liées à la sécurité des web services.

Ayant réalisé des missions, pour OCTO, aussi bien d’architecture que de développement autour ce sujet je vais tenter, via une série d’articles, de vous initier à ce domaine.
La majorité des WebServices de nos clients étant en SOAP je me concentrerais beaucoup plus sur ces derniers.
Cet article se voulant une initiation je ne suis pas rentré dans des détails très techniques, il a uniquement pour but d’attirer l’attention sur la vulnérabilité des protocoles de Web Services.

Identifier le besoin et les risques

Lorsqu’on traite de sécurité il faut toujours commencer par se poser quelques questions

1. Mes données sont elles sensibles?
2. Quel est le risque et quelles sont les conséquences pour mon SI si ces données sont capturées ou utilisés à mauvais escient ?
3. Quelle est la probabilité que quelqu’un attaque mon service ?

Sans rentrer dans les détails de l’analyse de risque qui sort du périmètre de cet article, il est important d’avoir une bonne idée de la réponse à ces questions pour ensuite être capable de déterminer le niveau de sécurité nécessaire.

Valider les données

Une des failles de sécurité qu’on croise le plus dans les applications concerne les points d’entrée des données. Que ce soit un formulaire sur une page web ou un web service, tout point d’entrée de donnée vers votre application est potentiellement une faille de sécurité.
Il est donc essentiel et critique de valider tout ce que les utilisateurs de votre application pourront envoyer à celle-ci.
En effet un WebService est aussi vulnérable qu’un formulaire à l’injection SQL (passage de morceaux de requêtes SQL à un champ de donnée pour les faire interpréter par le serveur) et à d’autres exploit du même acabit. Pour plus de détails je vous invite à consulter cette page de l’OWASP.
De plus, la majorité des WebService utilisant SOAP et donc du XML sont vulnérables à toutes les failles induites par XML.

La validation des données entrées est donc critique pour éviter de nombreuses failles. Pour cela il existe de nombreux moyens.
Première étape, utiliser un WSDL particulièrement stricte sur le typage des données et sur la taille des champs vous protégera déjà de nombreux problèmes.
De la même manière je ne peux rentrer dans les détails sans trop m’étendre, mais la mise en place de DTD, voir mieux de XSD, est un très bon levier.
En effet l’adresse d’un DTD étant indiquée dans le XML, un utilisateur mal attentionné pourra la modifier dans le message qu’il vous envoi, pour changer la méthode de validation des données par celle de son choix (beaucoup plus permissive). Dans le cas d’un XSD seul le serveur sait quel XSD utiliser pour valider le contenu.
Pour les champs spécifiques (adresse email, url…) utiliser des expressions régulières stricte pour valider est une bonne pratique.
Enfin, réfléchissez toujours bien à l’impact des données que l’utilisateur peut vous envoyer et donc manipuler.

Avant de vous présenter quelques failles induites par les WebServices SOAP, je tiens à rappeler qu’il est très facile pour un utilisateur mal intentionné de forger des messages SOAP avec des outils tels que soapUI. A la base conçu pour tester les WebServices cet outil s’avère formidable pour les attaquer en forgeant des messages.

SOAP & XML

Quelques attaques de type DoS (Denial of Service)

Buffer Overflow

SOAP a le gros avantage d’être un protocole très souple, ce qui est une qualité indéniable mais aussi un gros défaut en terme de sécurité.
La souplesse de SOAP réside essentiellement dans la possibilité d’encapsuler à peu près ce que l’on veut (tant que c’est un XML valide) dans un message SOAP.
Premier problème : aucune contrainte de taille.
Ce type d’attaque est généralement couvert par le framework de WebService que vous utilisez (sauf si celui-ci est vraiment obsolète).
Néanmoins un utilisateur mal intentionné qui souhaite réalise un DoS (Denial Of Service) sur votre application pourra s’amuser à essayer d’envoyer un message énorme à vos WebService pour tenter de faire planter le parseur XML qui va démarshaller le message SOAP.
C’est bien entendu les parseurs de type DOM qui chargent tout le message XML en mémoire avant de l’interpréter qui sont vulnérable à ce type de problèmes.
Ce type d’attaque amène à un problème de type BufferOverflow qui induit souvent au plantage complet de l’application.

Il est donc crucial de vérifier la taille des messages reçus avant de tenter de les interpréter.

Récursion infinie

Il s’agit ici d’envoyer un XML récursif au web service. Si le parseur est de type XPath il va partir en boucle infinie.
Exemple :

1

<credit><credit><credit>….

D’autres attaques …

XML Injection

L’idée ici est plutôt d’outrepasser les validateurs de données pour détourner l’usage prévu du Web Service.

Un exemple bien parlant :

1
2
3
4
5
6
7

<transaction> 
<total>4000.00<total>
<credit_card_number>123456789</credit_card_number> 
<total>6.66</total>
<credit_card_number>123456789 </credit_card_number> 
<expiration>17112010</expiration>
</transaction>

En répétant la balise total, l’attaquant tente de changer les valeurs démarshallées par le Web Service pour ainsi payer 6,66 au lieu de 4000 euros. Cet exemple est volontairement simpliste mais, croyez moi, je suis déjà tombé sur des cas ou cela fonctionne.

XPath Injection

L’idée ici est d’attaquer les parseurs de type XPath. En effet si vos requêtes XPath se basent sur les entrées utilisateurs le parseur risque d’interpréter des choses non prévus :

Exemple :
//users/custid[123] va aller récupérer l’utilisateurs ayant pour ID 123, ici l’utilisateur bienveillant à bien mis son Id donc tout va bien.

//users/custid[./age > 1] va aller récupérer tous les utilisateurs dont l’âge est supérieur à 1, ici l’utilisateur malveillant à tenté de mettre un bout de XPath en paramètre et le résultat est assez facile à deviner :)

L’index de requête étant passé en paramètre cela autorise l’utilisateur à utiliser un identifiant client différent du sien. Il est ainsi libre de récupérer les données de tous les utilisateurs de l’application.

Failles XML & SOAP : comment s’en prémunir

Globalement la réponse est très simple : ne réinventez pas la roue.
D’une part pour tout ce qui touche au parsing XML utilisez des frameworks éprouvés et testés par les communautés Open Source par exemple. En réécrivant un parseur XML vous prenez le risque de ne pas penser à tous les types d’attaques présentés précédemment et bien entendus à tous ceux qui ne sont pas exposés ici.
Les frameworks existants sont testés par de nombreux utilisateurs, dont certain très avertis vont remonter ce type de problèmes qui seront très vite corrigés.
Il en va de même pour votre framework de WebService. Utilisez un framework éprouvé et ne réinventer pas la roue en branchant votre parseur XML maison à une socket en écoute sur le port 80. Je caricature mais parfois on croise des choses terrifiantes … Et bien entendu validez tout ce que votre application recevra via des messages SOAP.

Enfin mettez à jour vos frameworks. Les mises à jours de ceux ci (même mineures) incluent souvent des correctifs au failles de sécurités mises en évidences.
Bref à retenir : utilisez des frameworks de parsing XML et de Web Services modernes et éprouvés par la communauté.

Côté réseau et hardware : HTTP, HTTPS, VPN, filtrage IP, filtrage hardware

Une question qui m’est souvent remontée est : quelle type de transport utiliser pour exposer mes Web Services ?

Déjà je tiens à briser un a priori souvent entendu : exposer vos services sur le web en HTTPS ne vous prémunit pas de tous les risques.
Au mieux vous vous protéger des attaques du type man in the middle (et donc qu’un utilisateur intercepte vos messages), mais toutes les autres attaques restent possible.
Il est néanmoins important de savoir que SSL peut, comme un VPN, assurer l’authentification de l’utilisateur si le serveur est correctement configuré.
Cependant, par défaut les canaux cryptés n’ont qu’un seul intérêt : garantir la confidentialité de l’échange. C’est à dire qu’un utilisateur en écoute sur vos échanges ne pourra pas les intercepter (confidentialité de l’échange).
C’est donc très important mais très souvent insuffisant.
Il est toutefois possible de mettre en place une authentification HTTP Basic ou WS Basic devant un WebService via une configuration spécifique du serveur. Néanmoins ces méthodes d’authentification sont peu fiable car le mot de passe circule en clair il est donc interceptable. Donc ces types d’authentification restent tout à fait valables si elles sont utilisées sur un canal crypté.

Les tunnels de type VPN sont déjà un cran au dessus car ils assurent l’authentification de l’appelant (souvent grâce à un certificat) via l’accès VPN. Cela vous protège aussi des écoutes malveillantes car les tunnels VPN sont cryptés. Cela vous apporte, en plus, une limitation sur les utilisateurs qui se connectent à vos services car seuls ceux que vous autorisez explicitement peuvent utiliser le canal VPN. Le canal VPN est donc une très bonne solution mais pas toujours applicable.

Le filtrage d’IP est une protection intéressante pour limiter les appelants de vos services, néanmoins il est relativement facile de masquer son adresse IP par une autre (spoofing d’adresse IP). C’est donc un levier de sécurité intéressant mais insuffisant à lui tout seul.
La mise en place de signature numérique sur les messages permet alors de valider la non répudiation de ceux-ci.

A noter qu’il existe aussi des solutions matérielles type Datapower pour gérer la sécurité de vos services selon les possibilités et la configuration du matériel choisi. Ces solutions sont particulièrement efficaces mais très couteuses. Dans un degrés de risque élevé elles sont toutefois justifiées. Ces solutions ont aussi l’avantage d’être particulièrement efficace pour accélérer la gestion du SSL, gérer l’authentification et les autorisations ainsi que la validation des données des flux.

GDIA : Gestion des identités et des accès.

On en revient finalement toujours au même, lorsque des données et services sont sensibles il est donc nécessaire de les protéger par deux mécanismes classiques : l’authentification et l’autorisation.
Néanmoins ce n’est pas toujours évident à mettre en place sur un Web Service, on ne peut pas simplement mettre un formulaire devant comme sur un site web.

SOAP dans sa souplesse, découpe ses messages en deux parties : un header et un body.
Le body est normalement prévu pour ne contenir que des notions orientées métier. Le header quand à lui est là pour recevoir toutes les notions techniques nécessaires au web service.
C’est donc lui que nous allons utiliser pour contenir les informations d’authentification et d’autorisation.
Les protocoles de sécurité de Web Service tel que WS Sécurity et ses consorts se basent tous sur ce header soap.

De manière un peu généraliste, une bonne pratique est de mettre en place un web service d’authentification. Celui lui ne sera pas filtré car il faut bien qu’il soit appelable la première fois. Il fournira des données de sécurité (comme un jeton unique à durée de vie limitée par exemple) à l’utilisateur qui se sera authentifié via une webmethod prévue à cet effet. L’utilisateur devra ensuite fournir (dans les header soap pour ne pas mélanger les notions techniques et métiers dans le message) son login et son mot de passe ou mieux, ce jeton de sécurité pour chaque appel à vos services métiers.
Côté WebService, un intercepteur devra valider ces données avant de permettre ou rejeter l’appel au service métier.
Cette bonne pratique est de manière très macroscopique le fonctionnement proposé par des protocoles tels que WS Security.

Concernant les mécanismes de gestion des autorisations, nous ne nous étendrons pas sur le sujet car cela peut être soit très simple (read/write ou user/admin) soit très complexe et nécessiter un article complet rien que sur le sujet. On peut toutefois facilement imaginer un intercepteur branché après l’authentification pour vérifier les droits de l’appelant.
Il est bon aussi de savoir qu’un protocole comme OAuth est tout à fait adapté pour gérer les autorisations d’accès à un WebService, d’autant qu’il est fortement compatible avec les services de type Rest qui sont orientés ressources.

Conclusion

Pour conclure il ne faut jamais oublier qu’un WebService est une porte d’entrée vers votre application. Le sécuriser est donc important.
La majorité des failles présentés dans cet article à titre informatif sont couvertes par les frameworks de WebService modernes (Pour java : CXF, Métro, JBossWS ….).
Néanmoins il est important de s’assurer de l’identité et des droits de l’appelant avant de le laisser appeler vos méthodes métiers.
Enfin le cryptage du canal d’échange, quelque soit le moyen, est un très bon levier de sécurité mais comme nous l’avons vu il ne mitige qu’une partie des risques.
La mise en place de signature numérique est aussi un élément aujourd’hui très fiable pour valider la non répudiation de vos messages.
Dans bien des cas, comme dit en introduction, une basic authentification HTTP sur un canal HTTPS s’avèrera suffisant et plus justifié que la mise en place d’outils évolués et relativement complexes à mettre en place tels que WS Security. Il faut donc bien mesurer le besoin et le confronter au risque avant de décider quel niveau de sécurité engager.
Toutefois n’oubliez pas que la notion la plus importante est toujours la validation des données envoyés par vos utilisateurs !

Dans un prochain article je vous présenterais les notions apportées par des protocoles de sécurité de web services tels que WS Security, XML Signature ou XML Encryption.

Suggestion d'articles :

1. Sécurité des services web – 1ère partie
2. HTML5, offline et sécurité
3. GWT et sécurité, se prémunir des CSRF

Cet article est la première partie d’une série de posts concernant la sécurité des services web.

Nous allons présenter dans cette première partie un aperçu de la norme WS-Security pour les services SOAP et les différentes possibilités pour sécuriser des services web.

Les architectures SOA se sont généralisées petit à petit au sein des entreprises pour construire des systèmes capables d’offrir des fonctionnalités partagées via des services.

Ces services peuvent être internes et ne concerner qu’une organisation ou être ouverts sur l’extérieur dans le cadre d’échanges B2B.

Dès lors que l’on propose de la valeur ajoutée ou transporte des données dites sensibles, ces services sont alors confrontés à des buts contradictoires :

• Exposer de l’information et la rendre facilement accessible à un tiers (personne ou système)
• Sécuriser l’information pour la rendre uniquement consommable par des personnes ou des systèmes habilités à la voir et à l’utiliser.

La sécurité est au cœur des préoccupations des entreprises pour garantir la cohérence et la pérennité des systèmes. Pour ce faire, la sécurité doit être prise en compte dès la conception des services web et ceci à tous les niveaux :

• Conception, spécification
• Architecture
• Développement
• Déploiement
• Exécution & exploitation

Au-delà du tout sécuritaire, une approche pragmatique de la sécurité pilotée par les risques est préférable. Rappelons les fonctions de sécurité disponibles qui pourront s’appliquer à des services:

• Authentification : le mécanisme qui permet de vérifier l’identité d’une personne/d’un système
• Habilitation : le droit d’accéder ou non à une fonctionnalité, à une donnée
• Intégrité (ou signature) : la non modification d’une donnée échangée
• Imputabilité : traçabilité des actions d’un individu sur un système
• Confidentialité (ou chiffrement) : la non lisibilité de la donnée par un tiers ne partageant pas un secret

Les stacks de sécurité des web services (WS-Security & co) sont à priori complexes et chers à mettre en œuvre. Toutefois, on peut trouver des exemples concrets où ces solutions ont un réel intérêt (signature des messages par exemple).

Nous allons présenter dans cet article un aperçu de la norme WS-Security pour les services SOAP et les différentes possibilités pour sécuriser des services web.

WS-Security

WS-Security est un standard pour sécuriser des services web SOAP uniquement. Ce dernier aborde les aspects classiques comme l’authentification, l’habilitation mais également des besoins plus rares comme le chiffrement, la signature. Cette norme s’applique uniquement au niveau des messages échangés et n’a aucun impact sur le protocole et le transport choisis. Il repose sur l’ajout d’éléments dans les headers/en-têtes SOAP. Ce standard appelé aussi WSS (Web Services Security) tente de normaliser les échanges sécurisés de messages et de garantir l’interopérabilité entre systèmes.

Des Profiles sont disponibles pour couvrir l’ensemble des problématiques liées à la sécurité (authentification, chiffrement et signature). Le consortium OASIS vise la standardisation des spécifications WS-* pour permettre une meilleure interopérabilité entre les technologies.

Authentification

L’authentification s’appuie sur la notion de token c’est à dire des headers SOAP capables de véhiculer les credentials (typiquement un login et un mot de passe) jusqu’au service cible. Le niveau de confidentialité de ces données échangées peut également être choisi (hash de password, chiffrement des données,.).

Les principaux tokens disponibles sont :

• User Name Token : échange de couples login/mot de passe
• SAML Token : échange de données d’authentification au format XML SAML
• X509 Token : échange de données d’authentification par certificat (authentification forte)

D’autres tokens permettent de l’authentification via des systèmes tiers comme Kerberos.

Voici un exemple de header avec un token user name non chiffré :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<s11 :Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu= "..." >
</s11><s11 :Header >
...
<wsse :Security>
</wsse><wsse :UsernameToken>
</wsse><wsse :Username>NNK</wsse>
<wsse :Password Type="...#PasswordDigest">
weYI3nXd8LjMNVksCKFV8t3rgHh3Rw==</wsse>
<wsse :Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse>
< wsu:Created>2003-07-16T01:24:32Z< /wsu:Created>
 
 
...
</s11>
...

Chiffrement

Le chiffrement peut se faire via différents algorithmes, symétriques ou asymétriques. La norme WS-Security permet l’envoi de métadonnées du client de web service au web service cible (end-point) afin de décrire la méthode de chiffrement utilisée et permettre des échanges de clé si besoin.

Les messages sont constitués de plusieurs parties (header, message), chacune pouvant être chiffrée ou non selon la configuration choisie.

Voici un exemple de chiffrement du corps du message avec un certificat X509 :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<s11 :Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..." xmlns:xenc="...">
</s11><s11 :Header>
<wsse :Security>
<xenc :ReferenceList>
<xenc :DataReference URI="#bodyID"/>
</xenc>
</wsse>
</s11>
<s11 :Body>
<xenc :EncryptedData Id="bodyID">
<ds :KeyInfo>
</ds><ds :KeyName>CN=Hiroshi Maruyama, C=JP</ds>
 
</xenc><xenc :CipherData>
</xenc><xenc :CipherValue>...//le message chiffré// </xenc>
 
 
</s11>

Ainsi, plutôt que d’utiliser une couche de transport gérant la confidentialité des données, on chiffre tout ou partie du message.

Signature

L’objectif de la signature est de garantir l’origine du message en échangeant un jeton chiffré avec un secret partagé (clé symétrique ou asymétrique). Elle se se fait via des certificats X509 et peut être appliquée sur des messages en clair ou chiffrés selon la configuration choisie.

Comme pour le chiffrement, il est possible de signer à la fois le corps des messages mais également leurs en-têtes.

Voici un exemple de header WS-Security avec une signature du corps du message à base de certificat X509 :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<s11 :Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..." xmlns:xenc="...">
</s11><s11 :Header>
<wsse :Security>
<xenc :ReferenceList>
<xenc :DataReference URI="#bodyID"/>
</xenc>
</wsse>
</s11>
<s11 :Body>
<xenc :EncryptedData Id="bodyID">
<ds :KeyInfo>
</ds><ds :KeyName>CN=Hiroshi Maruyama, C=JP</ds>
 
</xenc><xenc :CipherData>
</xenc><xenc :CipherValue>...//le message chiffré// </xenc>
 
 
</s11>

WS-Security : une norme de plus en plus accessible

La norme WS-Security est vaste mais la complexité inhérente à la norme est de plus en plus masquée et devient même dans certains cas complètement externe aux développements applicatifs.

En Java par exemple, l’adoption de nouveaux frameworks et leur intégration avec Spring a favorisé la mise en place de WS-Security par simple déclaration au niveau de la configuration Spring. Un service SOAP peut donc intégrer un chiffrement ou une signature par simple ajout d’un bloc XML.

Des constructeurs d’appliances comme IBM vont également dans ce sens en proposant des boitiers dédiés à la sécurité des web services. Ces derniers sont capables de modifier à la volée des messages SOAP pour leur appliquer des fonctions de sécurité.

Où placer la sécurité ? Jusqu’où aller ?

Les fonctionnalités d’un système n’étant pas exposées aux mêmes risques et cela de façon uniforme, l’approche sécuritaire pilotée par les risques permet d’ajuster le niveau de combinaison et donc d’ajuster les coûts et délais induits lors de la mise en œuvre/exploitation.

Généralement, la plupart des services web implémentés dans les entreprises n’embarquent pas de brique sécurité à proprement parler et les organisations ont plutôt tendance à s’appuyer, dans la plupart des cas, sur les procédures et matériels existants pour la gérer au niveau de l’infrastructure. Cette démarche a l’avantage de ne pas ou peu impacter les développements applicatifs.

La mise en place de tout ou partie des 5 fonctions citées précédemment doit être étudiée selon le besoin de chaque contexte. Il sera ainsi possible de trouver le meilleur compromis pour mitiger les risques en combinant ces fonctions. Voici quelques exemples de combinaisons possibles :

• Contrôle d’accès aux services : utiliser un réseau sécurisé par des firewalls pour limiter la consommation de services à telle ou telle machine.
• Confidentialité des données échangées over HTTP : HTTPS pour le transport des données
• Confidentialité et intégrité pour des messages XML over HTTP: HTTPS pour le transport, signature personnalisée ajoutée dans le message XML
• Confidentialité et intégrité pour des messages SOAP : HTTPS pour le transport, signature du message avec WS-Security
• .

Le déploiement de la sécurité autour des services web va être principalement guidé par les contraintes de mise en œuvre (légale ou réglementaire de non répudiation, de confidentialité des données), le besoin en terme de confidentialité des données et la topologie des équipes infra, sécurité et projet au sein de l’entreprise :

• Le niveau de maitrise par les équipes de développement des frameworks et outils (IDE, stack SOAP ou REST, intégration sur les serveurs de développement),
• Le niveau de maitrise par les équipes de production des briques d’infrastructure et éventuellement des frameworks utilisés sur les projets (firewalls, reverse-proxy, appliance XML, PKI/Certificats.),
• La facilité de communication entre ces équipes est donc nécessaire pour mettre en production des services sécurisés et fluidifier les échanges,
• Les besoins d’interopérabilité entre les systèmes exposant ou consommant des services sécurisés.

Voici quelques exemples de combinaisons que nos architectes retrouvent souvent chez des clients.

Utiliser la sécurité des infrastructures

• Réseaux séparés ou de confiance (firewalls)
• (optionnel) VPN pour la confidentialité sur l’extranet/internet
• (optionnel) Authentification éventuellement déléguée à un VPN

Dans ce cas, la sécurisation repose intégralement sur les briques réseau. Elle n’impacte pas les équipes de développement ce qui rend la sécurité complètement transverse à l’application. Ce cas d’utilisation s’applique dans des échanges B2B avec des partenaires (réseau VPN dédié entre le producteur et le consommateur de services) ou dans les intranets.

S’appuyer sur les protocoles standards

• HTTP pour le protocole
• SSL pour la confidentialité
• Basic Auth pour l’authentification (user, mot de passe) (granularité au niveau de l’application)

Ces briques sont communes et maitrisées par l’ensemble des technologies utilisées dans les entreprises (Java, .Net, C/C++, Progiciels, .). Le pattern repose entièrement sur le protocole (HTTP+SSL) et permet d’assurer à la fois l’authentification et la confidentialité (les messages transite en clair dans un tuyau crypté HTTPS).

Cette typologie est la plus répandue aujourd’hui. On peut l’utiliser à la fois pour des échanges internes à l’entreprise pour des services sensibles que pour relations B2B classiques utilisant l’Internet (ex: banque qui fait de l’assurance vie en marque blanche). Ce mode de sécurisation est flexible puisque l’accueil de nouveaux clients ne nécessite aucune modification de configuration existante (pas de réseau à créer contrairement à la précédente).

S’appuyer sur les couches applicatives et des normes telles que WS-Security

• HTTP (synchrone) ou JMS (asynchrone) pour le protocole
• Authentification par Username Token en WS-Security
• Chiffrement des messages via WS-Security

Cette solution est plus complexe à mettre en œuvre puisqu’elle impacte les couches applicatives et nécessite que les messages soient échangés en SOAP.

En revanche, l’application de la sécurité au niveau du message permet sa circulation sur un transport non sécurisé (http sur Internet par exemple) et une interopérabilité accrue.

Cette solution est intéressante dans le cas de services très ouverts sur Internet qui doivent garantir un fort niveau de confidentialité/intégrité du message.

La suite de cette série d’articles illustrera quelques uns de ces cas d’application.

Références

• Octo Livre Blanc « Services Web : Choix Architecturaux »
• Octo « Gestion des identités »
• OASIS User Name Token Profile
• Spécification WS-Security
• Définition SAML

Suggestion d'articles :

1. Initiation à la sécurité des Web Services
2. Refactoring .NET avec UML, 1ère partie
3. Problèmes courants: Imprécision des calculs mathématiques (1ère partie)

Vous concevez une architecture distribuée en utilisant des services Web ?

Bien ! Mais vous êtes-vous posé la question du style architectural, c’est-à-dire du choix entre une approche orientée appel de procédure à distance ou une approche orientée manipulation de ressources ?

Et celle du choix entre une pile de protocoles lourde ou une pile légère pour les échanges avec les services Web ? Vos décisions auront un impact important sur les propriétés de votre système : complexité, facilité d’évolution, obsolescence technique, capacité à monter en charge, stabilité, ouverture.

Nous proposons ici un tour d’horizon des grandes options architecturales… et quelques précieux conseils…

Téléchargez la suite sur www.octo.com

Suggestion d'articles :

1. Versioning des services: principes et éléments d’architecture…
2. Versioning de services REST
3. Les Publications OCTO