Document de réalisation Mise en œuvre d une infrastructure de sécurité dans une architecture orientée services

Transcription

1 Document de réalisation Mise en œuvre d une infrastructure de sécurité dans une architecture orientée services Version : 0.9 Auteurs : Olivier MALGRAS Anne-Sophie TRANCHET Encadrants : Olivier PERRIN Aymen BAOUAB 21 février 2011

2 Résumé Ce projet vise à séparer l aspect sécurité de l aspect fonctionnel d une application en externalisant les fonctionnalités de sécurité. Le nouveau modèle de système de sécurité orienté services sera composée de trois types de composants : des services métier, des méta-services de sécurité et d un service central qui fait l orchestration de ces méta-services suivant les besoins en terme de sécurité de chaque service métier. Ainsi, on peut gagner en flexibilité et agilité. Table des matières 1 Introduction 2 2 Politiques de sécurité Description des politiques d un service métier Description d une politique de sécurité Scénarios d utilisation 5 4 Réalisation Services métiers Clients Orchestrateur Lecture de la politique Éxécution de la politique Décision de l orchestrateur Méta-services de sécurité Authenticate Authorization Audit Différences avec le document de conception 10 6 Possibilités d améliorations 10 7 Ressenti sur le projet 10 Université Henri Poincaré 1 Master Informatique

3 1 Introduction Pour pouvoir répondre à des besoins toujours plus croissants d échange d informations et d interopérabilité, les organisations se tournent de plus en plus vers une architecture orientée services (SOA), qui offre l avantage de fournir des services réutilisables et reste très flexible grâce à un couplage flaible. Cependant, ces nouvelles méthodes d échanges entre clients, partenaires et fournisseurs impliquent un besoin de nouveaux mécanismes de sécurité permettant de sécuriser ces interactions. En effet, les services étant répartis et déployés sur des plateformes hétérogènes, ils sont alors accessibles par différents départements ou entreprises, faisant apparaître de nouveaux problèmes pour les développeurs et les architectes. La sécurité au niveau du transport ne suffisant plus, elle a du être implémantée au niveau applicatif, donnant ainsi naissance à de nouveaux standards qui ont résolu ces problèmes mais aussi remis en cause les avantages de la SOA comme le couplage faible et l agilité. Introduire la notion de méta-services de sécurité (des services assurant la sécurité des services métiers) dans les architectures SOA est une manière de résoudre ce compromis [1]. En séparant les fonctions de sécurité de la logique métier, l architecture gagne alors en flexibilité et en agilité tout en restant sécurisée. La suite de ce document va expliquer comment une telle architecture a été mise en place, ainsi que son fonctionnement. 2 Politiques de sécurité La modélisation des politiques de sécurité doit permettre à plusieurs services métiers d utiliser la même politique. Pour cela, nous nous sommes basés sur deux documents XML dont nous avons définit la struture grâce à XML Schema. Ainsi, en utilisant des fichiers, le couplage reste faible entre les différents web service. Par ailleurs, l architecture devient flexible puisque les politiques ne sont pas codées en dur. 2.1 Description des politiques d un service métier Le fichier business.xml fait la relation entre les services métiers et leur politique de sécurité. Une politique de sécurité est définie pour chaque service métier, mais elle peut être surchargée pour une méthode particulière. Ce fichier peut être décrit par le XML Schéma qui suit : <? xml version ="1.0" encoding =" UTF -8"? > <xs : schema xmlns : xs =" http :// www. w3. org /2001/ XMLSchema "> <xs : element name =" businesses " > <xs : sequence > <xs : element maxoccurs =" unbounded " ref =" business "/ > <xs : element name =" business " > <xs : sequence > <xs : element maxoccurs =" unbounded " ref =" method " / > <xs : attribute name =" name " use =" required " type =" xs : string "/ > <xs : attribute name =" policy " type =" xs : string " use =" required " /> <xs : element name =" method "> <xs : attribute name =" name " use =" required " type =" xs : string "/ > <xs : attribute name =" policy " type =" xs : string " /> </ xs : schema > Université Henri Poincaré 2 Master Informatique

4 Le listing suivant donne un exemple d un tel document : <? xml version ="1.0" encoding =" UTF -8"? > < businesses xmlns : xsi =' http :// www. w3. org /2001/ XMLSchema - instance ' xmlns : ns1 =' null ' xsi : nonamespaceschemalocation =" business. xsd " > < business name =" Mathematiques " policy =" Policy1 " > < method name =" add " /> < method name =" multiply " /> < method name =" substract " /> < method name =" divide " /> </ business > < business name =" Geographie " policy =" Policy2 " > < method name =" iscapitale " policy =" Policy1 " / > < method name =" getcapitale " / > </ business > < business name =" Traduction " policy =" Policy3 " > < method name =" frenchtoenglish " / > < method name =" englishtofrench " policy =" Policy4 " / > </ business > </ businesses > 2.2 Description d une politique de sécurité Une politique de sécurité est un ensemble de web services pouvant être appelés selon une séquence particulière. La structure flexible du langage XML permet de définir des politiques complexes telles que des appels de services en parallèle ou en séquence. Par ailleurs, il est aussi possible de spécifier un appel en parallèle qui prend fin dès qu un des services web appelé répond en utilisant l attribut xor="true". Dans le document XML, un service est défini par son nom et son adresse, comme le montre le XML Schéma qui suit : <? xml version ="1.0" encoding =" UTF -8"? > <xs : schema xmlns : xs =" http :// www. w3. org /2001/ XMLSchema "> <xs : element name =" policies " > <xs : sequence > <xs : element maxoccurs =" unbounded " ref =" policy "/ > <xs : element name =" policy "> <xs : choice > <xs : element ref =" parallel "/ > <xs : element ref =" sequence "/ > <xs : element ref =" service "/ > </ xs : choice > <xs : attribute name =" name " use =" required " type =" xs : string "/ > <xs : element name =" sequence " > <xs : sequence minoccurs ="0" maxoccurs =" unbounded " > <xs : choice > <xs : element ref =" parallel "/ > <xs : element ref =" sequence "/ > <xs : element ref =" service "/ > </ xs : choice > <xs : element name =" parallel " > Université Henri Poincaré 3 Master Informatique

5 <xs : sequence minoccurs ="0" maxoccurs =" unbounded " > <xs : choice > <xs : element ref =" parallel "/ > <xs : element ref =" sequence "/ > <xs : element ref =" service "/ > </ xs : choice > <xs : attribute name =" xor " type =" xs : boolean " default =" false "/ > <xs : element name =" service " > <xs : attribute name =" name " use =" required " type =" xs : string "/ > <xs : attribute name =" destination " use =" required " type =" xs : string "/ > </ xs : schema > Le listing suivant montre un exemple d un tel document : <? xml version ="1.0" encoding =" UTF -8"? > < policies xmlns : xsi =' http :// www. w3. org /2001/ XMLSchema - instance ' xmlns : ns1 =' null ' xsi : nonamespaceschemalocation =" policies. xsd " > < policy name =" Policy1 "> < parallel > < sequence > < service name =" Authenticate " destination =" http :// localhost :8080/ SecurityServices / AuthenticateService " / > < service name =" Authorization " destination =" http :// localhost :8080/ SecurityServices / AuthorizationService " / > </ sequence > < service name =" Audit " destination =" http :// localhost :8080/ SecurityServices / AuditService " / > < policy name =" Policy2 "> < parallel > < service name =" Authenticate " destination =" http :// localhost :8080/ SecurityServices / AuthenticateService " / > < service name =" Audit " destination =" http :// localhost :8080/ SecurityServices / AuditService " / > < policy name =" Policy3 "> < parallel > < service name =" Authorization " destination =" http :// localhost :8080/ SecurityServices / AuthorizationService " / > < service name =" Audit " destination =" http :// localhost :8080/ SecurityServices / AuditService " / > < policy name =" Policy4 "> < parallel > < sequence > < service name =" Authenticate " destination =" http :// localhost :8080/ SecurityServices / AuthenticateService " / > < parallel xor =" true "> < service name =" Authorization " destination =" http :// localhost :8080/ SecurityServices / AuthorizationService " / > < service name =" AuthorizationBis " destination =" http :// localhost :8080/ SecurityServices / AuthorizationBisService " / > </ sequence > < service name =" Audit " destination =" http :// localhost :8080/ SecurityServices / AuditService " / > Université Henri Poincaré 4 Master Informatique

6 < policy name =" Policy5 "> < service name =" Authorization " destination =" http :// localhost :8080/ SecurityServices / AuthorizationService " / > </ policies > 3 Scénarios d utilisation Nous avons créé deux scénarios. Le premier modélise le succès du traitement de la politique de sécurité : le message est routé vers le service métier demandé, et la réponse renvoyée au client (voir Figure 1). En cas d échec cependant, le service métier n est pas interrogé (voir Figure 2). FIGURE 1 Traitement du message en cas de succès FIGURE 2 Traitement du message en cas d échec 1. La requête du client au service métier est intercepté par l orchestrateur 2. L orchestrateur recherche la politique de sécurité associée au service métié demandé 3. L orchestrateur obtient la politique demandée 4. L orchestrateur appelle les méta-services de sécurité spécifiés dans la politique 5. Le service de sécurité renvoie une réponse positive 6. L orchestrateur transmet alors le message intercepté au service métier 7. L orchestrateur recoit la réponse du service métier 8. L orchestrateur transmet la réponse au client 1. La requête du client au service métier est intercepté par l orchestrateur 2. L orchestrateur recherche la politique de sécurité associée au service métié demandé 3. L orchestrateur obtient la politique demandée 4. L orchestrateur appelle les méta-services de sécurité spécifiés dans la politique 5. Le service de sécurité renvoie une réponse négative 6. L orchestrateur ne transmet pas le message intercepté au service métier La Figure 3 montre le diagramme de séquence de l orchestrateur en cas de succès de la politique de sécurité : La requête du client est interceptée par un Handler. Celui-ci transmet le message à l orchestrateur Orchestrateur. L orchestrateur parse la politique définie dans le fichier des politiques. Le Parser construit l objet Policy associé (la politique 4 du fichier définit dans la section 2.2 est prise comme exemple). L orchestrateur exécute cette politique, et l exécution est propagée dans l arbre de la politique. L orchestrateur détermine par la fonction getresponse le résultat de la politique de sécurité. De la même manière, la requêtes est propagée dans l arbre de la politique. La réponse étant positive, le Handler transmet le message au service métier demandé. La réponse du service métier est retournée au client. Université Henri Poincaré 5 Master Informatique

7 4 Réalisation FIGURE 3 Diagramme de séquence d une requête client à un service métier Afin de résoudre la problématique posée, nous avons implanté un orchestrateur dont le rôle est d intercepter les messages entrants et de les router vers des meta-services de sécurité suivant la politique avant de les re-diriger vers le service métier demandé. Contrètement, notre travail s est donc divisé en quatre projets distincts dans un environnement Netbeans/GlassFish : Des applications web BusinessServices, qui correspondent à un service métier. Une application java Client, qui appelle un service métier. Des applications web SecurityServices, qui représentent les méta-services de sécurité. Une application web Orchestrateur, qui analyse, détermine, puis route les messages destinés aux services métier. Dans la suite de ce document, nous donc allons détailler le rôle de chacun de ces acteurs et expliquer les interactions qui les relient. 4.1 Services métiers Nous avons réalisé trois services métiers pouvant être appelés par une application cliente. Mathematiques : Ce service web propose de réaliser des opérations simples telles que : add(int a, int b) substract(int a, int b) divide(int a, int b) Université Henri Poincaré 6 Master Informatique

8 multiply(int a, int b) Geographie : Ce web service propose deux méthodes : getcapitale(string pays) : donne la capitale d un pays donné iscapitale(string ville) : indique si la ville donnée est une capitale Traduction : Ce web service propose la traduction entre le français et l anglais : frenchtoenglish(string word) englishtofrench(string word) Nous avons défini une politique de sécurité pour chacun d entre eux (voir la section 2 page 2). Par ailleurs, nous avons lié à chacun de ces services web un SOAPHandler, une classe permettant d accéder à un message (entrant ou sortant) et son contexte avant que celui-ci soit traité par le service métier. Le SOAPHandler décide si le traitement doit continuer pour le message donné ou non. Ici, le MessageHandler a pour rôle d intercepter uniquement les messages entrants à destination des BusinessServices. Il envoie le message à l Orchestrateur. Celui-ci exécutera la politique associée à la méthode appelée, et décidera alors de la suite du traitement : en cas de succès, le message capturé est transité vers le service métier demandé, sinon, il est stoppé (voir la section 4.3 page 7). 4.2 Clients Pour chacun des scénarios (voir la section 3 page 5), nous avons créé un client qui appelle un service métier différent afin d illustrer les différents cas possibles. Nous avons cherché un moyen permettant à l orchestrateur de connaitre les informations nécessaires à l éxécution de la politique de sécurité d un service métier donné (identifiant, mot de passe...). En effet, le client connait uniquement le service métier, mais ne connait pas l orchestrateur, il ne peut donc pas les lui envoyer directement. Nous avons donc décidé que le client enverrait ces informations au service métier dans le même message que la requête. Ainsi, l Orchestrateur pourra extraire les données et les utiliser pour l exécution de la politique. Pour cela, nous avons donc modifié le fichier WSDL de chacun des services métiers pour y ajouter des paramètres. Par exemple, le service métier Traduction propose une méthode englishtofrench. La politique de sécurité associée à cette méthode appelle les méta-services de sécurité Authenticate, Authorization, AuthorizationBis et Audit. Elle a donc besoin d informations telles que : un identifiant et un mot de passe (pour le service Authenticate), ainsi qu un code (pour Authorization et AuthorizationBis). Nous avons donc modifié le fichier descripteur du WSDL du service métier Traduction (soit le fichier TraductionService_schema1.xsd) ainsi :... <xs : complextype name =" englishtofrench " > <xs : sequence > <xs : element name =" word " type =" xs : string " minoccurs ="0"/ >... est devenu... <xs : complextype name =" englishtofrench " > <xs : sequence > <xs : element name =" word " type =" xs : string " minoccurs ="0"/ > <xs : element name =" login " type =" xs : string " minoccurs ="0" / > <xs : element name =" password " type =" xs : string " minoccurs ="0" / > <xs : element name =" code " type =" xs : string " minoccurs ="0" / > Orchestrateur L orchestrateur est l entité principale du projet (voir le diagramme de classe Figure 4). À la réception d une requête pour un service métier, il va d abord chercher la politique de sécurité correspondante, avant de l exécuter puis va déterminer si le message peut continuer d être traité ou non. Université Henri Poincaré 7 Master Informatique

9 FIGURE 4 Diagramme de classe de l orchestrateur Lecture de la politique L Orchestrateur doit d abord extraire du message SOAP intercepté le nom de la méthode du service métier appelé. Un Parser analyse alors le fichier Business.xml afin d y trouver la politique associée. À partir du code XML, l Orchestrateur construit ensuite une politique Policy. Une politique est un Thread que l on peut assimiler à un arbre et dont les noeuds peuvent être du type : Sequence : thread qui exécute en séquence une liste de threads (noeuds enfants). Parallel : thread qui exécute en parallèle une liste de threads (noeuds enfants). Xor : thread qui exécute en parallèle une liste de threads (noeuds enfants). Cependant, à la différence de Parallel, quand un thread est terminé, les autres sont alors interrompus. Service : thread qui appelle un service donné (feuilles de l arbre). Exemple : L extrait suivant montre une politique de sécurité modélisée en XML. < policy name =" Policy4 "> < parallel > < sequence > < service name =" Authenticate " / > < parallel xor =" true "> < service name =" Authorization " destination =" http :// localhost :8080/ SecurityServices / AuthorizationService " / > < service name =" AuthorizationBis " destination =" http :// localhost :8080/ SecurityServices / AuthorizationBisService " / > </ sequence > < service name =" Audit " destination =" http :// localhost :8080/ SecurityServices / AuditService " / > Pour cette politique, l Orchestrateur créera un objet Policy dont la représentation tostring() est : Parallel (Sequence (Authenticate; Xor (Authorization; AuthorizationBis; ); ); Audit; ); Éxécution de la politique Une fois que l orchestrateur a construit la politique Policy à partir du fichier XML, il peut l exécuter. L exécution de la politique va être diffusée jusqu aux feuilles de l arbre où a lieu l appel des méta-services de sécurité. Pour ces appels, l orchestrateur doit extraire du SOAPMessage intercepté les paramètres nécessaires que lui a transmis le client (voir la section 4.2 page 7). Université Henri Poincaré 8 Master Informatique

10 Exemple : Trace d exécution de la politique précédente INFO : Begin Parallel INFO : Begin Sequence INFO : Begin calling service Audit INFO : Begin calling service Authenticate INFO : End calling service Audit INFO : End calling service Authenticate INFO : Begin Xor INFO : Begin calling service Authorization INFO : Begin calling service AuthorizationBis INFO : End calling service Authorization INFO : Interrupting active threads in Xor INFO : Forced interruption of AuthorizationBis Décision de l orchestrateur Une fois la politique exécutée, l orchestrateur interpréte les différentes réponses des méta-services de sécurité. Il vérifie notamment que la réponse ne contient pas un élément SOAP Fault. À partir du moment où un service renvoie une erreur ou une réponse négative, l orchestrateur considère alors que l exécution complète de la requête a échoué. Il interrompt donc le traitement du message original intercepté en ne le transmettant pas au service métier demandé (voir Figure 2). 4.4 Méta-services de sécurité Nous avons réalisé trois services de sécurités fictifs nous permettant de tester le projet. Voici les différents types de services de sécurité que nous pouvons trouver : Authenticate Ce service consiste à vérifier que l entité qui s est identifiée est bien qui elle prétend être. Le client doit donc fournir une identité et la prouver. On utilise généralement une paire Identifiant / Mot de passe. Dans notre cas, le service Authenticate comprends une méthode authenticate(string login, String password). Il retourne vrai si le mot de passe qu on lui donne a un nombre de lettres pair Authorization Ce service consiste à contrôler l accès aux données afin d empécher la divulgation non autorisée de l information. Pour cela, elle repose sur l identification et l authentification des utilisateurs et utilise habituellement une liste de contrôle d accès (ACL ) pour attribuer et vérifier les droits de chaque utilisateur. Ici, nous avons en fait créé deux services factices : Authorization et AuthorizationBis. Ces deux services ont une méthode authorize(string code) qui renvoie vrai après un temps d exécution aléatoire (entre 0 et 1000 ms) si ce code contient entre 4 et 8 caractères. La variation de temps nous permet de simuler des latences, et plus particulièrement de tester le cas d une politique XOR Audit Ce service permet de surveiller les accès en gardant une trace de toutes les actions effectuées. Les fichiers de log obtenus peuvent alors servir à détecter des malveillants ou analyser des problèmes rencontrés. Ce service permet aussi de se prémunir contre la non-répudiation : on sait qui a fait quoi et quand. Dans notre cas, le service de sécurité Audit sauvegarde chaque opération effectuée dans une base de données. Il est destiné à être appelé en parallèle des autres afin d avoir une trace de l éxécution après coup. Nous avons utilisé la base de données embarquée Apache Derby pour persister les données. Université Henri Poincaré 9 Master Informatique

11 audit_id date commentaire log_level :21:55 ceci est un commentaire INFO :42:07 Warning Audit WARNING Le tableau suivant montre un exemple d entrée dans la base de données d audit : audit_id : identifiant unique calculé à partir du hashcode de la date à laquelle l audit a été fait. date : date d appel du service Audit. commentaire : champ libre laissé pour les développeurs pouvant être vide. log_level : niveau d importance de l entrée. Les niveaux disponibles (sous forme de variables statiques accessibles aux développeurs) sont : INFO, WARNING, et ERROR. Ici, l orchestrateur remplit le champ commentaire par le nom du service métier originalement appelé. 5 Différences avec le document de conception Durant la réalisation, nous nous sommes parfois écartés du document de conception notamment pour des raisons de contraintes de temps. Ainsi, nous avons créé une instance d orchestrateur par message intercepté, plutôt qu une seule instance de l orchestrateur. Cela nous a notamment permis d éviter de gérer le conversationid, et de sauvegarder les messages entrants. Nous avons donc dû procéder autrement pour transmettre les paramètres des méta-services de sécurité à l orchestrateur (voir la section 4.2 page 7). 6 Possibilités d améliorations Une grosse amélioration serait de créér un programme capable d adapter les fichiers de descriptions de services automatiquement en fonction de la politique, afin de ne pas avoir à la faire à la main, comme dans la section 4.2. Une autre amélioration possible serait de mieux gérer les cas d échecs du déroulement d une politique de sécurité. Actuellement, le fonctionnement de SOAPHandler fait qu en cas de succès le message continue son chemin vers le service métier, mais en cas d échec il est renvoyé au client. Ce comportement est peu idéal et cause une erreur d exécution chez le client qui s attend à recevoir une réponse et pas le message qu il a reçu. Il serait plus intéressant de renvoyer un message Fault au client. 7 Ressenti sur le projet Nous tenons à remercier tout spécialement Olivier Perrin et Aymen Baouab pour leur disponibilité et leur pédagogie. Au travers de ce projet, ils nous ont appris des méthodes de travail et nous en sommes reconnaissants. Ce projet nous a permis de compléter ce que nous avons pu voir en cours, tout en découvrant de nouveaux concepts aussi bien au niveau de la conception que de la programmation. Nous avons d ailleurs réalisé avoir des lacunes dans la gestion de projet, et tout particulièrement lors de la réalisation du document de conception, nous faisant alors perdre du temps lors de la réalisation. Références [1] Architectures orientés services et intégration de méta-services de sécurité, Aymen BAOUAB, 2009 Université Henri Poincaré 10 Master Informatique