La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "1 Les technologies XML Cours 8 : Les Web Services Sécurisation Mars 2011 - Version 1.0 -"— Transcription de la présentation:

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

2 2 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

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

4 4 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. IBMMicrosoftVeriSignIBMMicrosoftVeriSign 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. intégritéconfidentialitéservices webSAMLKerberosX.509intégritéconfidentialitéservices webSAMLKerberosX.509 OASIS WSS : open.org/specs/index.php#wssv1.1

5 5 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 soccupe de lensemble 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

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

7 7 XML Signature Objectif Prévenir la falsification dun 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 …

8 8 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 lencodage (esp. Cr,..) sur le calcul de la signature W3C et IETF XML Digital Signature Canonisation API Java : JSR 105 XML Digital Signature APIs (javax.security.xml.dsig)

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

10 10 XML Signature – Construction message Objet Sha Clef de lémetteur ShaDsa Infos signées DigestUri Signature Infos Signées Signature Clef Objets certificat Clef privée

11 11 XML Signature – Exemple de signature détachée [s01] [s02] [s03] [s04] [s05] [s06] [s07] [s08] [s09] [s10] j6lwx3rvEPO0vKtMup4NbeVu8nk= [s11] [s12] [s13] MC0CFFrVLtRlk=... [s14] [s15a] [s15b] [s15c] [s15d] [s15e] [s16] [s17]

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

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

14 14 XML Signature – Les éléments optionnels exemple [ ] [ ] [p01] [p01] [ ]... [p02] [p02] [ ]... [p03] [p05] [p05] [p06] k3453rvEPO0vKtMup4NbeVu8nk= [p06] k3453rvEPO0vKtMup4NbeVu8nk= [p07] [p07] [p08] [p08] [p09]... [p10] [p10] [p11] [p11] [p12] [p12] [p13] [p13] [p14] [p14] [p15] 14:34:34:34 [p15] 14:34:34:34 [p16] [p16] [p17] [p17] [p18] [p18] [p19] [p19] [p20]

15 15 XML Signature – Les éléments optionnels KeyInfo Permet au récepteur dobtenir 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

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

17 17 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). XMLXML-schemaXMLXML-schema

18 18 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. voit ce qui est signévoit ce qui est signé

19 19 XML Signature – traitements La validation de signature Obtenir les informations de la clé à partir de l'élément KeyInfo ou d'une source externe ; KeyInfo 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. KeyInfo 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-C14N

20 20 XML Encryption Pourquoi ? Différents destinataires doivent pouvoir lire différentes parties du document (exemple dun document regroupant toutes les notes des étudiants) La sécurité doit être maintenue de bout en bout W3C XML Digital Encryption API Java JSR 106 XML Digital Encryption APIs

21 21 XML Encryption - Exemple Dupont A23B45C56 Durand A23B45C23

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

23 23 XML Encryption Il est possible de chiffrer tout ou partie dun document : On peut chiffrer lensemble dun document Un élément complet ce qui permet de masquer le type dun élément La valeur dun élément XML Encryption utilise la cryptographie à clé publique afin dassurer la confidentialité lors des transferts

24 24 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

25 25 XML Encryption Pour déchiffrer les données il existe plusieurs méthodes : 1.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 2.Un élément EncryptedKey détaché est utilisé 3.Le destinataire peut déterminer le matériel de gestion des clés selon le contexte de lapplication et il nest donc pas nécessaire de le mentionner explicitement

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

27 27 XKMS Basé sur XML Signature & XML Encryption W3C XKMS XML Key Management Specification Pour la v1 Pour la v2 API Java JSR 104 XML Trust Service APIs

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

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

30 30 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 ; X.509 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.

31 31 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. XMLOASISXMLOASIS Ressources : open.org/committees/tc_home.php?wg_abbrev=s ecurity open.org/committees/tc_home.php?wg_abbrev=s ecurityhttp://www.oasis- open.org/committees/tc_home.php?wg_abbrev=s ecurityhttp://www.oasis- open.org/committees/tc_home.php?wg_abbrev=s ecurity

32 32 SAML Un SAML token (une identité portable) permet le transport des attributs de sécurité dune 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 dauthentification et SAML permet la confiance inter-domaine. Chaque organisation fait ou non le choix de faire confiance aux membres dune autre organisation basé sur les assertions SAML

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

34 34 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 ninteropérant pas. authentification uniquewebintranetcookiesauthentification uniquewebintranetcookies 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 dau moins un fournisseur d'identité. Ce fournisseur d'identité est censé fournir des services d'authentification locaux au principal. fournisseur d'identitéservices d'authentificationfournisseur d'identitéservices d'authentification

35 35 SAML – Assertion Exemple

36 36 XACML 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. 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 daccès à une ressource protégée Formalisme XML pour exprimer des politiques(règles) dautorisation daccès OASIS open.org/committees/xacml/repository/cs-xacml- specification-1.1.pdf

37 37 XACML

38 38 XACML 1. 1.Réception dune requête qui aboutit à un PEP 2. 2.Le PEP formule en XACML la requête que lagent adresse à la ressource ("Je, soussigné agent XYZ, désire lire la ressource ABC.") 3. 3.Le PEP envoie cette requête XACML à un PDP (Policy Decision Point) Le PDP compare la requête XACML avec les règles dautorisation qui ont été définies pour sappliquer aux requêtes de ce type, sur cette ressource ABC Le PDP formule sa décision dautorisation ("Je consens à ce que lon réponde à cette requête ou je refuse") également en XACML 6. 6.Le PDP envoie sa réponse au PEP qui agit en conséquence (donne accès à la ressource ou renvoie un message derreur).

39 39 XACML Proposition d implantation de la norme par SUN : Classes Java JDK > 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

40 40 XACML - Exemple

41 41 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. Lutilisation des solutions de sécurisation présentées ici peut savérer compliquée et coûteuse en terme de performance.


Télécharger ppt "1 Les technologies XML Cours 8 : Les Web Services Sécurisation Mars 2011 - Version 1.0 -"

Présentations similaires


Annonces Google