L'Architecture Orientée Services et J2EE. Ahmed ALAMI's WEBLOG.

je vous invite à consulter le site suivant : http://www.soa-architect.net, vous y trouverez d'avantage d'informations sur la SOA et ses sattelites.

Les facteurs de réussite d’une démarche SOA peuvent être résumés dans les points ci-dessous :

• SOA est une démarche collective qui fait intervenir des chaînes de responsabilités toutes nécessaires pour mener à bon terme cette dernière. Un découpage des équipes ; donc des maillons des chaînes doit être réfléchi, optimisé et contrôlé de manière efficace et flexible. Ce découpage est nécessaire à plusieurs niveaux :
• • Les équipes à vocation métier,
  • Les équipes à vocation technique,
  • Les équipes de contrôle du cycle de vie des services.
• Utiliser le modèle d’architecture de référence comme base d’implémentation. Il existe plusieurs fondations et communautés travaillant sur les principes généraux et fondamentaux de la SOA dont il faut tirer parti sans se lancer dans une démarche interne qui des fois est très coûteuse.
• Toujours remettre en question la démarche adoptée en :
• • contrôlant le cycle de vie
  • mesurant le retour sur investissement
• La gouvernance SOA est importante pour mener à bon terme les projets SOA. La gouvernance affecte des facultés de décision aux maillons des chaînes de responsabilité tout en proposant des méthodes de contrôle et de mesure de la validité de ces décisions. La gouvernance SOA définit les principes, les processus, les moyens et les rôles nécessaires pour gérer, utiliser et suivre le changement d’une SOA.

1. Un service consiste en un ensemble de fonctionnalités fournis par une entité dans le but d’être utilisées par d’autres entités.
2. Les services sont conceptuellement autonomes (autosuffisants) et opaque (indépendant des technologies d’accès aux ressources).
3. Aucune distinction en terme d’architecture ne devrait être faite entre les services consommés dans le cadre d’un processus et les autres consommés directement.
4. Tout service logique a une description canonique.
5. La description d’un service est composée de trois parties logiques :
   • Un modèle de données.
   • Règles et obligations exigées pour les consommateurs et les fournisseurs du service.
   • Contrats qui gouverne l’utilisation du service.
6. Une règle de sécurité peut nécessiter l’utilisation d’un système de sécurité.
7. Une politique de sécurité inexistante est considérée comme une règle de sécurité.
8. Les consommateurs d’un service doivent disposer de sa description afin de pourvoir interagir avec ce dernier.

WS-Federation propose une généralisation des spécifications de WS-Trust en proposant des mécanismes de fédération et de gestion d’identité. La fédération d’identité consiste en la mise en place d’un système de SSOn (Single Sign On), permettant de propager des identités entre les différents participants à un service et d’un système SSOff (Single Sign Off ou Global Logout) qui permet de mettre fin à toutes les sessions ouvertes par les participants de la transaction. WS-Federation permet entre autres d’effectuer du profiling d’utilisateurs.

WS-Federation définit la manière avec laquelle les relations de confiance sont établies à travers des domaines de sécurité.

Le modèle de sécurité basé sur WS-Federation permet de définir un pseudonyme associé à chaque entité. Ceci est effectué via deux services, un AS (Attribute Service) et un PS (Pseudonym Service). Pour la définition de ces deux services, se référer à la terminologie relative à la sécurité SOA.

Parmi les notions utilisées par WS-Federation, on trouve :

• Security Token Service (STS)
• Identity Provider (IP)

L’approche de la fédération permet de supporter les différentes topologies de confiance initiées par WS-Trust en citant quelques unes : Direct Trust, Indirect Trust, Delegation.

Direct Trust

Le flux dans un contexte direct est le suivant :

1. L’infrastructure Client récupère le fichier de policy associé au service à demander.
2. Une fois le fichier de policy récupéré, l’infrastructure client demande un jeton à son STS.
3. Une fois le jeton récupéré, un appel est fait au STS de l’infrastructure du service afin de récupérer un jeton valide pour finalement appeler le service.

Ce modèle est simple à mettre en œuvre. Cependant la politique de fédération dépend du type du client appelant. Deux types ou profiles sont différenciés, Un profile Actif (Client SOAP capable de lire un WSDL et comprendre le résultat de retour d’un service Web), un profile Passif (Navigateur Web classique).

L’une des problématiques qui restent à gérer en utilisant WS-Federation est celle de la protection de l’identité en assurant l’anonymat de l’identité.

L’avantage le plus intéressant qui est du à l’utilisation de WS-Federation consiste en la possibilité de s’intégrer au différentes infrastructures qui fournissent les informations sur les identités et qui sont capables de comprendre les différents formats de jetons de sécurité ainsi que les annuaires de services et les fabriques d’attributs d’identité.

Profile

Un profile est un document qui décrit le modèle de sécurité associé à un type ou à une classe de client. Le client peut être par exemple, un navigateur classique (appelé client passif) capable d’envoyer des requêtes http classiques ou un client actif capable d’envoyer des requêtes basées sur SOAP et de comprendre le résultat.

Claim (Réclamation)

Elle spécifie une déclaration ou une revendication faite par une entité concernant par exemple, un nom, une identité, une clef, un privilège, un attribut, un certificat …

Jeton de sécurité

Un jeton de sécurité correspond à un ensemble de claims.

Jeton de sécurité signé

Une jeton de sécurité signé est un jeton de sécurité certifié et crypté par une autorité spécifique (par exemple un certificat X.509 ou un ticket Kerberos)

Signature

Une signature est valeur calculée via un algorithme cryptographique d’une donnée. La signature permet de vérifier que les données n’ont pas été altérées après envoi du signataire.

STS (Security Token Service)

Un STS est un service Web capable de délivrer des jetons de sécurité (utilisé dans le modèle de sécurité avec WS-Trust). Il permet entre autres d’installer une communication de confiance entre des entités ou fournisseurs de services.

Principal

Toute identité utilisatrice peut être appliquée à une personne, machine, service web, etc.

AS (Attribute Service)

Un AS est un service Web capable de maintenir des informations (attributs) de principals en relation avec un domaine de confiance.

Realm/Domain

Un relam ou domaine représente une unité de sécurité administrable et capable de fournir des informations afin d’établir une relation de confiance entre deux ou plusieurs fournisseurs de services.

Trust (Confiance)

La confiance signifie qu’une entité peut se baser ou avoir confiance en une autre entité pour exécuter un ensemble d’opérations relatives à la sécurité.

Trust Domain (Domaine de confiance)

Un domaine de confiance est un contexte sécurisé et administrable ouvert entre un client et un fournisseur de service leur permettant d’être d’accord si les credentials échangées satisfassent les contraintes de sécurité de chacun.

Fédération

Une fédération consiste en une collection de realms/domaines qui ont établi une relation de confiance. La confiance peut intervenir au niveau de l’authentification ou de l’autorisation.

Fournisseur d’identité (Identity Provider)

Un fournisseur d’identité est une entité qui fait foie de service d’authentification aux utilisateurs de service et aussi aux services. Cette entité est capable de fournir des informations de sécurité sur les profiles demandées.

Mapping d’identité (Identity Mapping)

Cette opération consiste à définir une correspondance entre les propriétés associées à une identité entre deux fournisseurs de services ou participant à une chaîne de service web.

Single Sign On (SSO)

Le Signle Sign On est une solution à la problématique d’authentification d’un client dont la transaction appelée met en jeu plusieurs participants. Ce qui évite une phase d’authentification pour chaque fournisseur de service à chaque échange.

Single Sign Off ou Global Logout

Solution permettant de finaliser toutes les sessions ouvertes pour un client donné au sein des fournisseurs de services particpant à la transaction en cours.

Dans ce chapitre on va décrire un modèle de sécurité faisant intervenir les concepts de l’architecture orientée services, des spécifications WS-* et plus particulièrement WS-Security et la plate-forme J2EE.

La sécurité des services Web fait partie intégrante de la stack des spécifications WS-*.

Plusieurs standards lui sont associés. Les plus importants et les plus stables en terme de spécifications sont cités ci-dessous. Pour plus de détails concernant chaque spécification se reporter aux autres livres blancs sur la sécurité niveau données et messages.

Afin de comprendre l’interaction entre les participants à une transaction basée sur un service Web, il conviendrait de dresser la cinématique relative au flux de messages transportés entre l’infrastructure Client et l’infrastructure Serveur. Ensuite seront associées les différentes spécifications, standards et outils associés à chaque étape de ce flux.

Les schémas mettent en jeu un client et un serveur, la cinématique peut être adaptée dans le cas d’un échange avec un intermédiaire ou plusieurs.

La cinématique ci-dessous ne fait pas référence au contexte de sécurité partagé et constitue un modèle dont la topologie reste simple et compréhensible.

Ci-dessous Le flux des messages

1. Le code client initialise l’environnement relatif à l’infrastructure client en récupérant des informations sur le proxy de connexion et soumet la requête désirée. Dans le contexte de la plate-forme J2EE, le client utiliserait l’api Jax-RPC.
2. Une fois l’infrastructure client alertée de la requête du client, cette dernière associe un processus à cette requête. Le processus correspond à un ensemble de services coordonnés et orchestrés. Pour chaque service, l’infrastructure client se connecte à l’annuaire des services et récupère la définition liée au service en téléchargeant le fichier WSDL représentatif.
3. une fois le fichier WSDL récupéré, l’infrastructure client se connecte à l’annuaire de policy (politique ou stratégies) puis récupérer les stratégies associées à l’appel du service Web. Ces stratégies peuvent contenir des exigences en terme de sécurité.
4. L’infrastructure Client Interprète les stratégies de sécurité de l’invocation du service, par exemple savoir quelle partie du message doit être cryptée. En ayant le fichier de policy, l’infrastructure client identifie le type de jetons de sécurité attendus par l’infrastructure serveur.
5. L’infrastructure client demande au client de spécifier son identité afin de l’autoriser.
6. Une fois l’identité du client validée, un jeton de sécurité est récupère via le fournisseur d’identité.
7. Lors de cette étape, le client constitue le message de la requête SOAP. Il signe le message, crypte les parties sensibles et associe le jeton de sécurité à l’entête du message. Une fois le message sécurisé créé il est enfin envoyé à l’infrastructure du serveur.
8. L’infrastructure serveur s’occupe de valider le message de le décrypter et de vérifier le jeton de sécurité afin d’installer une relation de confiance. Une fois la confiance établie, le service final est invoqué.

Ci-dessous sont associés à chaque étape de cette des technologies, standards et spécifications.

WS-SecurityPolicy fait partie des spécifications relatives à WS-Policy.

WS-Policy se base sur un modèle de programmation déclarative qui permet d’attacher des pré-requis, des stratégies et des paramétrages nécessaires à des services Web. WS-SecurityPolicy spécifie des stratégies de sécurité, il définit un ensemble de types d’assertions, elles sont décrites ci-dessous :

WS-SecurityPolicy permet de découpler le code de l’infrastructure de sécurité, il permet donc des stratégies de sécurité extensibles et modifiables.

Il permet aussi de réduire le code relatif à la sécurité, ce qui ajoute une flexibilité dans la gestion de la sécurité des services Web.

WS-Security est une spécification conçue afin d’être utilisé par les versions SOAP 1.1 et 1.2 de SOAP. WS-Securitypolicy peut être utilisée pour développer des applications basées sur des assertions XML associées à un endpoint d’un service Web ou un document WSDL. Elle définit un cadre pour préciser les impératifs et les stratégies d’un service Web. Elle permet aussi d’associer à un service Web des renseignements de sécurité et de routage.

La lecture des assertions WS-SecurityPolicy informe le consommateur du service sur les dispositifs de sécurité qui sont requis par le fournisseur de service, comme le format du jeton d’authentification, la nécessité de signature du message etc.

L’exemple ci-dessous précise que le fournisseur exige une intégrité du message en utilisant un algorithme de signature XML et requiert une authentification utilisant les jetons de type X.509.

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy" xmlns:wssp="http://schemas.xmlsoap.org/ws/2002/12/secext"> <wsp:All> <wssp:Integrity wsp:Usage="wsp:Required"> <wssp:Algorithm Type="wssp:AlgSignature" URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> </wssp:Integrity> <wssp:SecurityToken> <wssp:TokenType>wsse:X509v3</wssp:TokenType> </wssp:SecurityToken> </wsp:All> </wsp:Policy>

La sécurité niveau transport fournit la confidentialité et l’intégrité des données transportées entre deux applications, mais aussi l’authentification de ces dernières. Le modèle de sécurité le plus utilisé dans le monde de l’Internet est la combinaison entre SSL et HTTP Basic Authentication. HTTP Basic Authentication nécessite une user Id et un mot de passe et SSL étant un protocole sécurisé de transmission de données via des méthodes de cryptage.

Le protocole SSL (Secure Socket Layer) est une solution de sécurité transparente aux applications qui sont basées sur le protocole TCP. Il reste un protocole générique, mais ne couvre pas tous les besoins d’applications telles que des applications de paiement par Internet. Il est important de signaler que le protocole SSL avait pour ambition première de sécuriser le protocole http.

La sécurité niveau transport peut être gérée via les standards suivants :

• SSL (Secure Socket Layer) : repose sur un procédé de cryptographie par clef publique afin de garantir la sécurité de la transmission de données sur Internet Le système SSL est indépendant du protocole utilisé.
• Au milieu de l'année 2001, le brevet de SSL appartenant jusqu'alors à Netscape a été racheté par l'IETF (Internet Engineering Task Force) et a été rebaptisé pour l'occasion TLS (Transport Layer Security).

SSL/TLS offrent des dispositifs de sécurité dont l’authentification, l’intégrité et la confidentialité des données. SSL/TLS assurent la sécurité de session point-à-point.

• IPSec est un protocole destiné à fournir différents services de sécurité. Il propose ainsi plusieurs choix et options qui lui permettent de répondre de façon adaptée aux besoins des entreprises, nomades, extranets, particuliers, etc... Néanmoins, son intérêt principal reste sans conteste son mode dit de tunneling, c'est-à-dire d'encapsulation d'IP qui lui permet entre autres choses de créer des réseaux privés virtuels ou VPN. Cette technologie à pour but d'établir une communication sécurisée (le tunnel) entre des entités éloignées, séparées par un réseau non sécurisé voir public comme Internet, et ce de manière quasi-transparente si on le désire.

Malgré le fait que les protocoles décrits ci-dessous sont adaptés aux applications basées sur le protocole TCP ou HTPP. Ils restent limités et insuffisants dans un contexte de communication basé sur les services web. En effet :

• les messages SOAP peuvent inclure plusieurs intermédiaires, ce qui nécessite un contexte de sécurité partagé et interopérable entre les différentes parties mises en jeu, ce qui n’est pas le cas de SSL vu qu’il suppose que seules deux parties sont concernées par une transmission de données.
• SSL s’occupe de crypter le message en totalité. Dans le cas d’une transaction mettant en jeu plusieurs participants, il se pourrait que plusieurs parties des données transmises soient cryptés séparément et différemment pour que chaque participant décrypte la partie le concernant.

La sécurité niveau transport peut être considérée comme optionnelle et peut être remplacée par la sécurité niveau messages.

Dans une architecture basique un Client envoie un message SOAP contenant une entête WS-Security. Le but de la Gateway (passerelle) et du STS est d'assurer que le service reçoit un message sécurisé avec des jetons valides et compréhensibles. La gateway et le STS utilisent des messages WS-Trust pour permettre un traitement interopérable entre le client et le service demandé.

La gateway se trouve en frontal des services. Les clients peuvent attaquer directement la gateway qui se charge après de renvoyer au bon service, pour cela l'adresse du service dans le fichier WSDL doit pointer directement sur l'adresse de la gateway. Le client peut aussi attaquer le service directement, dans ce cas la gateway est déclenchée à l'appel du service afin de traiter les jetons de sécurité. Le traitement exécuté par le service n'est effectué que si les jetons sont validés et échangés.

La gateway doit être capable de déduire les préférences en terme de jetons de sécurité exigés par les services appelés.

L'appel du STS effectué par la gateway est sécurisé, il convient qu'il soit effectué au niveau de la couche transport.

Afin de comprendre le but de cette architecture, prenons l'exemple ci-dessous :

1. Le client ne comprend que les certificats X.509. Il passe par un CA (Certificate Authority) afin de signer ses messages pour assurer l'intégrité des messages et prouver leur provenance.
2. Le service ne comprend que les assertions SAML.
3. Le service n'a aucun moyen lui permettant d'établir une relation de confiance avec le client.
4. Le client n'est pas supposé connaître le type de jetons attendus par le service.

5. La communication entre le client et le service se déroule en quatre étapes.

   1. Le client SOAP envoie la requête suivante à la gateway ou au service.

        1   2  
         3  
         4           
         5    sdfOIDFKLSoidefsdflk … 6         
         7  
         8            
         9             
         10           
         11           
        akjsdflaksf
         12      
         13             
         14           
         15        
         16  
         17  
         18  
         19        
         20  
         21  
           

      La gateway intercepte le message et déduit que le client utilise des certificats X.509, sachant que les services s'attendent à recevoir des assertions SAML. Elle renvoie ce message au STS qui se chargera de mapper une assertion SAML au certificat X.509.

   2. L'échange des jetons de sécurité doit se faire sans perte d'informations sur l'identité du client, ceci peut être considéré comme une information déterminante dans le traitement effectué par le service. La gateway envoie donc la requête suivante au STS :

        1  
         2  
         3   
         4      5   
         6  
         7  
         8      
         9       SAML
         10        ReqExchange
         11     
         12             
         17                
         20                
         23                  
         24                  Client
         25                    
         26                 
         27                        urn:oasis:names:tc:SAML:1.0:cm:sender-vouches 28                        
         29                     
         30                  
         31               
         32              
                 <-- calculated by STS --> 
         33              
         34         
         35   
         36  
         37  
           

      Le STS retourne un élément RequestedSecurityToken [lignes 13-34]. La signature du STS est définie dans l'élément Signature [Ligne 32]. Le STS associe aussi un identifiant client à la réponse [Ligne 24]. Ceci présume que le STS a accès au référentiel clients.

   3. La passerelle reçoit le message du STS, extrait l'assertion SAML à partir de ce dernier et recrée une nouvelle version du message enoyé par le client. Ci-dessous un exemple :

        1  
         2  
         3  
         4        
         8                
         11                
         14                  
         15                  
                                 Client
         16                   
         17                 
         18                        urn:oasis:names:tc:SAML:1.0:cm:sender-vouches 19                        
         20                     
         21                  
         22               
         23              
                      <-- calculated by STS -->
         
         24      
         25  
         26  
         27  
         28       
         29  
         30  
           

      La passerelle a inséré l'assertion SAML dans l'entête de la requête SOAP [Lignes 4-24]. L'élément ConfirmationMethod [Ligne 17] permet au service d'authentifier la provenance du message. Il est intéressant de noter que la signature du STS est persistante, ce qui installe indirectement une relation de confiance entre le service et le client d'origine.

      

Il existe plusieurs formats des jetons de sécurité (Certificats X 509, Ticket Kerberos, Assertions SAML, politiques XACML, etc), ceci nécessite de la part des acteurs d’un service Web de comprendre ces différents jetons. Par conséquent, il n’existe aucune garantie qu’un récepteur de message SOAP puisse comprendre un jeton de sécurité envoyé par un client d’un service web. Un nouveau problème se pose, celui de l’interopérabilité en terme de sécurité. Comment sera mappé un jeton de sécurité reçu de la part d’un intervenant dans le service Web ? Par quel jeton sera-t-il remplacé ? Quel type de jeton renvoyer pour qu’il soit compréhensible par le client ?

Pour repondre à ce besoin d’interopérabilté et pour installer une confiance entre les intervenants dans le service web, deux specifications ont été introduites : WS-Trust et WS-SecurityPolicy. On se concentrera sur la premiere specification : WS-Trust.

Introduction à WS-Trust :

WS-Trust est utilisé afin d’assurer l’interopérabilité entre les multiples jetons de sécurité qui peuvent être transportés dans un message sécurisé via WS-Security. Cette interopérabilité ne se place pas qu’au niveau syntaxique. Par exemple, un service peut accepter des jetons Kerberos mais peut ne pas comprendre des jetons générés par des centres de distribution arbitraires.

En général, un service qui reçoit un message SOAP de type WS-Security doit gérer trois problématiques principales :

• Le format : le format peut être incompréhensible.
• La confiance : Le récepteur peut ne pas établir une chaîne de confiance.
• L’espace de nommage : Le récepteur peut avoir une syntaxe différente de celle de l’émetteur.

WS-Trust resout ces problématiques potentielles en établissant un système d’échange basé sur un protocole request/response. Le client envoie une RequestSecurityToken au STS (Security Token Service), la requête comporte le jeton de sécurité utilisé pour l’échange. Le STS répond avec une RequestSecurityTokenResponse contenant le nouveau jeton.

Les trois problématiques sont donc gérées comme suit :

• Le format : Le STS renvoie un jeton totalement compréhensible par le service récepteur.
• La confiance : Le jeton retourné a été signé par le STS ; le service récepteur s’attend à avoir en retour un jeton valide afin d’établir une relation de confiance.
• L’espace de nommage : La syntaxe correspond à celle attendue par le récepteur. En plus de l’échange des jetons de sécurité, WS-Trust permet de demander de jetons de sécurité et de les valider.

Ci-dessous, une figure représentant les différents échanges effectués entre le STS et le client du service sécurisé.