Cours 8 : Les Web Services Sécurisation Mars 2011 - Version 1.0 - Les technologies XML Cours 8 : Les Web Services Sécurisation Mars 2011 - Version 1.0 -

Sécurisation - Introduction Un Web Service est exposé sur le net qui est, par essence, un endroit non sécurisé. Il est donc nécessaire de : Sécuriser le transport Authentifier un expéditeur Chiffrer les données Gérer des droits sur les services distants

Sécurisation – WS-Security WS-Security : Ensemble de protocoles pour sécuriser les services Web Englobe les standards : XKMS (XML Key Management Specification) spécification conjointe du W3C et de l'IETF pour intégrer la gestion de clés et certificats aux applications XML. délégation du traitement de la sécurité à un service spécialisé sur Internet offrant des services de gestion de clés publiques, certificats et signatures, accessible en SOAP. XML Signature (Signature de message en XML) XML Encryption (Protocole d'échange de clés de cryptage)

Sécurisation – WS-Security Originellement développé par IBM, Microsoft, VeriSign et Forum Systems, le protocole est maintenant officiellement appelé WSS et développé via un comité dans Oasis-Open. Le protocole contient des spécifications sur la façon dont l'intégrité et la confidentialité peuvent être appliquées aux messages de services web. Le protocole WSS inclut des détails sur l'utilisation de SAML et Kerberos, et des formats de certificat comme X.509. OASIS WSS : http://www.oasis-open.org/specs/index.php#wssv1.1

Sécurisation – WS-Security WSS a été conçue pour sécuriser les échanges mis en oeuvre sous forme de Web Services entre deux applications distantes. WSS s’occupe de l’ensemble des composantes de la sécurisation : de l'authentification des utilisateurs et des composants en présence en passant par le chiffrement, et la gestion de l'intégrité des messages par le biais de certificats

Sécurisation - Standards XML Signature XML Encryption XKMS - XML Key Management System SAML - Security Assertions Markup Language XACML - XML Access Control Markup Language

XML Signature Objectif Fonctionnalités Prévenir la falsification d’un document XML. Gérer la non répudation des documents (identité de l’émetteur du document). Fonctionnalités Basé sur XML ( pas de notation ASN.1) Signatures sur des portions (arbres d’ éléments) de documents Le document peut être recomposé/transformé par le récepteur Signatures sur plusieurs entités 1 document HTML + feuille CSS + image de bannière + … Signatures par plusieurs signataires sur tout ou partie du document Signatures embarqués dans le document (signature dite enveloppante) SOAP request/response Signature d’ entités externes référencées par des URI (signature détaché) HTML, éléments Media, CSS …

Canonisation http://www.w3.org/TR/xml-c14n XML Signature Traitement L’ émetteur crée un message, le canonise et le signe Le récepteur reçoit un message, le canonise et vérifie sa signature Canonisation Indépendance de l’ indentation, de l’encodage (esp. Cr, ..) sur le calcul de la signature W3C et IETF XML Digital Signature http://www.w3.org/TR/xmldsig-core/ Canonisation http://www.w3.org/TR/xml-c14n API Java : JSR 105 XML Digital Signature APIs (javax.security.xml.dsig)

Il existe 3 type de signatures : XML Signature Il existe 3 type de signatures : la signature 'enveloppée' (enveloped signature) : lorsque la signature s'applique aux données qui l'entoure dans le reste du document ; la signature 'enveloppante' (enveloping signature) : lorsque les données signées forment un sous élément de la signature elle-même ; la signature 'détachée' (detached signature) : lorsque la signature concerne des ressources extérieures au document qui la contient ;

XML Signature – Construction message Objet Sha Infos signées Digest Uri Signature Infos Signées Clef Objets Sha Dsa Clef privée Clef de l’émetteur certificat

XML Signature – Exemple de signature détachée [s01] <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"> [s02] <SignedInfo> [s03] <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> [s04] <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> [s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> [s06] <Transforms> [s07] <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> [s08] </Transforms> [s09] <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> [s10] <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> [s11] </Reference> [s12] </SignedInfo> [s13] <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> [s14] <KeyInfo> [s15a] <KeyValue> [s15b] <DSAKeyValue> [s15c] <P>...</P><Q>...</Q><G>...</G><Y>...</Y> [s15d] </DSAKeyValue> [s15e] </KeyValue> [s16] </KeyInfo> [s17] </Signature> 1 : la page qui a été signé 2 : l’algorithme utilisé pour le hash de la ressource ainsi que celui-ci 3 : la signature de l’élément SignedInfo

XML Signature – les transformations Pourquoi ? Elles permettent de ne signer que certaines parties du document Transformations possibles Canonisation, Encodage/Décodage (Compression/Décompression), XSLT, Xpath, Validation XML Schema, Xinclude, ..

XML Signature – Les éléments optionnels Élément <Object> Attention : il est optionnel et le récepteur peut ne pas le comprendre Les sous éléments doivent être identifiés Sous Élément <SignatureProperties> Permet d’ ajouter des informations complémentaires à la signature Date de validité de la signature, identité du processus signataire, … Sous Élément <Manifest> Permet de signer indépendamment chaque URI listé dans le manifeste

XML Signature – Les éléments optionnels exemple [ ] <Signature Id="MySecondSignature" ...> [p01] <SignedInfo> [ ] ... [p02] <Reference URI="http://www.w3.org/TR/xml-stylesheet/"> [p03] <Reference URI="#AMadeUpTimeStamp«  [p04] Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties"> [p05] <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> [p06] <DigestValue>k3453rvEPO0vKtMup4NbeVu8nk=</DigestValue> [p07] </Reference> [p08] </SignedInfo> [p09] ... [p10] <Object> [p11] <SignatureProperties> [p12] <SignatureProperty Id="AMadeUpTimeStamp" Target="#MySecondSignature"> [p13] <timestamp xmlns="http://www.ietf.org/rfcXXXX.txt"> [p14] <date>19990908</date> [p15] <time>14:34:34:34</time> [p16] </timestamp> [p17] </SignatureProperty> [p18] </SignatureProperties> [p19] </Object> [p20]</Signature> [p04] L'attribut optionnel Type de l'élément Reference fournit des informations à propos de la ressource identifiée par l'URI. En particulier, il peut indiquer si c'est un élément Object, SignatureProperty ou Manifest. Ceci peut être utilisé par des applications pour lancer un traitement spécial sur certains éléments Reference. Les références vers un élément de données XML, dans un élément Object, DEVRAIENT identifier le véritable élément désigné. Lorsque le contenu d'un élément n'est pas du type XML (il peut s'agir de données codées ou binaires), la référence devrait identifier l'élément Object et l'attribut Type de l'élément Reference, s'il est donné, DEVRAIT désigner l'élément Object. À noter que l'attribut Type est utilisé à titre consultatif, le corps du fonctionnement ne demande aucune action qui s'appuie sur celui-ci ni de vérification de son exactitude. [p10] L'élément Object est un élément optionnel qui permet d'inclure des objets de données dans un élément de signature ou ailleurs. L'élément Object peut être facultativement typé et/ou codé. [p11-18] Les propriétés de la signature, telle que la date de la signature, peuvent être facultativement signées en les identifiant à partir d'un élément Reference. (Ces propriétés sont traditionnellement appelées des « attributs » de signature, bien que ce terme n'ait aucune relation avec le terme « attributs » en XML.)

XML Signature – Les éléments optionnels KeyInfo Permet au récepteur d’obtenir la clé nécessaire à valider la signature KeyName (un nom, un index dans un répertoire de clé, un X500 DN, …) RetrievalMethod Certificats : X509, PGP, SPKI Clés publiques : RSA, DSA

XML Signature – traitements génération La génération d'une référence Pour chaque objet de données en cours de signature : Appliquer l'élément Transforms comme déterminé par l'application (programme), sur l'objet de données ; Calculer la valeur prétraitée sur l'objet de données résultant. Créer un élément Reference, incluant l'identification (optionnelle) de l'objet de données, tout élément (optionnel) de transformation, l'algorithme de prétraitement et l'élément DigestValue. (À noter que ce sont les formes canoniques de ces références qui sont signées pour la génération des signatures et validées pour leurs validations)

XML Signature – traitements génération La génération de la signature Créer l'élément SignedInfo avec les éléments SignatureMethod, CanonicalizationMethod et Reference ; Canoniser puis calculer l'élément SignatureValue sur l'élément SignedInfo, en fonction des algorithmes spécifiés dans SignedInfo ; Construire l'élément Signature qui inclut les éléments SignedInfo, le ou les Object (si on le désire, le codage peut être différent de celui utilisé pour la signature), KeyInfo (si requis) SignatureValue. À noter que si l'élément Signature inclut des références provenant d'un même document, la validation [XML] ou [XML-schema] du document peut introduire des changements qui faussent la signature. Par conséquent, les applications devraient faire attention de traiter le document de manière cohérente ou d'éviter l'utilisation de contributions externes (par exemple, les défauts et les entités).

XML Signature – traitements validation La validation de référence Canoniser l'élément SignedInfo en fonction de l'élément CanonicalizationMethod dans SignedInfo ; Pour chaque élément Reference dans SignedInfo : Obtenir les données à prétraiter. (Par exemple, l'application de signature peut résoudre l'URI et exécuter l'élément Transforms fourni par le signataire dans l'élément Reference, ou elle peut obtenir le contenu par d'autres moyens tel que dans un cache local.) ; Prétraiter l' objet de données resultant en utilisant l'élément DigestMethod spécifié dans son élément Reference ; Comparer la valeur condensée générée avec la valeur de DigestValue dans l'élément Reference de SignedInfo ; s'il y a une quelconque divergence, la validation échoue. À noter que l'élément SignedInfo est canonisé lors de la génération des référence. L'application (programme) doit s'assurer que l'élément CanonicalizationMethod n'a pas d'effets secondaires indésirables, tels que la réécriture des URI, et qu'elle voit ce qui est signé, ce qui est la forme canonique.

XML Signature – traitements La validation de signature Obtenir les informations de la clé à partir de l'élément KeyInfo ou d'une source externe ; Obtenir la forme canonique de l'élément SignatureMethod en utilisant l'élément CanonicalizationMethod, puis utiliser le résultat (et les informations de clé de l'élément KeyInfo précédemment obtenues) pour confirmer la valeur de l'élément SignatureValue sur l'élément SignedInfo. À noter que l'élément KeyInfo (ou une certaine version transformée de celui-ci) peut être signé via un élément Reference. La transformation et la validation de cette référence est orthogonale par rapport à la validation de l'élément Signature qui utilise l'élément KeyInfo lors de l'analyse. De plus, l'attribut URI de l'élément SignatureMethod peut avoir été altéré par la canonisation de SignedInfo (par exemple, la transformation d'un URI relatif en URI absolu) et c'est la forme canonique qui DOIT être utilisée. Cependant, la canonisation requise [XML-C14N] de cette spécification ne change pas les URI.

XML Encryption Pourquoi ? Différents destinataires doivent pouvoir lire différentes parties du document (exemple d’un document regroupant toutes les notes des étudiants) La sécurité doit être maintenue de bout en bout W3C XML Digital Encryption http://www.w3.org/TR/xmlenc-core/ API Java JSR 106 XML Digital Encryption APIs

XML Encryption - Exemple <?xml version=“1”?> <notes> <etudiant id=“1”> <nom>Dupont</nom> <note> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Content'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </note> </etudiant> <etudiant id=“2”> <nom>Durand</nom> <CipherValue>A23B45C23</CipherValue> </notes>

L’élément EncryptedData est constitué de plusieurs sous éléments. XML Encryption Le résultat du chiffrement des données est un élément XML Encryption EncryptedData qui contient (via le contenu de l’un de ses enfants) ou identifie (via une référence d’URI) les données chiffrées L’élément EncryptedData est constitué de plusieurs sous éléments. Lors du cryptage d’un élément ou du contenu d’un élément XML, l’élément EncryptedData remplace l’élément ou le contenu (respectivement) dans la version cryptée du document XML Lors du cryptage de données arbitraires (y compris des documents XML entiers), l’élément EncryptedData peut devenir la racine d’un nouveau document XML ou devenir un élément enfant dans un document XML choisi par l’application. L’élément <EncryptedData> est constitué de plusieurs sous-éléments contenant des informations sur les données cryptées, notamment sur les clés et le code de chiffrement réel (ou la référence à ce code).

Il est possible de chiffrer tout ou partie d’un document : XML Encryption Il est possible de chiffrer tout ou partie d’un document : On peut chiffrer l’ensemble d’un document Un élément complet ce qui permet de masquer le type d’un élément La valeur d’un élément XML Encryption utilise la cryptographie à clé publique afin d’assurer la confidentialité lors des transferts Un document XML peut contenir zéro ou plus éléments EncryptedData. L’élément EncryptedData ne peut être le parent ou l’enfant d’un autre élément EncryptedData. Cependant, les données cryptées en question peuvent être n’importe quoi, y compris des éléments EncryptedData ou EncryptedKey (surcryptage) La cryptographie à clé publique a été inventée pour éviter l’échange de clé secrète préalable à toute transaction sécurisée. C’est une méthode de chiffrement qui repose sur deux clés : la clé publique et la clé privée. Chaque interlocuteur possède un couple de clés composé d’une clé privée qu’il doit garder secrète, et d’une clé publique qu’il diffuse à tout le monde. Ces deux clés sont complémentaires : en effet, il n’existe qu’une clé publique correspondant à une clé privée donnée et vice versa. Un document crypté avec la clé publique ne peut être relu qu’à l’aide de la clé privée et vice versa. Ce principe d’unicité permet de s’assurer que seul son destinataire pourra déchiffrer le message qu’on lui envoie. Pour échanger un document crypté, le principe est le suivant. On utilise la clé publique (connue de tous) du destinataire, qui sera le seul à pouvoir décrypter à l’aide de sa clé privée (connue de lui seul). Le gros avantage de la cryptographie à clé publique est que les clés publiques sont mises à la disposition de tous dans un annuaire interrogeable sur internet.

XML Encryption EncryptedType : Type abstrait à partir duquel les éléments EncryptedData et EncryptedKey sont dérivés L’élément EncryptionMethod est optionnel L’élément ds:KeyInfo est optionnel L’élément CipherData est obligatoire L’élément EncryptionProperties L’attribut Id est optionnel L’attribut Type est optionnel L’attribut MimeType est optionnel Important de faire la distinction syntaxique entre EncryptedData et EncryptedKey pour le traitement EncryptionMethod décrit l’algorithme de cryptage appliqué aux données chiffrées. Si l’élément est absent, l’algorithme de cryptage doit être connu du destinataire, sinon le décryptage échouera. L’élément KeyInfo transporte des informations concernant la clé utilisée pour crypter les données. L’élément cipherdata contient des éléments CipherValue ou CipherReference avec les données cryptées L’élément EncryptionProperties peut contenir des informations supplémentaires concernant la génération de l’élément EncryptedType L’attribut ID est optionnel : c’est la méthode standard pour assigner une chaîne id à l’élément dans le contexte du document L’attribut Type identifie une information de type au sujet de la forme en texte clair du contenu crypté L’attribut MimeType décrit le type de média des données qui ont été cryptées

Pour déchiffrer les données il existe plusieurs méthodes : XML Encryption Pour déchiffrer les données il existe plusieurs méthodes : Les éléments EncryptedData ou EncryptedKey spécifient le matériel de gestion des clés via un enfant de l’élément ds:KeyInfo Un élément EncryptedKey détaché est utilisé Le destinataire peut déterminer le matériel de gestion des clés selon le contexte de l’application et il n’est donc pas nécessaire de le mentionner explicitement Soit par ds:KeyValue, soit par Ds:KeyName (pour se référer à l’élément CarriedKeyName d’un élément EncryptedKey) soit par Ds:RetrievalMethod 2. peut spécifierl’élément EncryptedData ou EncryptedKey sur lequel s’appliquera sa clé décryptée via un élément DataReference ou KeyReference

Définit les messages de requête et de réponse pour XKMS XKMS (XML Key Management Specification) a pour but de normaliser un protocole PKI pour les échanges XML. Définit les messages de requête et de réponse pour Requérir (request) un certificat Renouveler (renew) un certificat Valider (validate) un certificat (expiration, CRL, OCSP, etc.) Révoquer (revoke) un certificat (CRL)

Basé sur XML Signature & XML Encryption W3C XKMS Basé sur XML Signature & XML Encryption W3C XKMS XML Key Management Specification Pour la v1 http://www.w3.org/TR/xkms/ Pour la v2 http://www.w3.org/TR/xkms2/ API Java JSR 104 XML Trust Service APIs

La spécification XKMS est composée de deux protocoles : X-KISS (XML Key Information Service Specification) pour les requêtes de localisation et de validation des clés publiques ; X-KRSS (XML Key Registration Service Specification) pour enregistrer, renouveler, révoquer et obtenir des clés.

XKMS - XKISS La spécification XKISS définit les deux opérations suivantes : Locate : localise le service pour obtenir des informations sur la clé publique correspondant à l'élément <ds:KeyInfo>. Cette opération n'est pas obligée de se prononcer sur la validité des données liées à la clé ; elle peut permettre de relayer la requête vers d'autres services ou se comporter comme passerelle vers une PKI. Validate : non seulement elle recherche la clé publique correspondant à l'élément <ds:KeyInfo>, mais elle assure également que les informations liées à la clé retournées sont dignes de confiance.

XKMS - XKRSS La spécification du service XKRSS définit quatre opérations : Register : attache des informations à une clé avec un key binding. Soit le client donne sa clé publique accompagnée d'une preuve de la possession de la clé privée associée, soit le service génère la paire de clés pour le client. Le service peut demander davantage d'informations au client avant d'enregistrer la clé publique (et éventuellement la clé privée). Reissue : un key binding enregistré est régénéré. De nouveaux credentials sont générés dans la PKI sous-jacente. Même s'il n'y a pas de durée de vie pour un key binding XKMS, les credentials générés par la PKI peuvent en avoir et doivent donc être régénérés périodiquement. Revoke : cette opération permet à un client de détruire les objets de données attachés à une clé. Par exemple, un certificat X.509 attaché à une clé d'un service XKMS est détruit quand cette opération est appelée ; Recover : cette opération permet à un client de recouvrer sa clé privée. Afin que cette opération soit possible, il faut que la clé privée ait été enregistrée par le service. L'une des façons pour le service d'obtenir cette clé est quand le service génère une paire de clés.

SAML SAML (Security assertion markup language) est un standard définissant un protocole pour échanger des informations liées à la sécurité. Basé sur le langage XML, SAML a été développé par OASIS. Ressources : http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security http://saml.xml.org/

SAML Un SAML token (une identité portable) permet le transport des attributs de sécurité d’une entité entre différents domaines Précède les services Web mais a été appliqué à ceux-ci et introduit dans WS-Security Dans un contexte de commerce électronique, chaque entité conserve son mécanisme d’authentification et SAML permet la confiance inter-domaine. Chaque organisation fait ou non le choix de faire confiance aux membres d’une autre organisation basé sur les assertions SAML

SAML définit trois types d’assertion Authentification (mot de passe, Kerberos, X.509, etc.) Autorisation (peut accéder une ressource donnée de la manière spécifiée) Attribut d’entité (donne de l’information sur une assertion d’authentification ou d’autorisation) SAML un protocole de requêtes/réponses pour échanger et générer les assertions

SAML SAML a pour but de permettre l'authentification unique (en anglais single sign-on ou SSO) sur le web. Les solutions de SSO au niveau d'un intranet abondent (en utilisant des cookies, par exemple) mais prolonger ces solutions au delà d'un intranet est problématique et a entraîné la prolifération de technologies différents n’interopérant pas. SAML est un standard supporté par un grand nombre de solutions de SSO pour les problèmes de gestion d'identité. SAML suppose que le principal (souvent un utilisateur) s'est inscrit auprès d’au moins un fournisseur d'identité. Ce fournisseur d'identité est censé fournir des services d'authentification locaux au principal.

SAML – Assertion Exemple

XACML XACML (Extensible Access Control MarkupLanguage) est un langage permettant, en conjonction avec SAML, de fournir un moyen de standardiser les décisions de contrôle d'accès pour les documents XML. Ce langage rend interopérables les systèmes d'authentification et d'autorisation. Formalisme XML pour exprimer des demandes et des réponses de décision d’accès à une ressource protégée Formalisme XML pour exprimer des politiques(règles) d’autorisation d’accès OASIS http://www.oasis-open.org/committees/xacml/repository/cs-xacml-specification-1.1.pdf

XACML

XACML Réception d’une requête qui aboutit à un PEP Le PEP formule en XACML la requête que l’agent adresse à la ressource ("Je, soussigné agent XYZ, désire lire la ressource ABC.") Le PEP envoie cette requête XACML à un “PDP” (Policy Decision Point). Le PDP compare la requête XACML avec les règles d’autorisation qui ont été définies pour s’appliquer aux requêtes de ce type, sur cette ressource ABC. Le PDP formule sa décision d’autorisation ("Je consens à ce que l’on réponde à cette requête” ou “je refuse") également en XACML Le PDP envoie sa réponse au PEP qui agit en conséquence (donne accès à la ressource ou renvoie un message d’erreur).

Proposition d’implantation de la norme par SUN : XACML Proposition d’implantation de la norme par SUN : Classes Java JDK > 1.4.0 Permet de décrire une politique d’accès Guide pour implémenter les autres fonctionnalités et notamment l’utilisation de LDAP et de SAML

XACML - Exemple

Conclusion Dans un monde « ouvert » il convient de bien évaluer le niveau de sécurisation souhaité afin de définir les solutions à mettre en œuvre. L’utilisation des solutions de sécurisation présentées ici peut s’avérer compliquée et coûteuse en terme de performance.