Les services Web XML sont-ils sûrs ?
Compte tenu des nombreux aspects liés à la sécurité, à l'authentification et aux autorisations, à la confidentialité et à l'intégrité des données, et compte tenu du fait que la spécification SOAP ne mentionne pas la sécurité, il est aisé d'imaginer que la réponse à cette question est « non » ! Pourtant, examinons de plus près les services Web XML de Microsoft®. Actuellement, la création de services Web XML sécurisés n'est pas chose impossible.

Lorsque l'on aborde la question de la sécurité de ces services, il faut examiner les points suivants :

- Qu'essayons-nous de réaliser ? Restreindre l'accès à un service Web XML à des utilisateurs dûment habilités, éviter que les messages ne soient lus par des indésirables, etc.
- Comment allons-nous y parvenir ? Par le Réseau, la couche transport, le système d'exploitation, un service ou une application.
- Quel niveau d'interopérabilité recherchons-nous dans le cadre de notre solution ? Un niveau local ou global.

Comment donc sécuriser les services Web XML actuellement proposés ? En répondant à ces questions et en appliquant les mêmes techniques que celles que nous employons pour sécuriser n'importe quelle autre application Web, notamment :

- Par la sécurisation des connexions
- Par l'authentification et l'autorisation des interactions

Comme nous allons le voir, ces techniques offrent des solutions élaborées qu'il est possible de combiner pour optimiser les résultats. Par exemple, il est possible d'utiliser un pare-feu avec un service Web XML afin de limiter l'accès à certaines fonctionnalités (méthodes) en fonction de la nature du client et de stratégies préétablies.

Pour plus de clarté, commençons par examiner chacune des solutions actuellement disponibles pour sécuriser l'infrastructure.

Sécurisation de l'infrastructure
Un service Web XML sûr repose sur une infrastructure sécurisée. Microsoft offre diverses technologies qui, intégrées dans un plan de sécurité global, permettent à une entreprise d'assurer la sécurité de son infrastructure informatique. Le processus de planification relatif à sa mise en œuvre suppose :

- Une identification approfondie des risques potentiels liés à l'environnement (virus, pirates, catastrophes naturelles) ;
- Une analyse des conséquences d'une violation de la sécurité et des mesures préventives à envisager ;
- Une stratégie d'implémentation soigneusement planifiée pour intégrer les mesures de sécurité à tous les niveaux du réseau de l'entreprise, en fonction de l'identification et de l'analyse préalablement réalisées.

Sécurisation des connexions
Une des solutions les plus faciles pour sécuriser des services Web XML est d'assurer la fiabilité de la connexion entre le client et le serveur. Pour atteindre cet objectif, plusieurs techniques sont possibles, selon la portée du réseau et le profil d'activité des interactions. Citons, parmi les plus répandues et les plus accessibles, les techniques suivantes : des règles basées sur l'existence d'un pare-feu, le protocole SSL (Secure Sockets Layer) et les réseaux privés virtuels (VPN, Virtual Private Network).

Si vous savez exactement quels ordinateurs doivent accéder à vos services Web XML, vous pouvez appliquer des règles de pare-feu afin de limiter l'accès sur la base d'adresses IP connues. Cette technique s'avère utile lorsque vous souhaitez restreindre l'accès aux ordinateurs au sein d'un réseau privé, LAN ou WAN par exemple, et que le contenu des messages n'est pas un secret (par conséquent, pas de cryptage). Les pare-feu tels que ISA Server (Internet Security and Acceleration) de Microsoft offrent éventuellement un ensemble de règles reposant sur des stratégies et permettent de limiter, à des degrés divers, l'accès aux ordinateurs par les clients, en fonction de leur origine ou de leur identité. Cette solution est par exemple applicable pour que des clients aient accès aux diverses fonctionnalités (méthodes) d'un même service Web XML.

Le protocole SSL (Secure Sockets Layer) quant à lui permet d'établir des connexions sécurisées sur des réseaux non sécurisés (tel qu'Internet). SSL crypte et décrypte les messages qui circulent entre un client et un serveur. En cryptant les données, vous empêchez la lecture des messages pendant leur transfert. SSL crypte un message envoyé par le client puis le transmet au serveur. Lorsque le serveur reçoit le message, SSL le décrypte et vérifie qu'il provient de l'expéditeur correct (ce processus est appelé « authentification »). Le serveur, ou le client et le serveur, peuvent proposer des certificats utilisés dans le cadre de l'authentification pour permettre une identification en plus du cryptage. Bien que le protocole SSL constitue une solution tout à fait efficace en termes de sécurisation des communications, il pèse sur les performances d'une façon non négligeable. Les services Web XML de Microsoft gèrent le protocole SSL intégré aussi bien au niveau du client que du serveur.

Un réseau privé virtuel (VPN) est une extension d'un réseau privé qui assure des connexions sur des réseaux partagés ou publics comme Internet. Via un VPN, vous pouvez envoyer des données d'un ordinateur à un autre sur une connexion sécurisée. Semblable par bien des côtés au protocole SSL, le VPN est une connexion point-à-point à long terme. Aussi exige-t-il une connexion à long terme pour que le gain en terme d'efficacité soit sensible.

Authentification et autorisations
Authentification : L'authentification est le processus qui consiste à vérifier l'identité d'une personne (ou, plus généralement, de « quelque chose »). Cette « personne » ou ce « quelque chose » est l'entité. L'authentification nécessite des preuves, appelées informations d'identification. Par exemple, une application cliente peut fournir un mot de passe comme informations d'identification. Si elle présente des informations correctes, le système suppose qu'elle est bien ce qu'elle prétend être.

Autorisations : Une fois que l'identité de l'entité est authentifiée, des autorisations peuvent être accordées. Pour qu'il y ait accès à un système, les informations concernant l'entité sont comparées avec des informations de contrôle des accès, par exemple avec une liste ACL (Access Control List). Les accès peuvent varier selon les clients. Ainsi, certains clients ont un accès total au service Web XML, alors que d'autres n'ont accès qu'à certaines tâches. Vous pouvez accorder à certains clients un accès complet à l'ensemble des données, à d'autres un accès à un groupe limité de données, ou encore un accès en lecture seule.

Une solution parmi les plus simples pour authentifier les accès à un service Web SML est d'utiliser les fonctionnalités d'authentification du protocole employé pour l'échange des messages. Pour la plupart des services Web XML, il s'agit d'exploiter les fonctions d'authentification du protocole HTTP. Microsoft Internet Information Server (IIS) et ISA Server proposent plusieurs mécanismes d'authentification sur HTTP par le biais de Windows 2000 Server.

- De base : Utilisé pour une identification non sécurisée et semi-sécurisée des clients, car le nom d'utilisateur et le mot de passe sont envoyés sous la forme de texte codé base64 (binaire), facile à décoder. IIS autorise l'accès au service Web XML si les informations d'identification correspondent à un compte utilisateur valide.
- De base sur SLL : Identique au précédent, sauf que le canal d'échange est crypté, ce qui assure la protection du nom d'utilisateur et du mot de passe. Ce mécanisme est une bonne solution pour Internet ; cependant, l'utilisation du protocole SSL a une incidence non négligeable sur les performances.
- Digest : Utilise la technique du hachage pour transmettre les informations d'identification du client de manière sécurisée. Toutefois, ce mécanisme risque de ne pas être largement pris en charge par les outils des développeurs utilisés pour créer des applications clientes de services Web XML. IIS autorise l'accès au service Web XML si les informations d'identification correspondent à un compte utilisateur valide.
- Authentification intégrée de Windows : Utile essentiellement dans l'environnement Internet. Utilise NTLM ou Kerberos. Le client doit appartenir au même domaine que le serveur ou à un domaine sécurisé du domaine du serveur. IIS autorise l'accès au service Web XML si les informations d'identification correspondent à un compte utilisateur valide.
- Certificats clients sur SSL : Chaque client doit obtenir un certificat. Les certificats sont mappés sur des comptes utilisateur auxquels se réfère IIS pour autoriser l'accès aux services Web XML. Il s'agit d'une solution intéressante en environnement Internet, bien que l'usage de certificats numériques ne soit pas très répandu pour le moment. En outre, ce mécanisme risque de ne pas être largement pris en charge par les outils des développeurs utilisés pour créer des applications clients de services Web XML. Disponible pour des connexions SSL, il peut enfin avoir une incidence sur les performances.

Du point de vue du programmeur de services Web XML, l'un des avantages offerts par ces mécanismes d'authentification est qu'aucune modification de code n'est nécessaire dans le service Web XML : en effet, IIS et ISA Server effectuent toutes les vérifications d'authentification et d'autorisation par rapport aux listes ACL avant que le service ne soit appelé. Cependant, lors de la mise en œuvre du client, certaines opérations supplémentaires peuvent s'avérer nécessaires. L'application cliente doit répondre aux requêtes du serveur concernant les informations d'authentification.

Il existe d'autres techniques pour mettre en œuvre l'authentification dans les services Web XML, notamment le recours à des services externes comme ceux que l'on trouve dans Microsoft® .NET Passport, l'utilisation des fonctionnalités de session de Microsoft ASP.NET, ou la mise en place d'une méthode personnalisée.

Phase suivante : l'interopérabilité
Comme vous le constatez, les techniques standard de sécurisation des applications Web sont applicables seules ou combinées afin d'offrir des services Web XML sûrs et fiables. Ces techniques s'inspirent d'une riche expérience et sont tout à fait efficaces. Cependant, elles n'offrent pas de solution intégrée au sein de l'architecture des services Web XML. À mesure que le service Web XML augmente en complexité (nécessité de traverser des frontières sécurisées, présence sur plusieurs systèmes ou entreprises, etc.), les programmeurs sont contraints de bâtir des solutions personnalisées qui, bien qu'efficaces, n'offrent pas une véritable interopérabilité.

Pour répondre à ces besoins et accroître l'interopérabilité entre les services Web XML, Microsoft et ses partenaires travaillent à la mise au point d'un ensemble d'applications de sécurité qui s'appuient sur le mécanisme d'extensibilité de la norme SOAP pour proposer des fonctionnalités de sécurité optimales, directement intégrées dans les services Web XML.

Le langage WS-Security (XML Web Services Security Language) est au cœur de la solution et améliore les échanges SOAP grâce aux trois fonctionnalités suivantes : transfert des informations d'identification, intégrité des messages, confidentialité des messages. Ces fonctionnalités ne constituent pas en soi une solution de sécurisation complète ; le langage WS-Security est un bloc fonctionnel qui s'utilise conjointement avec l'infrastructure et d'autres protocoles de services Web XML pour répondre à diverses exigences en matière de sécurisation des applications. L'architecture Global XML Web Services de Microsoft englobe le langage WS-Security et des spécifications associées qui fournissent un cadre contribuant à faire évoluer l'infrastructure des services Web XML.

Initialement publié sur MSDN France le 29 mars 2002