Sécurité des Web Services

Introduction

Les Web Services ont été conçus pour répondre à un besoin d’interopérabilité. Leur objectif étant de faciliter la communication entre environnements de nature hétérogène.

Face à cette problématique opérationnelle, la prise en compte de la sécurité n’a pas été systématique. Cependant depuis quelques années, sous l’impulsion d’acteurs majeurs comme IBM et Microsoft (avec des projets comme WS-Security lancé en 2002), certains travaux visent à combler cette lacune.

Pour répondre à cette problématique, les différentes solutions existantes reposent sur une sécurisation :

  • Au niveau réseau  - visant à assurer principalement le chiffrement, l’intégrité et l’authentification des échanges réseau.
  • Au niveau applicatif - apportant des fonctionnalités plus étendues telles que la fédération d’identités.

 

Bonnes pratiques de sécurité

Les Services Web, par nature ouverts et interopérables, constituent des points d’entrée privilégiés pour des attaques. Afin de pallier à ces vulnérabilités potentielles, un certain nombre de bonnes pratiques doivent être prises en compte. Elles s’articulent autour de 3 axes majeurs qui sont : la sécurisation côté client, la sécurisation de l’application et la sécurisation des échanges.

La sécurisation côté client comprend le contrôle d’accès, la gestion des sessions et des comptes. La sécurisation de l’application comprend la sécurisation des différents points d’entrée (WSDL, données en entrée), de l’audit, de la protection contre le rejeu, de la gestion des exceptions et des relations de confiance. La sécurisation des échanges couvre les aspects confidentialité, intégrité et disponibilité.

 

Contrôle d’accès

Le Service Web doit implémenter un mécanisme d’authentification pour contrôler la légitimité des accès :

  • HTTP Digest/Basic,
  • Rampart,
  • Kerberos,
  • Active Directory,
  • LDAP,
  • Base de données,
  • Certificats.

 

Gestion des sessions

Si le mécanisme d’authentification utilisé n’implémente pas nativement une gestion des sessions, il est nécessaire d’implémenter une gestion des sessions de manière applicative :

  •  Gestion des sessions applicative

 

Gestion des comptes

Les comptes utilisés par l’application doivent respecter le principe du moindre privilège afin d’éviter une trop grande exposition en cas de compromission de celui-ci :

  •  Respect du moindre privilège

 

Confidentialité

Les échanges SOAP, par exemple, doivent être sécurisés et les messages chiffrés :

  • Rampart,
  • WS-Security,
  • TLS,
    IPSec

 

 

Intégrité

Les parties critiques des messages SOAP doivent être signées afin d’en garantir leur exactitude :

  •  Rampart,
  • WS-Security,
  • TLS,
  • IPSec

 

Disponibilité

Les Services Web critiques en disponibilité doivent faire l’objet de mesures adaptées supportées par des composants d’infrastructure et applicatifs :

  •  Redondance de l’infrastructure,
  • WS-Reliability

 

WSDL

L’accès à la WSDL doit être sécurisé et n’être autorisé qu’aux clients identifiés :

  • Filtrage IP des clients

 

Contrôle des entrées

Le développeur ne doit accorder aucune confiance aux données en entrée des Services Web et chaque entrée doit être validée. Chaque donnée en entrée doit faire l’objet d’un contrôle afin de s’assurer qu’elle correspond au type attendu et qu’elle respecte la syntaxe attendue :

  • Valider la taille, le format, le type des données en entrée,
  • Valider la taille, la longueur et la profondeur des messages XML parsés

 

Gestion des exceptions

Les erreurs possibles du Service Web doivent être interceptées et gérées afin de ne pas fournir d’informations potentielles à un attaquant :

  • Gestion des exceptions (Try/Catch),
  • Contrôle de la sensibilité des informations remontées en cas d’erreur

 

Protection contre le rejeu

Les Services Web n’intègrent pas par défaut de mécanismes contre le rejeu. Le développeur doit intégrer des mécanismes anti rejeu sur les fonctions sensibles du Service Web.

  • Protection applicative contre le rejeu
  • Protection système contre le rejeu

 

Audit

Les actions réalisées par l’intermédiaire du Service Web doivent être auditées afin de permettre un diagnostic post-attaque ou détecter tout comportement suspect :

  •         Mécanismes d’audit implémentés de manière applicative

 

Relation de confiance

Dans le cas où le Service Web est ouvert à de nombreux acteurs, les clients et les fournisseurs de Services Web doivent instaurer une relation de confiance. Cette relation de confiance peut être instaurée selon différents mécanismes en fonction de la complexité de l’architecture et du nombre d’acteurs du Service Web :

  • Filtrage IP des clients,
  • TLS – Certificats clients/serveurs,
  • PKI - Certificats clients/serveurs,
  • Rampart - Certificats clients/serveurs,
  • WS-Security
  • Fédération
  • WS-Trust

 

 


 

Sécurité réseau

Les mesures de sécurité réseau peuvent être positionnées aux niveaux 3, 4 et 7 des couches ISO selon les protocoles IP, TCP et HTTP considérés.

 

Couche 3 (IP - IPSec)

Une partie de la sécurité des web services peut être mise en œuvre au niveau du réseau au moyen du protocole IPSec. Ce service assure notamment l’intégrité, l’authentification et le chiffrement des échanges.

Le protocole IPSec peut être une bonne réponse aux problématiques de sécurité des web services. Il peut cependant porter atteinte à l’interopérabilité native des Web Services en obligeant les clients (requêtant les web services) l’implantation des mécanismes support au protocole IPSec.

 

Couche 4 (TCP - SSL/TLS)

Transport Layer Security (TLS), anciennement nommé Secure Socket Layer (SSL), est un protocole de sécurisation des échanges sur Internet.

TLS fonctionne suivant un mode client-serveur et supporte les fonctionnalités d’authentification (serveur ou mutuelle), protection en confidentialité et intégrité des données échangées tout en assurant l’interopérabilité avec l’utilisation de protocoles connus, standards et non modifiés.

Sa facilité de mise en œuvre associée à sa reconnaissance internationale favorise l’adoption du protocole TLS dans le cadre de sécurisation de Services Web. Il assure les mécanismes d’authentification, de confidentialité et d’intégrité.

 

Couche 7 (HTTP - HTTP Auth)

L’authentification HTTP répond à la problématique d’authentification d’un client auprès d'un serveur au moyen d’un mécanisme de type login/mot de passe.

Deux méthodes définies pour l’authentification http peuvent être implémentées : la méthode Basic ou la méthode Digest. La méthode Basic est la plus simple, mais également la moins sécurisée car elle suppose que le mot de passe soit transmis en clair (ou presque). La méthode Digest ne transmet pas le mot de passe en clair, mais impose de stocker celui-ci (ou son hachage SHA1) en clair. Même si cette méthode est plus sûre que la méthode Basic, elle reste tout de même sensible aux attaques (interception de communication…), et plus sensible encore à certaines attaques (vol de fichier de mot de passes).

Ces deux méthodes ne présentent pas de garantie sécurité natives suffisantes mais peuvent être utilisées conjointement au protocole TLS pour authentifier les clients des Services Web.

 


 

Sécurité applicative

SOAP et spécifications WS

SOAP (ancien acronyme de Simple Object Access Protocol) est un protocole de RPC orienté objet bâti sur XML.

Il permet la transmission de messages entre objets distants. Il autorise un objet à invoquer des méthodes d'objets physiquement situés sur un autre serveur. Le transfert se fait le plus souvent à l'aide du protocole HTTP, mais peut également se faire par un autre protocole, comme SMTP.

SOAP a été initialement défini par Microsoft et IBM, mais est devenu une référence depuis une recommandation du W3C, utilisée notamment dans le cadre d'architectures de type SOA (Service Oriented Architecture) pour les Services Web.

Différentes spécifications (certaines en passe de devenir des standards), connues généralement sous le nom collectif WS-*, définissent des ensembles d'en-têtes SOAP perçus comme étant particulièrement importants pour un grand nombre d'applications. Divers spécifications dédiées à la sécurité ou dans des domaines connexes doivent être prises en considération dans cet état de l’art dont notamment WS-Security et WS-Policy.

 

Spécifications sécurité applicables à AXIS

Les spécifications liées à la sécurité qui sont implémentées dans AXIS sont les suivantes :

 

WS-Security

WS-Security (Web Services Security) est une spécification du protocole SOAP qui permet d'appliquer des mesures de sécurité aux Services Web. La version actuelle de WSS est la version 1.1.

Cette spécification a pour vocation de définir les moyens de protéger l’intégrité et la confidentialité des messages des Services Web. Le protocole WSS inclut des détails sur l'utilisation de SAML et Kerberos, et des formats de certificat comme X.509.

WS-Security ne fournit pas de mécanismes contre les attaques par rejeu et les attaques de type « Man in the middle »

 

WS-Security s’appuie sur les fonctionnalités natives XML de signature et de chiffrement :

XML Encryption - Cette fonction fournit les mécanismes de chiffrement pour tout ou partie d’un document XML. La granularité dans le chiffrement est rendue nécessaire par la possibilité que certains intermédiaires du Service Web ne sont pas autorisés à accéder à certains blocs du document XML.

Le périmètre du chiffrement peut s’étendre :

  • A la totalité du document,
  • A un élément XML,
  • Au contenu d’un élément XML,
  • A une partie de données d’un élément XML.

 

XML Signature -  Cette fonction fournit les mécanismes de signature permettant d’assurer l’intégrité de tout ou partie d’un document XML.

Un document XML transmis par un Service Web est amené à être modifié. Il est nécessaire de s’assurer de l’intégrité et de l’origine de chaque bloc.

Pour ce faire, XML Signature propose trois types de signatures :

  • Signature enveloppante : La signature contient les données signées comme un sous ensemble,
  • Signature enveloppée : La signature qualifie les données qui l'entourent dans le reste du document,
  • Signature détachée : La signature concerne des ressources extérieures au document qui la contient.

 

WS-Policy

WS-Policy est une norme qui définit un langage flexible et extensible qui permet d’exprimer au niveau de la couche SOAP des possibilités, exigences et caractéristiques générales dans les Services Web basés sur XML.

WS-Policy permet de définir des politiques clientes en matière de capacité sécurité ou de qualité de service et aux fournisseurs de services (providers en anglais) de spécifier leurs exigences.

Par exemple, WS-Policy permet de spécifier les possibilités et les contraintes de sécurité sur les intermédiaires et les points finaux en matière d’algorithmes de chiffrement, d’authentification des clients et fournisseurs et comment associer ces politiques en fonction des services et des points finaux.

 

Autres normes ou spécifications intéressantes

Un certain nombre de spécifications ne sont pas implémentées dans AXIS pour des raisons de maturité de la spécification ou de propriété de la spécification qui est définie par des acteurs majeurs privés comme IBM ou Microsoft. Elles demeurent néanmoins intéressantes car elles répondent à des problématiques de sécurité qui pourront se poser telles que la gestion applicative de la disponibilité, la relation de confiance entre acteurs multiples ou la fédération des identités….

 

XACML

XACML est une norme qui définit un langage pour le contrôle d'accès, la circulation des règles et l'administration de la politique de sécurité des systèmes d'information. XACML est souvent utilisée pour supporter la fonction d'autorisation dans les architectures SOA.

La norme permet de positionner les permissions avec une granularité plus fine que permission/interdiction en fonction du client, de la ressource accédée et de l’action exécutée. Son principe de  fonctionnement est comparable à celui des ACLs utilisées dans les systèmes d’exploitation ou au niveau du réseau.

 

SAML

Le protocole SAML est très lié au protocole XACML. SAML définit un langage qui permet  d’échanger des données sécurité au niveau des utilisateurs et tente de répondre à la problématique d’authentification unique. Il est utilisé pour fédérer les identités et fournir des mécanismes de SSO aux applications qui permettent de prolonger les solutions de SSO au delà de l’intranet où les solutions abondent (solution à base de cookie de session par exemple).

Le protocole suppose que le client s’est authentifié sur un fournisseur d’identité approuvé et ce quelque soit la méthode d’authentification et qui par relation de confiance propage l’identité de l’utilisateur sur tous les domaines de sécurité où la relation de confiance est effective.

 

WS-Reliability

WS-Reliability est une spécification basée sur le protocole SOAP qui définit des exigences en matière de disponibilité pour les applications critiques basées sur des Services Web. SOAP est un protocole basé sur HTTP qui par nature ne permet pas d’assurer un haut niveau de disponibilité et de fiabilité. Cette spécification a été conçue pour être utilisée dans le cadre des standards actuels relatifs aux Services Web.

 

Problématique des relations de confiance :

Dans le cas où le nombre d’acteurs est réduit, la relation de confiance peut s’établir sur le modèle « un pour un » dans lequel chaque acteur détient les certificats de tous les autres ce qui permet de  les authentifier.

Dans une infrastructure où le nombre d’acteurs est important, cette architecture et ce mode de fonctionnement n’est plus viable. Il est alors nécessaire de faire supporter la relation de confiance entre acteurs par une ou plusieurs des normes de relations suivantes.

 

WS-Trust

WS-Trust est une extension à la norme WS-Security qui tente de répondre aux problématiques de renouvellement et de validation des jetons de sécurité. Elle vise aussi à assurer la gestion, l’établissement et l’évaluation des relations de confiance entre les différents acteurs qui assurent le transit du Service Web.

Dans ce but, WS-Trust définit un certain nombre de nouveaux concepts et objets :

  • Le Security Token Service (STS) – STS est un web service qui assure la gestion des jetons de sécurité. Il est à la base de la relation de confiance inter-domaine,
  • Le format des messages utilisés pour les requêtes de jetons sécurité et les réponses à ces messages,
  • Les mécanismes d’échange de clés.

Beaucoup de Frameworks implémentent cette extension et notamment le module Apache du projet AXIS2.

 

XKMS

XKMS (XML Key Management Specification) est une spécification de gestion des clés de chiffrement XML au niveau des applications et des services. Elle est principalement supportée par Microsoft et Verisign.

Le protocole permet de reporter le processus et les moyens de gestion des clés sur une infrastructure à clés publiques (IGC ou PKI) plutôt que sur les applications.

Le protocole a pour objectifs :

  • D’offrir des fonctionnalités de validation et d’enregistrement des clés publiques aux applications et Services Web,
  • De supprimer la complexité d’interaction avec les PKI ; les PKI étant de nature hétérogènes et n’offrant pas de protocole unique de communication,
  • De déplacer la complexité de l’application cliente sur la PKI afin de rendre le Service Web plus léger.

 

WS-Federation

La norme WS-Federation décrit un certain nombre de mécanismes permettant la fédération des identités et la création d’un périmètre de confiance entre environnements hétérogènes. WS-Federation s'appuie pour sur les spécifications WS-Security, WS-Policy, WS-Trust et WS-SecureConversation pour fédérer des domaines de sécurité et définir les contextes de sécurité qui les régissent.

Le langage qui permet la description de règles de confiance assure la gestion de relations de confiance entre des environnements hétérogènes en permettant par exemple l’authentification mutuelle entre applications qui utilisent des mécanismes d’authentification différents tels que Kerberos ou X.509.

WS-Federation s’insère entre WS-Policy et WS-Trust pour définir comment les relations de confiance doivent être gérées.

 

LibertyAlliance

Le projet Liberty Alliance est un projet qui réunit de nombreux acteurs informatiques, industriels, gouvernementaux et bancaires. L’idée de ce projet est de définir un ensemble de spécifications autour de la problématique de la fédération des identités et des processus de communication entre Services Web de ces informations d’identification.

Le projet se concentrait essentiellement sur la problématique d’authentification unique fédérée et se basait sur la norme SAML. A l’heure actuelle le projet s’appuie un nombre plus large de protocoles et de normes tels que HTTP et SSL.

 

 


 

 

AXIS

Introduction

AXIS est l’implémentation par le groupe Apache du protocole SOAP définie par le W3C et qui en est actuellement à sa deuxième version. La dernière version du projet AXIS1 a été publiée à la date du 22 avril 2006. Par la suite le projet AXIS2  a été lancé en Août 2004  par la fondation Apache qui a complètement repensée et réécrit le Framework.

AXIS2 oriente l’architecture vers un modèle tout XML qui s’avère plus flexible, efficace et configurable en comparaison à AXIS1. Cependant certains concepts ont été conservés dans la nouvelle architecture AXIS2 tels que les « handlers ».

Au niveau des ajouts, AXIS2 supporte maintenant SOAP 1.1 et SOAP 2 ainsi que la méthode REST pour la construction des Services Web. AXIS2 permet également l’ajout de fonctionnalités basées sur les spécifications WS-* à travers des modules qui viennent se greffer à la couche SOAP à travers des headers spécifiques. L’ajout de modules est permis par la modularité XML.

Afin de sécuriser les Services Web, AXIS2 implémente un certain nombre des spécifications WS-* au moyen du module spécialisé « Rampart ».

 

Rampart

Le module Rampart a été lancé conjointement au lancement du projet AXIS2. La version testée par nos équipes est la version 1.4 qui  implémente les fonctionnalités décrites dans les spécifications WS-Security, WS-Trust, WS-Secure Conversation et WS-Security Policy.

 

Spécification

Composant

WS-Federation

Non Implémentée

WS-Secure Conversation

rampart-core

WS-Trust

rampart-trust

WS-Security

rampart-core

WS-Security Policy

rampart-policy

 

 

Fonctionnement

Le module Rampart vient s’insérer dans la phase sécurité du protocole SOAP juste après la phase transport.

         En entrée : Le « Rampart Reciever » intercepte le message en entrée afin de valider si le message est conforme vis-à-vis de la politique de sécurité spécifiée. Toutes les actions de sécurité telles que le déchiffrement, la validation d’une signature ou de l’horodatage et l’authentification de l’utilisateur se déroulent pendant cette phase.

        En sortie : Le « Rampart Sender » est le dernier intercepteur avant l’envoi du message. Celui-ci est intercepté et le module Rampart applique toutes les actions de sécurité spécifiées par la politique de sécurité telles que le chiffrement ou la signature du message ou l’inclusion d’un jeton de sécurité.

 Pour ce faire, le module Rampart utilise un fichier XML aussi bien du côté serveur que du côté client qui définit les spécifications et les exigences en matière de sécurité. Du côté serveur, le fichier XML se nomme services.xml et vient s’insérer dans le répertoire META-INF du Service Web.

 

Rampart Trust

Rampart Trust est l’implémentation de la spécification WS-Trust qui peut être utilisée conjointement aux modules Rampart Core et Rampart Policy. Rampart Trust définit un Framework qui peut être utilisé pour valider, renouveler ou annuler des jetons de sécurité. Il fournit donc les fonctionnalités nécessaires à un STS (Security Token Service) qui est littéralement un Service Web dédié à la gestion des tokens de sécurité.

 

Rampart Policy

WS-Security Policy est une extension de la spécification WS-Policy qui est implémentée dans Rampart via la bibliothèque Neethi qui est l’implémentation de la spécification WS-Policy.

WS-Security Policy définit un langage qui permet au travers de « Policy Assertion » (bloc XML standardisé) de spécifier des exigences, des contraintes ou des propriétés.

 
La combinaison de ces « Policy Assertion » permet de définir une politique de sécurité globale flexible permettant de faire varier les exigences en matière de sécurité sans avoir à modifier le Service Web en lui-même.

Les types d’assertions

  • Sécurité de la connexion,
  • Protection des données,
  • Méthodes d’authentification,
  • Spécifications des jetons de sécurité,
  • Protocoles.

 

Spécifications - Sécurité de la connexion

Les assertions de type « Security binding » définissent les mécanismes utilisés pour sécuriser les messages échangés. Ils définissent entre autres les clés et les algorithmes utilisés. Les propriétés communes à d’autres types d’assertions sont aussi définies dans les assertions de type « Security binding » et sont injectées dans les autres assertions lorsque cela est nécessaire.

 

Sécurisation de la connexion avec TLS - L’assertion de type « Transport binding assertion » est utilisée dans le cas ou la sécurisation de la connexion s’effectue au niveau de la couche transport à travers le protocole TLS.

Sécurisation de la connexion par chiffrement asymétrique - L’assertion de type « Asymmetric binding assertion » est utilisée dans le cas ou le client et le service possèdent des jetons de sécurité. Si les deux parties possèdent, par exemple, des certificats de type X509, une assertion de type « Asymmetric binding assertion » est utilisée pour spécifier (côté client) que le client doit utiliser sa clé privée pour la signature et la clé publique du Service Web pour le chiffrement des messages. Côté serveur le Service Web utilise sa clé privée pour le déchiffrement et la clé publique du client pour vérifier la signature.

Les assertions de type « Asymmetric binding assertion » permettent de définir les jetons de sécurité utilisés par le client et le Service Web en utilisant les propriétés « Initiator Token » et « Recipient Token »

Sécurisation de la connexion par chiffrement symétrique - L’assertion de type « Symmetric binding assertion » est utilisée seulement dans le cas où une  seule des parties doit générer des jetons de sécurité. Une clé symétrique est générée pour créer le jeton de sécurité. Cette même clé est utilisée plus tard dans le processus pour la signature et le chiffrement/déchiffrement des messages échangés.

Par exemple, ce type d’assertions est utilisé dans le cas où le serveur possède un jeton X509. Dans un premier temps le client crée une clé éphémère. Cette clé est chiffrée avec la clé publique du serveur. Cette clé éphémère est ensuite utilisée pour chiffrer et signer les messages. Ce mécanisme permet au même titre que le protocole TLS (mais au niveau du Service Web) de chiffrer et signer des messages avec des clients anonymes. Dans le cas où il est nécessaire d’authentifier le client, il est possible de faire porter cette fonction par l’application en définissant des jetons de signature, de chiffrement ou de protection (chiffrement et signature).

 

 Propriétés transverses

Certaines valeurs définies dans les assertions de type « Security binding » sont définies par défaut  et peuvent être utilisées dans les autres assertions.

 

Propriété

Description

Valeur par défaut

Algorithm Suite

Définit les algorithmes utilisés en fonction des opérations cryptographiques et la taille minimum et maximum des clés utilisées

-

Timestamp

Définit si le timestamp doit être incorporé dans le header

false

Protection order

Définit l’ordre de signature et de chiffrement quand des contenus ont besoin d’être signés et chiffrés. Si la propriété est définie à « sign before encrypt » la signature doit être calculée à partir du texte en clair tandis que dans le cas « encrypt before sign » la signature est calculée à partir du chiffré.

Signature puis chiffrement

Signature protection

Définit si la signature et la confirmation de la signature doivent être chiffrées. Si la propriété est à vrai la signature du message et la confirmation doivent être chiffrées

false

Token protection

Définir si la signature doit inclure le jeton de sécurité qui est utilisé comme clé pour générer la signature. Dans le scénario où des clés secondaires sont générées à partir du jeton de sécurité seul le jeton de sécurité doit être signé.

false

Entrire Header and Body Signature

Définit si le hash de la signature couvre seulement les éléments de la partie body et de la partie headers des messages SOAP.

false

Security Header Layout

Définit l’ordonnancement du header de sécurité. Quatre valeur peuvent être définies et qui sont Lax, Strict, LaxTimestampFirst , LaxTimestampLast.

Lax

 

Spécifications - Jeton de sécurité

Les assertions de type « Token Assertions » spécifient les types de jetons de sécurité utilisés pour protéger les messages. Ces assertions définissent deux propriétés importantes pour la protection des messages :

  • Propriétés des clés dérivées (« Derived Keys property ») – Cette propriété est utilisée pour définir si les clés dérivées ou secondaires sont utilisées. Si la propriété est à vrai, des jetons secondaires dérivés du jeton principal sont utilisées pour chiffrer et signer les messages. Cependant ces clés doivent être générées comme il est défini dans la spécification WS-Secure Conversation.
  • Propriétés d’inclusion des jetons (« Token Inclusion property ») -  Cette propriété permet de positionner les paramètres d’inclusion des jetons au sein d’une communication. Quatre valeurs sont autorisées :

 

Valeur

Description

/IncludeToken/Never

Les jetons de sécurité ne doivent pas être inclus dans les messages. Ils doivent être référencés en utilisant un mécanisme de référencement en accord avec la politique.

/IncludeToken/Once

Les jetons de sécurité doivent être envoyés une seule fois par le client au Service Web. Les messages suivants n’ont pas besoin d’inclure le jeton de sécurité.

/IncludeToken/AlwaysToRecipient

Tous les messages envoyés par le client au Service Web doivent inclure le jeton de sécurité. Les messages du Service Web n’ont pas besoin d’inclure le jeton de sécurité du Service Web.

/IncludeToken/Always

Tous les messages doivent inclure les jetons de sécurité qu’ils proviennent du client ou du Service Web. Des mécanismes de référencement peuvent être utilisés.

 

Quelques types de jetons de sécurité définis dans la spécification WS-Security Policy :
Username Tokens

  • X509 Tokens
  • Issued Tokens
  • Secure Conversation Tokens
  • SAML Tokens
  • Https Tokens

 

Spécifications - Signature

Les quatre assertions de type « Supporting Token » définissent des spécifications supplémentaires pour les clients. Ces assertions permettent d’inclure plusieurs jetons de sécurité dans un même message :

  • Supporting Tokens : Jetons de sécurité ajoutés dans le header de sécurité,
  • Signed Supporting Tokens : Jetons de sécurité ajoutés dans le header et signés par la signature du message,
  • Endorsing Supporting tokens : Jetons de sécurité qui signent la signature du message,
  • Signed Endorsing supporting tokens : Jetons de sécurité qui signent la signature du message et qui sont inclus dans la signature du message.

 

Spécifications – Protection

Ces assertions permettent de définir quelles sont les parties du message qui sont protégées et de quelle manière. Ces protections s’appliquent principalement sur les critères d’Intégrité et de Confidentialité. Les assertions d’intégrité spécifient quelles parties sont signées et celles liées à la confidentialité les parties chiffrées.

 

Valeur

Description

Signed Parts Assertion

Définit si le corps du message (« body ») doit être signé et quels sont les headers SOAP qui doivent être signés également.

Signed Elements Assertion

Définit les éléments qui doivent être signés en utilisant XPath.

Encrypted Parts Assertion

Définit si le « body » doit être chiffré et quels sont les headers SOAP qui doivent être chiffrés aussi.

Encrypted Elements Assertion

Définit les éléments qui doivent être chiffrés en utilisant XPath

Required Elements Assertion

Définit les éléments qui doivent être présents obligatoirement dans le message

 

Spécifications – Protocoles

 

La spécification WS-Security définit trois types d’assertions au  WSS10, WSS11 et Trust10 relatives à la sécurité et à la confiance globale des messages SOAP. Ces assertions permettent de définir les exigences qu’un client et un destinataire doivent respecter.

  •  Wss10 assertion

Valeur

Description

Direct References

Définit si le destinataire et le client doivent être capables de gérer les références directes

Key Identifier References

Définit si le destinataire et le client doivent être capables de gérer les références aux « key identifier »

Issuer Serial References

Définit si le destinataire et le client doivent être capables de gérer les références aux « issuer serials »

External URI References

Définit si le destinataire et le client doivent être capables de gérer les références aux URI externes

Embedded Token References

Définit si le destinataire et le client doivent être capables de gérer les références embarquées dans les jetons de sécurité

 

  • Wss11 assertion

Valeur

Description

Thumbprint References

Définit si le destinataire et le client doivent être capables de gérer  les « thumbprint references »

EncryptedKey References

Définit si le destinataire et le client doivent être capables de gérer  les références aux clés chiffrées (« encrypted key »)

Signature Confirmation

Définit si la signature de confirmation doit être envoyée conformément aux spécifications définies dans les spécifications SOAP Message Security 1.1.

Direct References

Définit si le destinataire et le client doivent être capables de gérer les références directes

Key Identifier References

Définit si le destinataire et le client doivent être capables de gérer les références aux « key identifier »

Issuer Serial References

Définit si le destinataire et le client doivent être capables de gérer les références aux « issuer serials »

External URI References

Définit si le destinataire et le client doivent être capables de gérer les références aux URI externes

Embedded Token References

Définit si le destinataire et le client doivent être capables de gérer les références embarquées dans les jetons de sécurité

 

  • Trust10 assertion

Valeur

Description

MustSupportClientChallenge

Définit si le mode « challenge client » doit être supporté. Il est défini par l’élément wst:SignChallenge  dans les requêtes de type « Request Security Token » dans les scénarios de relation de confiance.

MustSupportServerChallenge

Définit si le mode « challenge serveur » doit être supporté. Il est défini par l’élément wst:SignChallenge  dans les requêtes de type « Response Security Token »

RequireClientEntropy

Définit si l’entropie du client nécessite une clé matérielle

RequireServerEntropy

Définit si l’entropie du serveur nécessite une clé matérielle

MustSupportIssuedTokens

Définit si le header wst:IssuedTokens header est géré dans le header SOAP

 

Construire une politique de sécurité

La spécification WS-Policy définit deux opérateurs qui peuvent être utilisés pour construire une politique de sécurité. « wsp » est utilisé comme préfixe pour l’environnement défini dans la spécification WS-Policy.

  • wsp:All operator
  • wsp:ExactlyOne operator

Ces opérateurs peuvent être utilisés pour construire des politiques de sécurité alternatives qui sont basées sur les différentes assertions évoquées préalablement.

Policy Subjects

Les « Policy Subjects » sont les différents points d’entrée pour les politiques de sécurité. Les différents niveaux sont :

  • Message Policy Subject
  • Operation Policy Subject
  • Endpoint Policy Subject

 Les politiques de sécurité peuvent être liées à ces trois niveaux et définir un certain nombre d’assertions en fonction du niveau auxquelles les politiques sont rattachées.

  •  Niveaux et définitions d’assertions suggérées

Policy Subject

Points d’entrée  dans la WSDL 

Assertions suggérées

End point policy subject

wsdl:binding

wsdl:port

Security binding

Supporting token

Protocol

Operation policy subject

wsdl:binding/wsdl:operation

Supporting Token

Message

wsdl:binding/wsdl:operation/wsdl:input

wsdl:binding/wsdl:operation/wsdl:output

wsdl:binding/wsdl:operation/wsdl:fault

Supporting Token

Protection

 

 


            

                

                    

                        

                            

                                

                                    

 


 

Tableau de synthèse

 

Critères

Mesures

Contrôle d’accès

  •  
    • HTTP Digest/Basic
    • Rampart – WS Security
      • Kerberos
      • Active Directory
      • LDAP
      • Base de données
      • Certificats

Gestion des sessions

  •  
    • Gestion des sessions applicatives

Confidentialité

  •  
    • Rampart
      • WS-Security
      • TLS
      • IPSec

Intégrité

  •  
    • Rampart
      • WS-Security
      • TLS
      • IPSec

Disponibilité

  •  
    • Redondance de l’infrastructure
    • WS-Reliability

WSDL

  •  
    • Filtrage IP des clients

Validation des entrées

  •  
    • Valider la taille, le format, le type des données en entrée
    • Valider la taille, la longueur et la profondeur des messages XML parsés

Relation de confiance

  •  
    • Filtrage IP des clients
    • TLS – Certificats clients/serveurs
    • PKI - Certificats clients/serveurs
    • Rampart - Certificats clients/serveurs
      • WS-Security
      • Fédération
        • WS-Trust

Gestion des exceptions

  •  
    • Gestion des exceptions (Try/Catch)
    • Contrôle de la sensibilité des informations remontées en cas d’erreur

Gestion des comptes applicatifs

  •  
    • Respect du moindre privilège

Protection contre le rejeu

  •  
    • Protection applicative contre le rejeu
    • Protection système contre le rejeu

Audit

  •  
    • Mécanismes d’audit implémentés de manière applicative
    GDI, rédigé le 7/02/2011