1 / 48

Développement de Services Web sécurisés et interopérables avec WS-* et WSE 2.0 SP3

Développement de Services Web sécurisés et interopérables avec WS-* et WSE 2.0 SP3. Philippe Beraud Consultant Principal Microsoft France. Excellence de l’engineering. Mise à jour avancée. Conseils, Outils, Réponse. Isolation et résilience. La stratégie sécurité de Microsoft.

ianna
Download Presentation

Développement de Services Web sécurisés et interopérables avec WS-* et WSE 2.0 SP3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Développement de Services Web sécurisés et interopérables avec WS-* et WSE 2.0 SP3 Philippe Beraud Consultant Principal Microsoft France

  2. Excellence de l’engineering Mise à jour avancée Conseils, Outils, Réponse Isolation et résilience La stratégie sécurité de Microsoft Authentification, Autorisation, Audit

  3. Sommaire • Vue d’ensemble sur Web Services Architectures (WSA) • Fondamentaux de la sécurité des services Web (WS-Security) • Définir un cadre de confiance entre clients et services (WS-Trust) • Rendre possible une infrastructure B2B gérable • Créer un contexte de sécurité (WS-SecureConversation) • Offrir de meilleures performances vis-à-vis de la sécurité • Décrire des politiques de sécurité (WS-SecurityPolicy) • Supprimer le besoin d’écrire du code de sécurité

  4. WS-* Web Service Architecture (WSA) • STAR pour Secure, Transactional, Asynchronous, Reliable • « An Introduction to the Web Services Architecture and Its Specifications » • http://msdn.microsoft.com/library/en-us/dnwebsrv/html/introwsa.asp Service Composition BPEL4WS, Management Composable Service Assurances Reliable Messaging Transactions Security XSD, WSDL, UDDI, Policy, MetadataExchange Description Messaging XML, SOAP, Addressing Transports HTTP, HTTPS, SMTP, etc.

  5. Importance de la composition • Tout fonctionne en association • Ex: Le contexte transactionnel fonctionne au-dessus d'une connexion fiable • Ex: Les participants utilisent WS-Security pour sécuriser les transactions (pour tous les types de participants) • Ne pas « réinventer la roue » pour chaque spécification • Réutilisation du code, réduction des coûts, un temps de mise à disposition plus court • Ex: l’ensemble des ressources est nommé avec WS-Addressing • Le système dans son ensemble est plus stable • Les changements ne filtrent pas vers le haut de la pile • Ex: avec WS-Security, les scénarios de fédération d’identité supporte l’ensemble des jetons de sécurité, y compris les futurs

  6. Composition des en-têtes <S:Envelope … > <S:Header> <wsa:ReplyTo> <wsa:Address>http://business456.com/User12</wsa:Address> </wsa:ReplyTo> <wsa:To>http://fabrikam123.com/Traffic</wsa:To> <wsa:Action>http://fabrikam123.com/Traffic/Status</wsa:Action> <wssec:Security> <wssec:BinarySecurityToken ValueType="wssec:X509v3" EncodingType=“wssec:Base64Binary">      dWJzY3JpYmVyLVBlc…..eFw0wMTEwMTAwMD </wssec:BinarySecurityToken> </wssec:Security> <wsrm:Sequence> <wsu:Identifier>http://fabrikam123.com/seq1234</wsu:Identifier> <wsrm:MessageNumber>10</wsrm:MessageNumber> </wsrm:Sequence> </S:Header> <S:Body> <app:TrafficStatus xmlns:app="http://highwaymon.org/payloads"> <road>520W</road><speed>3MPH</speed> </app:TrafficStatus> </S:Body> </S:Envelope> Addressing Security Reliable Messaging

  7. Révision de la spécification, itérationImplémentation Spécification publiée Recueil des feedbacks Organismes de normalisation Processus d’élaboration des spécifications • Revue ouverte et publique des spécifications WS-* via le processus de workshops • Approche ouverte de bout en bout permettant de réconcilier des objectifs conflictuels • Qualité d’ingénierie, Réduction du temps de mise à disposition sur le marché, Ampleur de l’adoption et du support par l’industrie • « Web Services Protocol Workshops Process Overview » • http://msdn.microsoft.com/library/en-us/dnwebsrv/html/wkshopprocess.asp • Liste des workshops • http://msdn.microsoft.com/webservices/community/workshops/default.aspx • Mailing list pour la préparation • http://groups.yahoo.com/group/WS-Security-Workshops

  8. Web Service Enhancement (WSE) 2.0 • Extension (Add-on) supportée de Visual Studio.NET (VS.NET) et du Framework .NET • Version 2.0 Service Pack 3 • Téléchargeable depuis http://msdn.microsoft.com/webservices/building/wse • Documentation, QuickStart (C#, Visual Basic) • Boîte à outils • WseWsdl2, WseSettings, WseCertificate2 • Cycle de mises à jour plus rapide que VS.NET • Proposer le plus tôt possible une implémentation des dernières spécifications WS-* (ou de leur révision) publiées par Microsoft et d’autres acteurs • WS-Security, WS-SecurityPolicy, WS-Trust, WS-SecureConversation, WS-Referral, WS-Addressing, WS-Policy, « DIME », WS-Attachments • Simplification considérable du développement de services Web sécurisés • Y compris à travers de multiples intermédiaires et domaines de confiance • Les fonctionnalités additionnelles incluent le support de transports alternatifs, du routage de message, etc.

  9. Filtres de sortie Filtres d’entrée Expéditeur de messages SOAP Service Web Filtres d’entrée Filtres de sortie Architecture WSE 2.0 • Ensemble de classes implémentant les nouveaux standards WS-* • Manipulation des en-têtes SOAP • Notion de pipeline et filtres hébergés par ASP.NET • Écriture (Injection) d’en-têtes SOAP dans le messages sortants • Transformation du corps SOAP du message (chiffrement/déchiffrement) • Lecture des en-têtes SOAP des messages entrants • Possibilité d’insérer ses propres filtres dans le pipeline • « Inside the Web Services Enhancements Pipeline » • http://msdn.microsoft.com/library/en-us/dnwse/html/insidewsepipe.asp

  10. Traitement des en-têtes • Nécessité d’interpréter et de comprendre le schéma des en-tête • Retourner un SOAP Fault dans le cas d’une en-tête mustUnderstand="1" non comprise [WebMethod] [SoapHeaders("headers")] Public returnType Foo(…) { ProcessHeaders(headers); … } … public static void ProcessHeaders(SoapUnknownHeader[] hdrs) { if(hdrs != null) { foreach(SoapUnknownHeader hdr in hdrs) { if(hdr.MustUnderstand==true) { hdr.DidUnderstand=false; throw new SoapHeaderException("Header was notunderstood", SoapException.MustUnderstandFaultCode); } } } }

  11. Feuille de route WS-Security (WS-*) • « Security in a Web Services World: A Proposed Architecture and Roadmap » • http://msdn.microsoft.com/library/en-us/dnwssecur/html/securitywhitepaper.asp • WSE 2.0 • Support de WS-Security, WS-Trust, WS-SecureConversation, WS-SecurityPolicy WS-Federation WS-Security Policy WS-Secure Conversation WS-Trust Standard de l’OASIS aujourd’hui largement supporté WS-Security Standard W3C, fondation des services Web SOAP

  12. WS-Security, la fondation • « Web Services Security SOAP Message Security 1.0 » • WS-Security 2004, OASIS Standard 200401, Mars 2004 • http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf • Disponibilité d’un profil d’interopérabilité WS-I • Basic Security Profile Working Group • http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity • Définit un « framework » pour la construction de protocoles de sécurité capitalisant sur les spécifications XML de sécurité existantes • Intégrité (et non répudiation) • S’appuie sur W3C « XML Signature Syntax and Processing » (XMLDSIG) • http://www.w3.org/TR/xmldsig-core • Signatures multiples, parties spécifiques • Confidentialité • S’appuie sur W3C «  XML Encryption Syntax and Processing » (XMLENC) • http://www.w3.org/TR/xmlenc-core • Chiffrement multiples, parties spécifiques • Propagation des jetons de sécurité • Support des jetons binaires et XML

  13. Intermédiaire Intermédiaire Émetteur Destinataire … WS-Security • « Framework » conçu pour une sécurité de bout en bout pour les messages SOAP • De l’émetteur initial via 0-n nœuds intermédiaires au destinataire ultime • Sécurité indépendante du transport • Support de multiples protocoles de transport et technologies de chiffrement • L’émetteur ne doit faire confiance qu’au point de terminaison • Par opposition à une sécurité point à point (SSL/TLS et/ou IPSec) plus simple et connue • Gestion au niveau transport • Restreint les protocoles de transport qui peuvent être utilisée • L’expéditeur doit faire confiance à l’ensemble des intermédiaires

  14. Jetons de sécurité • Bases pour une authentification et une autorisation distribuées • Les jetons de sécurité définissent des affirmations faites au sujet d’une identité, d’aptitude ou de privilèges • Nom, adresse mèl, clé, groupe, rôle, etc. • Attributs/propriétés de sécurité • Quelques exemples • Non signé • Jeton Nom d’utilisateur • Signé • Certificat X.509, ticket Kerberos, assertion SAML, licence XrML, etc. • Preuve de possession • Clé secrète, mot de passe • L’authentification implique la vérification de cette connaissance Microsoft.Web.Services2.Security .SecurityToken .UsernameToken .SecurityContextToken [jetons de sécurité XML] … .BinarySecurityToken .KerberosToken(2) .X509SecurityToken [jetons binaires personnalisés] …

  15. Chiffrement asymétrique Fonction de hashage (SHA, MD5) Signatures numériques pour l’intégrité • Des parties spécifiques du message peuvent être signées pour assurer l’intégrité et la non répudiation • Savoir que le message n’a pas été altéré, savoir que seul l’expéditeur a pu l’envoyer • Par défaut, WSE signe un ensemble de parties du messages • Microsoft.Web.Services2.Security.MessageSignature • Soap:Envelope/soap:Header/wsa:To, Soap:Envelope/soap:Header/wsa:Action, Soap:Envelope/soap:Header/wsa:MessageID, Soap:Envelope/soap:Header/wsa:From/wsa:Address, Soap:Envelope/soap:Header/wsu:Timestamp/wsu:Created, Soap:Envelope/soap:Header/wsu:Timestamp/wsu:Expires, Soap:Envelope/soap:Body • Créer une signature numérique (émetteur) Message à envoyer Condensé Signature numérique Jrf843kjfgf*£$&Hdif*7oUsd*&@:<CHDFHSD(** Py75c%bn&*)9|fDe^bDFaq#xzjFr@g5=&nmdFg$5knvMd’rkvegMs” Clé privée

  16. Condensé de la donnée à protéger Signature sur l’élément ds:SignedInfo Jeton de sécurité Référence de la donnée à protéger Signatures numériques pour l’intégrité Exemple de signature numérique <s:Envelope xmlns:s='...' xmlns:wsu='...'xmlns:ws='...' xmlns:ds='...' > <s:Header> <ws:Security s:mustUnderstand='true' > <ws:BinarySecurityToken wsu:Id='Me' ValueType=‘http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3' EncodingType=‘http://dosc.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security- 1.0#Base64Binary' > MeIIZFgea4FGiu5cvWEklO8pl... </ws:BinarySecurityToken> … <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' /> <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' /> <ds:Reference URI='#Body' > <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' /> <ds:DigestValue>uJhGtef54ed91iKLoA...</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>FR8yaKmNDePQ7E3Hj...</ds:SignatureValue> …

  17. Référence au jeton qui peut être utilisé pour vérifier la signature Données signées Signatures numériques pour l’intégrité Exemple de signature numérique … <ds:KeyInfo> <ws:SecurityTokenReference> <ws:Reference URI='#Me‘ ValueType=' http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile- 1.0#X509v3' /> </ws:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </ws:Security> … </s:Header> <s:Body wsu:Id='Body' > … </s:Body> </s:Envelope>

  18. Déchiffrement asymétrique Même fonction de hashage Signatures numériques pour l’intégrité • Vérifier une signature numérique (destinataire) Signature numérique Condensé Py75c%bn&*)9|fDe^bDFaq#xzjFr@g5=&nmdFg$5knvMd’rkvegMs” Jrf843kjfgf*£$&Hdif*7oUsd*&@:<CHDFHSD(** Clé publique envoyée avec le message ? == ? Py75c%bn&*)9|fDe^bDFaq#xzjFr@g5=&nmdFg$5knvMd’rkvegMs” Message d’origine

  19. Signature d’un message avec un certificat X.509

  20. Chiffrement asymétrique Chiffrement symétrique Chiffrement XML pour la confidentialité • Des parties spécifiques du message peuvent être chiffrés pour assurer la confidentialité • Le texte en clair est remplacé par du texte chiffré • Dans WSE, Microsoft.Web.Services2.Security.Cryptography • Chiffrer un message (expéditeur) Clé publique du destinataire Clé symétrique générée Clé chiffrée AyD5c%bné”*)9|fDe^bDFaq#xzjFKr@67=&nmdWzm5knvMd’rkvegMs” Py75c%bn&*)9|fDe^bDFaq#xzjFr@g5=&nmdFg$5knvMd’rkveq#xzjFrgMs”

  21. Déchiffrement asymétrique Déchiffrement symétrique Chiffrement XML pour la confidentialité • Déchiffre un message (destinataire) Clé privée du destinataire Clé chiffrée AyD5c%bné”*)9|fDe^bDFaq#xzjFKr@67=&nmdWzm5knvMd’rkvegMs” Py75c%bn&*)9|fDe^bDFaq#xzjFr@g5=&nmdFg$5knvMd’rkveq#xzjFrgMs”

  22. Chiffrement d’un message avec un TGS Kerberos

  23. Identité et relations de confiance • Les services Web sont des agents autonomes • Le développement, le déploiement, le fonctionnement, l’administration et la sécurité varient indépendamment des clients des services • Cette « indépendance forcée » présente d’importantes ramifications qui s’infiltrent dans l’architecture des services Web Comment prouver qui je suis ? Qui peut se porter garant pour moi ? Comment savoir en qui accorder sa confiance ? • Met l’accent sur la gestion explicite des relations de confiance entres les applications et services • WS-Security permet qu’un message contienne plusieurs jetons de sécurité • Certains de ces jetons peuvent correspondre à des identités d’utilisateurs • D’autres jetons peuvent correspondre aux droits accordés à un utilisateur particulier ou à une application • Ils peuvent être chiffrés et validés dans le cadre général d’un schéma d’autorisation • Nécessite que des processus ou des systèmes qui étaient centralisés évoluent vers un modèle fédéré • Cela s’applique non seulement aux identités de sécurité mais aussi aux annuaires de services et à l’administration de systèmes

  24. WS-Trust • « Web Services Trust Language »  • Actional, BEA Systems, CA, IBM, L7T, Microsoft, Oblix, OpenNetwork, PingId, Reactivity, RSA, Verisign, Février 2005 • http://msdn.microsoft.com/ws/2005/02/ws-trust • Introduit la notion de Security Token Service (STS) • Un STS est potentiellement tout service Web capable d’émettre des jetons • Tout le monde peut émettre des jetons • Définit comment faire du courtage de confiance • Besoin d’un initiateur • Définit un protocole pour demander et obtenir des jetons de sécurité • Les jetons sont destinés à tout type d’usage comme la sécurisation d’une séquence de message, et pas uniquement à l’authentification • Définit différents modèles

  25. Demande d’un nouveau jeton Type de jeton demandé Obtention d’un jeton • Demande d’un jeton de sécurité (wsse:ReqIssue) • Envoi d’un message Request Security Token (RST) au STS • D’ordinaire signé avec un jeton en qui l’émetteur de jeton fait confiance <s:Envelope> … <s:Body wsu:Id='request' > <wst:RequestSecurityToken xmlns:wst=‘...’ > <wst:TokenType> http://www.docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-saml-token-profile- 1.0#SAMLAssertion-1.1 </wst:TokenType> <wst:RequestType> http://schemas.xmlsoap.org/ws/2004/04/security/trust/Issue </wst:RequestType> </wst:RequestSecurityToken> </s:Body> </s:Envelope>

  26. Preuve de possession Jeton de sécurité demandé Obtention d’un jeton • Message Request Security Token Response (RSTR) retourné par le STS • Contient le jeton demandé et une preuve de possession (optionnelle) • Le jeton comprend une clé que le demandeur peut utiliser pour prouver qu’il est autorisé à utiliser le jeton émis • Support natif par WSE de ces opérations • Microsoft.Web.Services2.Security • Support également de la création d’un STS personnalisé <s:Envelope> … <s:Body wsu:Id='response' > <wst:RequestSecurityTokenResponse> <wst:RequestedSecurityToken> <saml:Assertion xmlns:saml='...' > … </saml:Assertion> </wst:RequestedSecurityToken> <wst:RequestedProofToken> <xe:EncryptedKey Id='Sym' > … </xe:EncryptedKey> </wst:RequestedProofToken> </wst:RequestSecurityTokenResponse> </s:Body> </s:Envelope>

  27. T2 T1 T1 T# T2 Autres modèles proposés • Échange d’un jeton de sécurité(wsse:ReqExchange) • Définit comment échanger un jeton pour un autre 2. Demande d’échange du jeton Username au service de mappage A (STS) (utilise wsse:ReqExchange) 1. Émission à destination du service C d’un message signé avec un jeton Username 1 2 A B 3 3. Réponse du service de mappage A avec le jeton X.509 associé au jeton Username 4 4. Transfert au service C par le routeur B du message signé avec le certificat X.509 C Jeton de sécurité

  28. T# T# T# T# Autres modèles proposés • Validation d’un jeton de sécurité (wsse:ReqValidate) • Définit comment vérifier des jetons et des signatures à l’aide d’un STS A 3. Vérification par le service de validation que le jeton est suffisant 1. Émission à destination du service B d’un message avec un jeton de sécurité 2 3  ? 2. Envoi par le service B du jeton au service de validation A (utilise wsse:ReqValidate) B 1 Jeton de sécurité

  29. C T1 T# T1 P1 P# Topologies de confiance • Différentes topologies vis-à-vis de l’émission de jetons • Le client obtient un jeton depuis une source bien connue, le service obtient un jeton pour le client, etc. • Mise en œuvre au travers des protocoles d’authentification utilisant les technologies modernes de chiffrement (asymétrique et symétrique) • Confiance directe Périmètre de confiance A 1. Demande d’un jeton au STS A (utilise wsse:ReqIssue), jeton dans la réponse wsse:RequestSecurityTokenResponse 1 2 B 2. Émission d’un message à destination du service B avec le jeton Jeton de sécurité Preuve de possession

  30. C T1 T1 T2 T# T2 P1 P# P2 Topologies de confiance • Confiance via « courtier » • Le client et le service peuvent faire chacun confiance à un STS ce qui évite d’avoir à gérer une confiance directe A B Obtention d’un jeton d’accès Obtention d’un jeton d’identité 1 2 3 Jeton de sécurité Preuve de possession

  31. …Récursivité Directe - Échange d’une clé symétrique ou d’un certificat Directe - Échange d’une clé symétrique ou d’un certificat B T# T1 Indirecte – B garant de A et des identités de B P1 P# Topologies de confiance • Confiance indirecte • C fait confiance à B qui se porte garant de A qui répond du client C A Obtention d’un jeton d’identité 1 2 Jeton de sécurité Preuve de possession

  32. Topologies de confiance Délégation 1 2 4 3 5

  33. Politique de fédération C T1 T1 T2 T2 P1 P2 Politique d’accès Modèle de fédération piloté par les méta données Les services comprennent des jetons spécifiques, les services de jetons de sécurité traduisent les jetons (de ce que le principal possède à ce que le service a besoin) et WS-* fournit une pile standard et l’enveloppe Service Cible Service d’identité Service de jetons de sécurité (le service de contrôle d’accès fournit les jetons de permission) Services de pseudonymes et d’attributs

  34. WS-SecureConversation • Les nœuds doivent souvent échanger plus d’un message • Une conversation implique plusieurs échanges entre un client et un service Web • WS-Security fournit des mécanismes de sécurité vis-à-vis de messages uniques • L’utilisation de clés asymétriques est lente pour de multiples messages • Spécifier des clés symétriques pour chaque message est lourd, verbeux, et inefficace • Impact sur la taille des messages et les performances • WS-SecureConversationdéfinit les mécanismes pour adresser cela • « Web Services Secure Conversation Language »  • Actional, BEA Systems, CA, IBM, L7T, Microsoft, Oblix, OpenNetwork, PingId, Reactivity, RSA, Verisign, Février 2005 • http://msdn.microsoft.com/ws/2005/02/ws-secure-conversation

  35. WS-SecureConversation • Établit un contexte de sécurité partagé ou Security Context Token (SCT) • Beaucoup plus performant pour de multiples appels • Le contexte contient les clés/secrets et d’autre information • Peut être sans état • L’état est embarqué dans le jeton de sécurité • Le contexte est établi à l’aide de WS-Trust • Définit un profil distinct d’émission, de renouvellement et d’annulation <s:Envelope xmlns:s='http://www.w3.org/2003/05/soap-envelope' > <s:Header> <ws:Security s:mustUnderstand='true' > <wsc:SecurityContextToken> <wsc:Identifier> uuid:652d2aaa-4857-4d8c-865c-f9549e5806f0</wsc:Identifier> </wsc:SecurityContextToken> </ws:Security> </s:Header> <s:Body wsu:Id='request'> … </s:Body> </s:Envelope>

  36. SCT SCT Demande d‘un SCT SCT émis vers le client Client Service Web et STS Séries de messages signés avec le SCT émis Créer des conversations sécurisées • Dans WSE, ce jeton « léger » prend la place d’un jeton exigeant un traitement plus intensif • Microsoft.Web.Services2.Security • Le STS peut être localisé au niveau du service ou être un point de terminaison distinct • Les services peuvent émettre leurs propres SCTs • Plus besoin de déployer un émetteur de SCTs • Élément de configuration à activer <autoIssueSCT enabled=true />

  37. Dérivation de clés • L’échange de clefs et leur réutilisations amène des vulnérabilités en termes de sécurité • Le degré d’aléatoire (entropie) n’est pas connu des deux parties • Les clés sont utilisées sur une période prolongée et/ou sur des données similaires • Il est plus sûr d’échanger un secret et de dériver des clés sur cette base • DerivedKey • Définit l’utilisation des clés dérivées • Autorise la dérivation de multiples clés sur la base de la combinaison d’un secret initial, de nonces et de libellés au cours du temps • DerivedKey sur la base d’un SCT • Utilisation des jetons clé dérivée • Référence un secret (ici le SCT qui implique une cible) • Il est recommandé de générer des nonces pour chaque message

  38. SCT DK1 DK2 DK Jeton DerivedKey Security Context Token Dérivation de clés … <wss:Security><wsc:SecurityContextToken wsu:Id='Session' > <wsc:Identifier> uuid:55281202-fdc8-460f-b154-745ab6029391 </wsc:Identifier> </wsc:SecurityContextToken> <wsc:DerivedKeyToken wsu:Id='DKT1' > <wss:SecurityTokenReference><wss:Reference URI='#Session' ValueType='http://schemas.xmlsoap.org/ws/2004/04/security/sc/sct' /> </wss:SecurityTokenReference> <wsc:Length>16</wsc:Length><wsc:Nonce>KMkRDInROAJQcLcTjyxliw==</wsc:Nonce> </wsc:DerivedKeyToken> … </wse:Security>…

  39. WS-Policy • Au delà de ce que WSDL fournit, quoi d’autre est nécessaire pour décrire un service Web ? • Exigences de sécurité, Garantie de transmission fiable de messages, Version du protocole, Etc. • Ces autres attributs d'un service peuvent être décrits avec WS-Policy • « Web Services Policy Framework» • BEA Systems, IBM, Microsoft, SAP, Sonic Software, VeriSign, Septembre 2004 • http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-policy.asp • Langage basé sur XML pour la description des exigences d’un service • Une politique peut être appliquée côté émission ou réception • Réduit la quantité de code à écrire • Un fichier de politique contient des politiques et des mappages • WSE n’offre pas de support de WS-PolicyAttachment aujourd’hui • Une politique est mappée sur un message particulier à l’exécution

  40. WS-SecurityPolicy • « Web Services Security Policy Language » • IBM, Microsoft, RSA, VeriSign, Décembre 2002 • http://msdn.microsoft.com/ws/2002/12/ws-security-policy • Définit un ensemble d'assertions pour l’expression d’exigences relatives à WS-Security • Exigence d’intégrité <Integrity> • Exigence de confidentialité <Confidentiality> • Exigence en termes de jeton de sécurité <SecurityToken> • Peut être intégrée dans les deux autres • Positionnées via le Security Settings Wizard

  41. Politique Fichier de politique <?xml version="1.0" encoding="utf-8"?> <policyDocument xmlns="http://.../Policy"> <mappings xmlns:wse="http://.../Policy"> <defaultEndpoint> <defaultOperation> <request policy="#signed-body-x509" /> <response policy="" /> </defaultOperation> </defaultEndpoint> </mappings> <policies xmlns:wsu="http://...wssecurity-utility-1.0.xsd" xmlns:wsp="http://.../policy"xmlns:wssp="http://.../secext" xmlns:wse="http://.../Policy" xmlns:wsse="http://...wssecurity-secext-1.0.xsd" xmlns:wsa="http://.../addressing"> <wsp:Policy wsu:Id="signed-body-x509"> <wsse:Integrity wsp:Usage="wsp:Required" > <TokenInfo> <SecurityToken> <TokenType>X509v3</TokenType> </SecurityToken> </TokenInfo> <MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part"> wsp:Body() </MessageParts> </wsse:Integrity> </wsp:Policy> </policies> </policyDocument>

  42. Mise en œuvre d’une conversation sécurisée via l’expression de politiques

  43. Fonctionnalités additionnelles de WSE • Éditeur de configuration autonome • X.509 Certificate Wizard pour la gestion des certificats • De très nombreux exemples de mise en œuvre

  44. En route vers Indigo • WSE constitue la première implémentation Microsoft des spécifications WS-* • Indigo, composante de WinFX offrira une couverture complète de la pile WS-* • Framework unifié pour la conception d’applications orientées service au sein de la plate-forme Windows • « Introducing Indigo: An Early Look » • http://msdn.microsoft.com/library/en-us/dnlong/html/introindigov1-0.asp • Composante de la nouvelle interface de programmation WinFX introduite par Windows « Longhorn » • http://msdn.microsoft.com/Longhorn/understanding/pillars/indigo • Microsoft Pre-Release Software Code Named “Avalon” and “Indigo” Beta1 RC • http://www.microsoft.com/downloads/details.aspx?familyid=b789bc8d-4f25-4823-b6aa-c5edf432d0c1&displaylang=en

  45. Résumé de la session • WSE offre dès aujourd’hui de nombreux services de sécurité avancés avec un haut niveau d’abstraction • Authentification • Jetons de sécurité : Microsoft.Web.Services2.Security.SecurityToken • Couple utilisateur/mot de passe : UsernameToken • Jetons binaires : BinarySecurityToken • Certificat X509 : X509SecurityToken • Jeton Kerberos : KerberosToken, KerberosToken2 • SAML : Microsoft.Web.Services2.Security.SAML • Signature des messages • XML Signature : Microsoft.Web.Services2.Security.MessageSignature • Chiffrement des messages • XML Encryption : Microsoft.Web.Services2.Security.Cryptography • Gestion et définition de relation de confiance entre entités • WS-Trust : Microsoft.Web.Services2.Security • Contexte de sécurité entre deux services pour des échanges de plusieurs messages dans ce même contexte • WS-SecureConversation : Microsoft.Web.Services2.Security

  46. Pour plus d’informations • MSDN Web Services Developer Center • http://msdn.microsoft.com/webservices • « Web Services Enhancements (WSE) » • http://msdn.microsoft.com/webservices/building/wse/default.aspx • « WS-Security Drilldown in WSE 2.0 » • http://msdn.microsoft.com/library/en-us/dnwse/html/wssecdrill.asp • « Securing the Username Token with Web Services Enhancements 2.0 » • http://msdn.microsoft.com/library/en-us/dnwse/html/securusernametoken.asp • « Managing Security Context Tokens in a Web Farm» • http://msdn.microsoft.com/library/en-us/dnwebsrv/html/sctinfarm.asp • « Using Role-Based Security with Web Services Enhancements 2.0 » • http://msdn.microsoft.com/library/en-us/dnwse/html/wserolebasedsec.asp • « Web Service Enhancements 2.0 Support for WS-Policy » • http://msdn.microsoft.com/library/en-us/dnwse/html/wse2wspolicy.asp • Newsgroups • microsoft.public.framework.webservices • microsoft.public.framework.webservices.enhancements

  47. Pour plus d’informations • « Web Services Security Specifications Index Page » • http://msdn.microsoft.com/library/en-us/dnglobspec/html/wssecurspecindex.asp • « Web Services Protocol Workshops » • http://msdn.microsoft.com/webservices/community/workshops/default.aspx

  48. Microsoft France 18, avenue du Québec 91 957 Courtaboeuf Cedex www.microsoft.com/france 0 825 827 829 msfrance@microsoft.com

More Related