Les technologies XML Cours 13 Les Web Services

Les technologies XML Cours 13 : Les Web Services Sécurisation Mars 2016 - Version 1. 0 - 1

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 2

Sécurisation – WS-Security : Ensemble de protocoles pour sécuriser les services Web Englobe les standards : XKMS (XML Key Management Specification) q spécification conjointe du W 3 C et de l'IETF pour intégrer la gestion de clés et certificats aux applications XML. q 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) 3

Sécurisation – WS-Security Originellement développé par IBM, Microsoft, Veri. Sign 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#wssv 1. 1 4

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 5

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

XML Signature Objectif 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 q Le document peut être recomposé/transformé par le récepteur Signatures sur plusieurs entités q 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) q SOAP request/response Signature d’ entités externes référencées par des URI (signature détaché) q HTML, éléments Media, CSS … 7

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 W 3 C et IETF XML Digital Signature http: //www. w 3. org/TR/xmldsig-core/ Canonisation http: //www. w 3. org/TR/xml-c 14 n API Java : JSR 105 XML Digital Signature APIs (javax. security. xml. dsig) 8

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 ; 9

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

XML Signature – Exemple de signature détachée [s 01] <Signature Id="My. First. Signature" xmlns="http: //www. w 3. org/2000/09/xmldsig#"> [s 02] <Signed. Info> [s 03] <Canonicalization. Method Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> [s 04] <Signature. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#dsa-sha 1"/> [s 05] <Reference URI="http: //www. w 3. org/TR/2000/REC-xhtml 1 -20000126/"> [s 06] <Transforms> [s 07] <Transform Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> [s 08] </Transforms> [s 09] <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1"/> [s 10] <Digest. Value>j 6 lwx 3 rv. EPO 0 v. Kt. Mup 4 Nbe. Vu 8 nk=</Digest. Value> [s 11] </Reference> [s 12] </Signed. Info> [s 13] <Signature. Value>MC 0 CFFr. VLt. Rlk=. . . </Signature. Value> [s 14] <Key. Info> [s 15 a] <Key. Value> [s 15 b] <DSAKey. Value> [s 15 c] <P>. . . </P><Q>. . . </Q><G>. . . </G><Y>. . . </Y> [s 15 d] </DSAKey. Value> [s 15 e] </Key. Value> [s 16] </Key. Info> [s 17] </Signature> 11

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, . . 12

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 <Signature. Properties> 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 13

XML Signature – Les éléments optionnels exemple [ ] <Signature Id="My. Second. Signature". . . > [p 01] <Signed. Info> [ ]. . . [p 02] <Reference URI="http: //www. w 3. org/TR/xml-stylesheet/"> [ ]. . . [p 03] <Reference URI="#AMade. Up. Time. Stamp « [p 04] Type="http: //www. w 3. org/2000/09/xmldsig#Signature. Properties"> [p 05] <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1"/> [p 06] <Digest. Value>k 3453 rv. EPO 0 v. Kt. Mup 4 Nbe. Vu 8 nk=</Digest. Value> [p 07] </Reference> [p 08] </Signed. Info> [p 09]. . . [p 10] <Object> [p 11] <Signature. Properties> [p 12] <Signature. Property Id="AMade. Up. Time. Stamp" Target="#My. Second. Signature"> [p 13] <timestamp xmlns="http: //www. ietf. org/rfc. XXXX. txt"> [p 14] <date>19990908</date> [p 15] <time>14: 34: 34</time> [p 16] </timestamp> [p 17] </Signature. Property> [p 18] </Signature. Properties> [p 19] </Object> [p 20]</Signature> 14

XML Signature – Les éléments optionnels Key. Info Permet au récepteur d’obtenir la clé nécessaire à valider la signature Key. Name (un nom, un index dans un répertoire de clé, un X 500 DN, …) Retrieval. Method Certificats : X 509, PGP, SPKI Clés publiques : RSA, DSA 15

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 Digest. Value. (À 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) 16

XML Signature – traitements génération La génération de la signature Créer l'élément Signed. Info avec les éléments Signature. Method, Canonicalization. Method et Reference ; Canoniser puis calculer l'élément Signature. Value sur l'élément Signed. Info, en fonction des algorithmes spécifiés dans Signed. Info ; Construire l'élément Signature qui inclut les éléments Signed. Info, le ou les Object (si on le désire, le codage peut être différent de celui utilisé pour la signature), Key. Info (si requis) Signature. Value. À 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). 17

XML Signature – traitements validation La validation de référence Canoniser l'élément Signed. Info en fonction de l'élément Canonicalization. Method dans Signed. Info ; Pour chaque élément Reference dans Signed. Info : 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 Digest. Method spécifié dans son élément Reference ; Comparer la valeur condensée générée avec la valeur de Digest. Value dans l'élément Reference de Signed. Info ; s'il y a une quelconque divergence, la validation échoue. À noter que l'élément Signed. Info est canonisé lors de la génération des référence. L'application (programme) doit s'assurer que l'élément Canonicalization. Method 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. 18

XML Signature – traitements La validation de signature Obtenir les informations de la clé à partir de l'élément Key. Info ou d'une source externe ; Obtenir la forme canonique de l'élément Signature. Method en utilisant l'élément Canonicalization. Method, puis utiliser le résultat (et les informations de clé de l'élément Key. Info précédemment obtenues) pour confirmer la valeur de l'élément Signature. Value sur l'élément Signed. Info. À noter que l'élément Key. Info (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 Key. Info lors de l'analyse. De plus, l'attribut URI de l'élément Signature. Method peut avoir été altéré par la canonisation de Signed. Info (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-C 14 N] de cette spécification ne change pas les URI. 19

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 W 3 C XML Digital Encryption http: //www. w 3. org/TR/xmlenc-core/ API Java JSR 106 XML Digital Encryption APIs 20

XML Encryption - Exemple <? xml version=“ 1”? > <notes> <etudiant id=“ 1”> <nom>Dupont</nom> <note> <Encrypted. Data xmlns='http: //www. w 3. org/2001/04/xmlenc#' Type='http: //www. w 3. org/2001/04/xmlenc#Content'> <Cipher. Data> <Cipher. Value>A 23 B 45 C 56</Cipher. Value> </Cipher. Data> </Encrypted. Data> </note> </etudiant> <etudiant id=“ 2”> <nom>Durand</nom> <note> <Encrypted. Data xmlns='http: //www. w 3. org/2001/04/xmlenc#' Type='http: //www. w 3. org/2001/04/xmlenc#Content'> <Cipher. Data> <Cipher. Value>A 23 B 45 C 23</Cipher. Value> </Cipher. Data> </Encrypted. Data> </note> </etudiant> </notes> 21

XML Encryption Le résultat du chiffrement des données est un élément XML Encryption Encrypted. Data 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 Encrypted. Data est constitué de plusieurs sous éléments. 22

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 23

XML Encryption Encrypted. Type : Type abstrait à partir duquel les éléments Encrypted. Data et Encrypted. Key sont dérivés L’élément Encryption. Method est optionnel L’élément ds: Key. Info est optionnel L’élément Cipher. Data est obligatoire L’élément Encryption. Properties L’attribut Id est optionnel L’attribut Type est optionnel L’attribut Mime. Type est optionnel 24

XML Encryption Pour déchiffrer les données il existe plusieurs méthodes : 1. Les éléments Encrypted. Data ou Encrypted. Key spécifient le matériel de gestion des clés via un enfant de l’élément ds: Key. Info 2. Un élément Encrypted. Key détaché est utilisé 3. 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 25

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) 26

XKMS Basé sur XML Signature & XML Encryption W 3 C XKMS XML Key Management Specification Pour la v 1 http: //www. w 3. org/TR/xkms/ Pour la v 2 http: //www. w 3. org/TR/xkms 2/ API Java JSR 104 XML Trust Service APIs 27

XKMS 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. 28

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: Key. Info>. 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: Key. Info>, mais elle assure également que les informations liées à la clé retournées sont dignes de confiance. 29

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. 30

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. oasisopen. org/committees/tc_home. php? wg_abbrev=s ecurity http: //saml. xml. org/ 31

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 32

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 33

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. 34

SAML – Assertion Exemple 35

XACML (Extensible Access Control Markup. Language) 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 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. oasisopen. org/committees/xacml/repository/cs-xacmlspecification-1. 1. pdf 36

XACML 37

XACML 1. Réception d’une requête qui aboutit à un PEP 2. Le PEP formule en XACML la requête que l’agent adresse à la ressource ("Je, soussigné agent XYZ, désire la ressource ABC. ") 3. Le PEP envoie cette requête XACML à un “PDP” (Policy Decision Point). 4. 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. 5. 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 6. Le PDP envoie sa réponse au PEP qui agit en conséquence (donne accès à la ressource ou renvoie un message d’erreur). 38

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 39

XACML - Exemple 40

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. 41