; Développement de Services Web sécurisés et interopérables avec WS
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Développement de Services Web sécurisés et interopérables avec WS

VIEWS: 12 PAGES: 48

  • pg 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
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

								
To top