Get documents about "Développement de Services Web sécurisés et interopérables avec WS
Document Sample
Développement de Services Web
sécurisés et interopérables avec
WS-* et WSE 2.0 SP3
Philippe Beraud
Consultant Principal
Microsoft France
La stratégie sécurité de Microsoft
Authentification,
Autorisation,
Excellence
Mise à jour Audit de
avancée l‟engineering
Isolation et Conseils,
résilience Outils,
Réponse
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é
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
BPEL4WS, Management
Composition
Composable
Security Reliable Transactions Service
Messaging Assurances
XSD, WSDL, UDDI, Policy, MetadataExchange Description
XML, SOAP, Addressing Messaging
HTTP, HTTPS, SMTP, etc. Transports
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
Composition des en-têtes
<S:Envelope … >
<S:Header>
<wsa:ReplyTo>
<wsa:Address>http://business456.com/User12</wsa:Address>
Addressing </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"
Security EncodingType=“wssec:Base64Binary">
dWJzY3JpYmVyLVBlc…..eFw0wMTEwMTAwMD
</wssec:BinarySecurityToken>
</wssec:Security>
<wsrm:Sequence>
Reliable <wsu:Identifier>http://fabrikam123.com/seq1234</wsu:Identifier>
Messaging <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>
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
Révision de la
Spécification Recueil des spécification, Organismes de
publiée feedbacks itération normalisation
Implémentation
« 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
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.
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
Filtres de sortie Filtres d‟entrée
Expéditeur
de Service Web
messages
SOAP
Filtres d‟entrée Filtres de sortie
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 not understood",
SoapException.MustUnderstandFaultCode);
}
}
}
}
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
WS-Security
WS-Federation
Policy
WS-Trust WS-Secure
Conversation
Standard de l‟OASIS aujourd‟hui
WS-Security largement supporté
Standard W3C, fondation des
SOAP services Web
WSE 2.0
Support de WS-Security, WS-Trust, WS-SecureConversation, WS-
SecurityPolicy
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
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
Émetteur Intermédiaire Intermédiaire Destinataire
…
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
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é Microsoft.Web.Services2.Security
.SecurityToken
Jeton Nom d‟utilisateur .UsernameToken
Signé .SecurityContextToken
Certificat X.509, ticket Kerberos, assertion [jetons de sécurité XML]
SAML, licence XrML, etc. …
.BinarySecurityToken
Preuve de possession .KerberosToken(2)
Clé secrète, mot de passe .X509SecurityToken
[jetons binaires personnalisés]
L‟authentification implique la vérification de …
cette connaissance
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*&
Py75c%bn&*)9|fDe^bDFaq#x
@:<CHDFHSD(**
zjFr@g5=&nmdFg$5knvMd’r
kvegMs”
Chiffrement
Fonction de asymétrique
hashage (SHA, MD5)
Clé
privée
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> 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
…
<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>
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é
Vérifier une signature numérique (destinataire)
Signature Condensé
numérique
Py75c%bn&*)9|fDe^
Jrf843kjfgf*£$&Hdif*7oUsd*& Déchiffrement
bDFaq#xzjFr@g5=&
@:<CHDFHSD(** asymétrique
nmdFg$5knvMd’rkve
gMs”
Clé publique
envoyée avec le
message
? == ?
Py75c%bn&*)9|fDe^
Même fonction de bDFaq#xzjFr@g5=&
hashage nmdFg$5knvMd’rkve
gMs”
Message
d‟origine
Signature d‟un message avec un certificat X.509
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
Clé destinataire
symétrique Clé chiffrée
générée
AyD5c%bné”*)
9|fDe^bDFaq#
Chiffrement
xzjFKr@67=&n
asymétrique
mdWzm5knvM
d’rkvegMs”
Chiffrement Py75c%bn&*)9|fDe^
symétrique bDFaq#xzjFr@g5=&
nmdFg$5knvMd’rkve
q#xzjFrgMs”
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=&n Déchiffrement
mdWzm5knvM asymétrique
d’rkvegMs”
Py75c%bn&*)9|fDe^
bDFaq#xzjFr@g5=& Déchiffrement
nmdFg$5knvMd’rkve symétrique
q#xzjFrgMs”
Chiffrement d‟un message avec un TGS Kerberos
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
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
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>
Demande d‟un nouveau jeton
Type de jeton 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
<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> Preuve de possession
Jeton de sécurité demandé
Support natif par WSE de ces opérations
Microsoft.Web.Services2.Security
Support également de la création d‟un STS personnalisé
Autres modèles proposés
Échange d‟un jeton de sécurité (wsse:ReqExchange)
Définit comment échanger un jeton pour un autre
1. Émission à destination du 2. Demande d‟échange du jeton Username
service C d‟un message signé au service de mappage A (STS)
1
avec un jeton Username (utilise wsse:ReqExchange)
T1
2 T1
A
B T2 3
3. Réponse du service de mappage A avec le
4 jeton X.509 associé au jeton Username
T2
4. Transfert au service C par le routeur B du
message signé avec le certificat X.509
C
T# Jeton de sécurité
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
1. Émission à destination du de validation que le jeton est
service B d‟un message avec suffisant
un jeton de sécurité
2 T# T# 3
2. Envoi par le service B du
jeton au service de validation A
?
(utilise wsse:ReqValidate)
B
1
T#
T# Jeton de sécurité
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
A confiance
1. Demande d‟un jeton au STS A
(utilise wsse:ReqIssue), jeton dans la T1
réponse C 1
wsse:RequestSecurityTokenResponse P1
2
T1 B
T# Jeton de sécurité 2. Émission d‟un message à destination
du service B avec le jeton
P# Preuve de possession
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 T1
jeton d‟identité C 1
P1 T1 2 T2
P2
3
T2
T# Jeton de sécurité
P# Preuve de possession
Topologies de confiance
Confiance indirecte
C fait confiance à B qui se porte garant de A qui répond du client
Directe - Échange d‟une clé Directe - Échange d‟une clé
symétrique ou d‟un certificat …Récursivité symétrique ou d‟un certificat
B
Indirecte – B garant de A et
A des identités de B C
Obtention d‟un T1
jeton d‟identité 1
P1
2
T# Jeton de sécurité
P# Preuve de possession
Topologies de confiance
Délégation
1 2 4
3 5
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
Politique de
fédération
Service Cible
T2
T2
C
T1 T1 P2
P1
Politique
d‟accès
Service d‟identité
Service de jetons de sécurité
Services de (le service de contrôle
pseudonymes et d‟accès fournit les jetons de
d‟attributs permission)
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-SecureConversation dé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
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>
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 />
Demande d„un SCT
Client SCT
SCT émis vers le client Service Web et
STS
SCT
Séries de messages signés avec le
SCT émis
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
Dérivation de clés
SCT
DK1 DK2
…
<wss:Security>
<wsc:SecurityContextToken wsu:Id='Session' >
<wsc:Identifier>
uuid:55281202-fdc8-460f-b154-745ab6029391
DK
</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>
… Jeton DerivedKey
</wse:Security>
…
Security Context Token
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
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
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>
Politique
</wsp:Policy>
</policies>
</policyDocument>
Mise en œuvre d‟une conversation sécurisée via
l‟expression de politiques
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
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
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
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
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
Microsoft France
18, avenue du Québec
91 957 Courtaboeuf Cedex
www.microsoft.com/france
0 825 827 829
msfrance@microsoft.com
