Laboratoire SIS - Equipe Informatique Université de Toulon et du Var 83957 La Garde, France {gabillon,bruno}@univ-tln.fr RESUME : L objectif de cet article est de définir un modèle de sécurité permettant de contrôler les accès aux documents XML. Le modèle proposé permet une expression simple et précise de la politique de sécurité. Un document XML est représenté par un arbre dont les nœuds sont de différents types (élément, attribut, texte, commentaire, etc.). Dans notre modèle, le nœud est le plus petit objet auquel une autorisation peut être associée. Cela signifie qu une règle d autorisation peut permettre ou interdire l accès à un simple nœud (par exemple, un attribut précis) ou à un ensemble de nœuds (par exemple à tous les éléments contenus dans un élément donné). Les règles qui définissent les autorisations relatives à un document XML particulier sont définies dans un document indépendant : une feuille d autorisation, appelée feuille XAS (XML Authorisation Sheet). Lors d une étape préliminaire, la feuille XAS est traduite une bonne fois pour toutes en une feuille de style XSLT. Par la suite, à chaque fois qu un utilisateur demande à accéder au document XML, un processeur XSLT applique la feuille de style XSLT ainsi obtenue et fournit à l utilisateur une vue du document original compatible avec ses droits. MOTS-CLEFS : XML, Sécurité, Xpath, contrôles d accès
1. Introduction XML est un langage de description de document recommandé par le World Wide Web Consortium (W3C) [1]. XML est devenu le langage standard utilisé pour décrire les informations publiées sur Internet. Or, Internet est un réseau public, les applications qui y sont développées nécessitent donc des mécanismes de sécurité destinés à prévenir les accès non autorisés à des données sensibles. Des ébauches de standards concernant la signature électronique de documents XML et le cryptage de fragments de documents ont déjà été proposées [2]. Néanmoins, un modèle de contrôles d accès pour documents XML reste à définir, bien que quelques propositions aient déjà été faites [3,4,5]. Dans cet article, notre objectif est de définir un modèle de sécurité permettant le contrôler les accès à des documents XML. Dans [6], nous avons présenté les bases de notre proposition. Nous présentons ici le modèle complet. Un document XML est représenté par un arbre dont les nœuds peuvent être de différents types : élément, attribut, texte ou commentaire. Le plus petit fragment de document pouvant être protégé est le nœud. Ceci signifie qu une règle d autorisation peut accorder ou refuser l accès à un simple nœud (par exemple un attribut) ou à un groupe de nœuds (tous les textes d une section). La sémantique d une autorisation est unique quel que soit le type de nœud concerné. Nous montrons que notre modèle permet d exprimer simplement des politiques de sécurité complexes opérant à un niveau de granularité très fin et capable de gérer des leurres. Une implantation de notre modèle est accessible en ligne à l adresse : http://sis.univtln.fr/xml-secu. Notre prototype s appuie sur XSLT [7]. Les règles d autorisations relatives à un document XML particulier sont décrites dans un document XML indépendant appelé feuille XAS (XML Authorisation Sheet). Lors d une étape préliminaire, la feuille XAS est traduite une bonne fois pour toutes en une feuille de style XSLT. Par la suite, à chaque fois qu un utilisateur demande à accéder au document XML, le serveur de documents applique la feuille XSLT obtenue, fournissant ainsi à l utilisateur une vue du document XML compatible avec ses droits. Cet article est organisé de la façon suivante. La section 2 présente brièvement les principales caractéristiques du langage XPath. La section 3 définit notre modèle. La section 4 décrit un prototype de processeur de sécurité pour documents XML implantant notre modèle. La section 5 effectue une comparaison de nos travaux avec des travaux concurrents. Finalement la section 6 conclut cet article. 2. XPath XPath [8] est un langage qui permet d adresser de façon très fine les composants d un document XML. XPath représente un document XML par un ensemble de nœuds formant un arbre. Le document XML de la figure suivante représente un fichier contenant des dossiers médicaux (ce premier exemple ne contient qu un seul dossier). Ce document XML peut être représenté par l arbre de la figure 1. 2
<files> <record id="mrobert"> <name>martin Robert</name> <diagnosis> <item>pneumonia</item> </diagnosis> </files> @id="mrobert" /files /record /name /diagnosis text() Martin Robert /item text() Pneumonia Figure 1 : Représentation arborescente d un document XML Les nœuds dont le label est précédé d un / sont des nœuds de type élément. Ceux dont le label est précédé de @ sont des nœuds de type attribut et ceux dont le label est précédé de text() sont des nœuds de type texte 1. Les expressions suivantes sont des exemples d'expression XPath décrivant des chemins de localisation absolus (cf. [8]) : /files/record. Ce chemin indique tous les éléments record qui sont fils de l élément racine files. /files//text(). Ce chemin indique tous les nœuds textes descendants du nœud racine files. Les expressions suivantes sont des exemples de chemins XPath relatifs. Nous supposerons que le nœud contexte (ou nœud courant) est l élément diagnosis. item/node(). Ce chemin indique tous les nœuds fils (éléments ou textes) d un élément item fils du nœud contexte.../@*. Ce chemin sélectionne tous les nœuds attributs de l élément parent du nœud contexte. Dans notre exemple, ce chemin indique tous les attributs de l élément record. En plus de son utilité pour adresser des composants de documents XML, un sous-ensemble de XPath peut être utilisé pour vérifier des pattern de chemins, c'est-à-dire tester si un nœud donné est conforme à un pattern. Cette particularité de XPath est utilisée par XSLT [7]. Un pattern permet de spécifier un ensemble de conditions sur un nœud. Ces conditions portent non seulement sur le chemin permettant d accéder au nœud, mais aussi sur sa structure et son contenu. Des chemins de localisations vérifiant certaines restrictions peuvent être utilisés comme pattern (voir [7]). Les expressions suivantes sont des exemples de pattern : item. Tout élément item vérifie ce pattern. item/text(). Tout nœud de type text contenu dans un élément item vérifie ce pattern. 1 Le modèle de données de XPath définit d autres types de nœuds : espace de nom, instruction de traitement et commentaire. Pour permettre une présentation concise nous n utilisons pas ces nœuds dans nos exemples. 3
record/@*. Tout attribut associé à un élément record vérifie ce pattern. record[1]/node() record[1]/@*. Tout nœud fils ou tout attribut du premier élément record vérifie ce pattern ( est l opérateur d union). item[contains(text(), Cancer )]. Tout nœud élément item qui contient la chaîne de caractère Cancer vérifie ce pattern. 3. Modèle de contrôles d accès Concevoir un système de contrôles d accès nécessite de définir les sujets, les objets et les règles d autorisations spécifiant si tel ou tel sujet a la permission ou l interdiction d accéder à tel ou tel objet. 3.1. Sujets Un sujet est un utilisateur. A chaque utilisateur est associé un identifiant, qui peut être par exemple son nom de login. Chaque utilisateur est membre de zéro, un ou plusieurs groupes. Pour une question de simplicité nous supposons que les groupes peuvent être imbriqués, mais qu'ils sont disjoints. La hiérarchie des sujets est décrite dans un document XML indépendant appelé feuille XSS (XML Subject Sheet). Le document ci-dessous est un exemple de feuille XSS. <subjects> <users> <member id="dupont"> <name>pierre Dupont</name> </member> <member id="durand"> <name>jacqueline Durand</name> </member> <member id="frobert"> <name>francine Robert</name> </member> <member id="mrobert"> <name>martin Robert</name> </member> <member id="beaufort"> <name>colette Beaufort</name> </member> </users> <groups> <Staff> <Secretary> <member idref="beaufort"/> </Secretary> <Doctor> <member idref="dupont"/> </Doctor> <Nurse> <member idref="durand"/> </Nurse> </Staff> <Patient> <member idref="mrobert"/> </Patient> <Family> <Robert> <member idref="frobert"/> 4
<member idref="mrobert"/> </Robert> </Family> </groups> </subjects> Cette feuille XSS décrit une hiérarchie de sujets composées de quatre utilisateurs, chacun étant membre d au moins un groupe. Il y a trois groupes principaux : Staff, Patient et Family. Le groupe Staff est divisé en trois sous-groupes : Doctor, Nurse, Secretary. Le groupe Family ne contient qu un seul sous-groupe : la famille Robert. Les utilisateurs définis dans la feuille XSS peuvent être sélectionnés en utilisant des chemins de localisation relatifs à l élément subject. Si un chemin de localisation indique un nœud n, on dira que tous les utilisateurs mentionnés dans le sous-arbre dont n est la racine sont sélectionnés. Les expressions suivantes sont des exemples de sélection d utilisateurs : users. Ce chemin sélectionne tous les utilisateurs. users/member[@id='mrobert']. Ce chemin sélectionne l utilisateur Martin Robert. groups//secretary. Ce chemin sélectionne toutes les secrétaires. groups/*[name()!='staff']. Ce chemin sélectionne les utilisateurs qui appartiennent à un groupe principal autre que Staff (et ses sous-groupes : Doctor, Nurse et Secretary). Le document suivant est une DTD possible pour les feuilles XSS : <!ELEMENT subjects (users,groups) > <!ELEMENT users (member*) > <!ELEMENT member (name?) > <!ELEMENT name #PCDATA> <!ATTLIST member id ID idref IDREF > <!ELEMENT groups ((ANY member)*) > 3.2. Objets Dans la section 3 nous avons vu qu un document XML peut être vu comme un arbre XPath. Nous définissons un objet comme un nœud quelconque d un tel arbre. Un ensemble d'objets peut être sélectionné avec un pattern XPath. 3.3. Règles d autorisation Nous avons vu dans les sections 3.1 et 3.2 qu un sujet est un utilisateur et qu un objet est un nœud d un arbre Xpath. Une règle d autorisation est un quadruplet de la forme suivante : < ensemble-de-sujets, ensemble-d -objets, accès, priorité > ensemble-de-sujets est un chemin de localisation relatif à l élément subjects de la feuille XSS (cf. section 3.1) 5
ensemble-d -objets est exprimé avec un pattern XPath évalué dans le document source. la valeur de accès est soit grant, soit deny. priorité est optionnel. Il est utilisé pour associer une priorité à une règle d autorisation (cf. section 3.4 pour plus de détail sur la gestion des priorités). Par défaut, la priorité d une règle est égale à 0. Dans notre modèle la sémantique d une règle d autorisation est unique quel que soit le type de nœud considéré (élément, attribut, texte, etc.) : Si l accès à un nœud n est accordé à un utilisateur u alors u peut voir le sous-arbre dont n est la racine. Si l accès à un nœud n est refusé à un utilisateur u alors u ne peut pas voir le sous-arbre dont n est la racine. Un administrateur de sécurité écrit les règles d autorisation dans une feuille XAS (XML Autorisation Sheet). Le document XML suivant est un exemple de feuille XAS. Cette feuille contient des règles qui s appliquent au document décrit dans la section 2. Elle se réfère à la hiérarchie de sujets définie dans la section 3.1. <! - D O S S I E R S M E D I C A U X --> <! - P O L I T I Q U E P A R D E F A U T --> <!-- Règle 1 --> <xas DefaultPolicy="open" DefaultSubjectsFile="subjects.xss"> <!-- Règle 2 --> <rule access="deny" object="record" subject="groups/*[name()!='staff']"/> <!-- Règle 3 --> <rule access="deny" object="diagnosis" subject="groups//secretary"/> <!-- Règle 4 --> <rule access="grant" object="record[@id=$user]" subject="users/member[@id=$user]"/> <xas/> L élément racine d une feuille XAS détermine si la politique de sécurité par défaut est ouverte (open) ou fermée (closed) [9]. S il n existe aucune règle concernant un utilisateur u particulier et un nœud n particulier alors u a la permission d accéder à n dans le cas d une politique ouverte, et u a l interdiction d accéder à n dans le cas d une politique fermée. Dans le cas de la feuille XAS ci-dessus, la règle 1 indique que la politique par défaut est ouverte (DefaultPolicy="open") La règle 2 précise que les utilisateurs qui ne sont pas membres du personnel ne peuvent pas voir les éléments record (et donc ni leurs attributs et ni leur contenu). La règle 3 indique que les Secrétaires ne peuvent accéder aux éléments diagnosis. La règle 4 autorise un patient à voir son propre dossier médical. La variable $user contient l identifiant de l utilisateur accédant au document XML source. La règle 4 crée 6
une exception à la règle 2 (ou surcharge la règle 2) dans le cas d un utilisateur accédant à son dossier médical. Aucune des règles présentées dans cet exemple ne définit de priorité explicite (absence de l attribut priority). La priorité de chacune de ces règles est donc la priorité par défaut 0. La DTD d une feuille XAS peut s écrire de la façon suivante : <!ELEMENT xas (rule*) > <!ATTLIST xas DefaultPolicy (open closed) #FIXED "open" DefaultSubjectsFile CDATA #FIXED "subjects.xss"> <!ELEMENT rule EMPTY > <!ATTLIST rule object CDATA #REQUIRED subject CDATA #REQUIRED access (grant deny) #REQUIRED priority CDATA "0" > 3.4. Algorithme de calcul des vues et politique de résolution des conflits Si un utilisateur demande à voir le document XML source, il obtient en fait une vue de ce document compatible avec ses droits. Le but de cette section est de présenter l algorithme de calcul d une telle vue. Pour obtenir une expression simple de l algorithme nous remplaçons chaque règle dont la forme générale est : <rule access='grant' object=n subject=u priority=p > par les trois règles suivantes : <rule access='grant' object=n subject=u priority=p > <rule access='grant' object=n//node() subject=u priority=p > <rule access='grant' object=n//@* subject=u priority=p > La première règle autorise l'accès au nœud n, la seconde règle autorise l accès à tous les nœuds descendants de n et la troisième autorise l accès aux attributs de n et de ses descendants. Il est important de noter que cette transformation ne change pas la politique de sécurité. Rappelons que lorsqu un utilisateur u est autorisé à accéder à un nœud n, il est de toute façon autorisé à voir tout le sous-arbre dont n est la racine (cf. section 3.3). Ce remplacement est effectué dans le seul but d obtenir un algorithme simple de calcul des vues. Finalement, si la politique par défaut est fermée (closed) nous ajoutons la règle suivante : <rule access='deny' object='/' subject='users' priority='-1' > et si la politique par défaut est ouverte (open) alors nous ajoutons les 3 règles suivantes : 7
<rule access='grant' object='/' subject='users' priority='-1'> <rule access='grant' object='//node()' subject='users' priority='-1'> <rule access='grant' object='//@*' subject='users' priority='-1'> Ces règles, qui implantent la politique par défaut, ont toutes une priorité négative. Le chemin users sélectionne tous les utilisateurs existants dans la feuille XSS. La feuille XAS devient donc (en appliquant automatiquement ces transformations) : <! - D O S S I E R S M E D I C A U X --> <! - P O L I T I Q U E P A R D E F A U T --> <!-- Règles 1a, 1b et 1c --> <rule access = "grant" object = "/" subject = "users" priority = "-1"> <rule access = "grant" object = "//node()" subject = "users" priority = "-1"> <rule access = "grant" object = "//@*" subject = "users" priority = "-1"> <!-- Règles 2 --> <rule access = "deny" object = "record" subject = "groups/*[name()!='staff']" priority = "0"/> <!-- Règles 3 --> <rule access = "deny" object = "diagnosis" subject = "groups//secretary" priority = "0"/> <!-- Règles 4a, 4b et 4c --> <rule access = "grant" object = "record[@id=$user]" subject = "users/member[@id=$user]" priority = "0"/> <rule access = "grant" object="record[@id=$user]//node()" subject = "users/member[@id=$user]" priority = "0"/> <rule access = "grant" object="record[@id=$user]//@*" subject = "users/member[@id=$user]" priority = "0"/> La règle 1 a été remplacée par trois règles "grant". Ces règles ont une priorité faible (négative), inférieure à la priorité par défaut. La règle 4 a été remplacée par 3 règles "grant". Les règles dont la priorité n'était pas spécifiée dans la XAS originale ont maintenant une priorité nulle. 8
On dira qu'il y a un conflit entre une règle "grant" et une règle "deny" pour un utilisateur u et un nœud n si n vérifie les deux pattern ensemble-d'-objets et si u est adressé par les deux chemins ensemble-de-sujets. Dans notre exemple, la règle 2 est en conflit avec la règle 1b pour chaque élément record si l'utilisateur appartient au groupe Staff. La règle 3 est en conflit avec la règle 1b pour chaque élément diagnosis si l'utilisateur est un membre du groupe Secretary. La règle 4a est en conflit avec la règle 2 lorsqu'un patient consulte l'élément record qui le concerne. La politique de résolution de conflit de notre modèle est très simple : 1. Si, pour un nœud n et un utilisateur u, il existe un conflit entre un ensemble de règles alors les règles ayant la plus haute priorité sont sélectionnées. 2. S'il y a plus d'une règle sélectionnée alors seule la dernière règle dans l'ordre de lecture de la feuille XAS est conservée. La seconde étape de la politique de résolution de conflit explique pourquoi lorsqu'il y a conflit entre la règle 2 et la règle 4a, c'est cette dernière qui est appliquée. Cette politique peut être décrite par l'algorithme de calcul des vues suivant : Algorithme de calcul des vues Soit U l'utilisateur pour lequel la vue est calculée. Soit L une liste de nœuds initialement vide. Ajouter l'élément racine du document source à L. Soit R une liste de nœuds initialement vide. Tant que L n'est pas vide faire N le premier nœud de L Sélectionner toutes les règles telles que N vérifie le pattern contenu dans l'attribut object U est sélectionné par le chemin contenu dans l'attribut subject Appliquer la politique de résolution de conflits. Si la règle sélectionnée est une règle deny alors Enlever N de la liste L. Sinon Ajouter N à R. Remplacer N par ses nœuds-fils (attributs, éléments, etc ) dans L Après l'exécution de cet algorithme, R contient la liste ordonnée des nœuds du document source appartenant à la vue adaptée à l'utilisateur U. En utilisant cet algorithme, on dérive facilement la vue pour chaque utilisateur : Vue pour P.Dupont (Doctor), J.Durand (Nurse) et M. Robert (Patient) <files> <record id="mrobert"> <name>martin Robert</name> <diagnosis> <item>pneumonia</item> </diagnosis> </files> Pierre Dupont et Jacqueline Durand ont le droit de tout voir. Martin Robert peut tout voir uniquement parce que le fichier ne contient qu'un seul dossier, le sien. 9
Vue pour C. Beaufort (Secretary) <files> <record id="mrobert"> <name>martin Robert</name> </files> Colette Beaufort n'a pas le droit de voir l'élément diagnosis. Vue pour F. Robert (Famille Robert) <files/> La politique par défaut de l'hôpital dit que les personnes qui ne sont pas membre du personnel n'ont pas le droit de voir les dossiers médicaux. Cette règle s'applique aussi aux membres de la famille Robert, donc Francine Robert n'a pas le droit de voir les dossiers médicaux y compris celui de Martin Robert. 3.5. Politique de sécurité spécifique L'exemple, que nous avons décrit jusqu'ici était très simple, et n'illustrait pas complètement la puissance de notre modèle. L'objectif de cette section est de montrer que notre modèle permet d écrire de puissantes politiques de sécurité, supportant le concept d'exception, permettant l'expression de règles d autorisation basées sur le contenu et autorisant l insertion de leurres dans le document source. Nous ajoutons au document XML précédent un nouvel élément record : <files> <record id="pfranck"> <name>patricia Frank</name> <diagnosis> <item>cancer</item> <item coverstory="yes">ulcer</item> <comments>life expectancy is limited to two years</comments> </diagnosis> <record id="mrobert">... </files> 10
Ce document peut être représenté par l'arbre XPath suivant : /files /record /record @id="pfranck" /name /diagnosis @id="mrobert" /name /diagnosis text() Patricia Franck /item /item /comments text() Robert Martin /item text()cancer text() Ulcer @coverstory="yes" text() Life... text() Pneumonia Figure 2 Représentation arborescente du document source Patricia Franck est un nouveau patient. Elle a un cancer, et son espérance de vie est limitée à deux ans. L'élément item disant qu'elle est atteinte d'un ulcère est un leurre. Un leurre est un mensonge inséré dans le document source et dont le but est de cacher l'existence d'informations sensibles. Tout utilisateur ayant le droit de voir l'attribut coverstory (leurre) sait que l élément de diagnostic Ulcer est un mensonge (cf. [10] pour plus d'informations sur les leurres et leur gestion). La feuille XSS (description des sujets) est étendue de la façon suivante : <subjects> <users>... <member id="pfranck"><name>patricia Franck</name></member> <member id="gfranck"><name>georges Franck</name></member>... </users> <groups>... <Patient> <member idref="pfranck"/> <member idref="mrobert"/> </Patient> <Family>... <Franck> <member idref="gfranck"/> <member idref="pfranck"/> </Franck> </Family> </groups> </subjects> Patricia et Georges Franck sont de nouveaux utilisateurs, un groupe décrivant la famille Franck est aussi créé. 11
La feuille décrivant la politique de sécurité (XAS) est étendue de la façon suivante : <! - D O S S I E R S M E D I C A U X --> <! - P O L I T I Q U E P A R D E F A U T --> <xas DefaultPolicy = "open" DefaultSubjectsFile = "subjects.xss">... etc. <!-- P O L I T I Q U E S P E C I F I Q U E A P A T R I C I A F R A N C K --> <!-- Règle 5 --> <rule access = "grant" object = "record[@id='pfranck']" subject = "groups/family/franck" /> <!-- Règle 6 --> <rule access = "deny" object = "record[@id='pfranck']//comments" subject = "groups/family/franck" /> <!-- Règle 7 --> <rule access = "deny" object = "record[@id='pfranck']//comments/text()" subject = "groups//*[name()='nurse']" /> <!-- Règle 8 --> <rule access = "deny" object = "item[contains(text(),'cancer')]" subject = "users/member[@id='pfranck']" /> <!-- Rule 9 --> <rule access = "grant" object = "item[@coverstory='yes']" subject = "users/member[@id='pfranck']" /> <!-- Rule 10 --> <rule access = "deny" object = "item/@coverstory" subject = "users/member[@id='pfranck']" /> </xas> La règle 5 indique que la Famille Franck est autorisée à voir les données concernant Patricia Franck. La règle 6 précise que la Famille Franck (y compris Patricia) n'a pas le droit de voir l élément comments, qui apparaît dans le dossier de Patricia. La règle 7 spécifie que les infirmières n'ont pas le droit de voir le texte du commentaire dans le dossier de Patricia Franck. Cette règle protège donc uniquement le texte du commentaire mais pas l'existence du commentaire comme dans le cas de la règle 6. La règle 8 indique que P. Franck n'a pas le droit de voir les éléments item qui contiennent le mot 'Cancer'. Cette règle est un bon exemple de protection basée sur le contenu. La règle 9 indique que P. Franck a le droit de voir l'élément item qui est un leurre mais la règle 10 l'empêche de savoir qu'il s'agit d'un leurre. Les règles 5 à 10 montrent que P. Franck n'est pas considérée comme un patient ordinaire. La politique par défaut de l'hôpital ne s'applique pas à elle. Les médecins estiment que pour des raisons psychologiques, P. Franck ne doit pas savoir qu'elle est atteinte d'un cancer. Les médecins ont donc décidé de lui mentir en lui disant qu'elle avait un ulcère. La famille Franck 12
connaît l'existence de ce mensonge et a la permission de consulter les données concernant P. Franck. Néanmoins, le commentaire sur son espérance de vie doit rester confidentiel, même les infirmières n'ont pas accès à cette information. Les vues pour certains des utilisateurs cités ci-dessus sont donc : Vue pour P. Dupont (Doctor) <files> <record id="pfranck"> <name>patricia Frank</name> <diagnosis> <item>cancer</item> <item coverstory="yes"> Ulcer</item> <comments>life expectancy is limited to two years</comments> </diagnosis> <record id="mrobert"> <name>martin Robert</name> <diagnosis> <item>pneumonia</item> </diagnosis> </files> Vue pour J. Durand (Nurse) <files> <record id="pfranck"> <name>patricia Frank</name> <diagnosis> <item>cancer</item> <item coverstory="yes"> Ulcer</item> <comments/> </diagnosis> <record id="mrobert"> <name>martin Robert</name> <diagnosis> <item>pneumonia</item> </diagnosis> </files> Vue pour G. Franck (Famille Franck) <files> <record id="pfranck"> <name>patricia Frank</name> <diagnosis> <item>cancer</item> <item coverstory="yes"> Ulcer</item> </diagnosis> </files> Pierre Dupont est un médecin. Il peut voir toutes les informations. Jacqueline Durand est infirmière. Elle a accès à toutes les informations sauf au contenu de l élément comments. Georges Franck a accès au dossier médical de Patricia Franck. Il sait que les médecins ont décidé de mentir à Patricia à propos de sa maladie. Il n'a pas connaissance de l'existence de l'élément comments. 13
Vue pour P. Franck (Patient) <files> <record id="pfranck"> <name>patricia Frank</name> <diagnosis> <item>ulcer</item> </diagnosis> </files> Patricia Franck pense qu'elle a un ulcère. Cet exemple montre qu une politique de sécurité par défaut peut éventuellement être surchargée par un ensemble d'exceptions adaptées à des cas particuliers. Finalement, notons que dans [3], les auteurs définissent les concepts de feuille d'autorisation au niveau document et de feuille d'autorisation au niveau DTD 2. Une feuille d'autorisation au niveau document s'applique à un document donné. Une feuille d'autorisation au niveau DTD s'applique à tous les documents valides par rapport à une DTD particulière. Notre modèle permet aussi la définition d'une politique de sécurité au niveau DTD. Si pour un document XML donné, deux feuilles XAS s appliquent, une au niveau DTD et une autre au niveau document, alors les règles d autorisation définies au niveau document sont concaténées avec celles définies au niveau DTD pour former une feuille XAS globale. En d'autres termes, une feuille d'autorisation globale contient les règles définies pour une classe de documents puis celles spécifiquement définies pour une instance de cette classe. Cette feuille XAS globale est utilisée pour calculer les différentes vues. Il est à noter que l utilisation de valeurs de priorité pertinentes permet de définir, au niveau DTD, des règles qui pourront être surchargées (priorité faible) au niveau instance, et des règles obligatoires qui ne pourront être transgressées au niveau instance (priorité infinie). 4. Prototype Nous avons développé un prototype de processeur de sécurité pour document XML. Ce prototype utilise XSLT. Il est disponible en ligne à l'adresse http://sis.univ-tln.fr/xmlsecu. La figure 3 décrit son architecture. Notre prototype est intégré à un serveur Web Apache 3 utilisant Tomcat 4 comme serveur de servlets Java. Les vues des documents XML sources sont construites dynamiquement en utilisant l'environnement de publication de documents XML Cocoon [11]. Comme le montre la figure 3, la production d'une vue est faite en deux étapes : (i) la politique de sécurité est traduite en une feuille XSLT puis (ii) cette feuille XSLT est appliquée au document source : 1. Les règles d'autorisation exprimées sous une forme simple dans le fichier Doc.XAS sont transformées en règles (templates) XSLT pour produire une feuille de style XSL (Doc.XSL). Cette transformation est effectuée une bonne fois pour toutes. La feuille XAS n est plus utilisée par la suite (à moins qu elle soit modifiée, dans ce cas elle est automatiquement retraduite). Le résultat de cette transformation est stocké dans un cache. 2 Document Type Definition 3 http://www.apache.org 4 http://jakarta.apache.org/tomcat/index.html 14
xas2xsl.xsl 1 Doc.XAS XML parser XSLT processor Doc.XSL Cocoon Tomcat Apache Web Server User_id Doc.XSL Subjects. XSS 2 Doc.XML XML parser XSLT processor View.XML Cocoon Tomcat Apache Web Server Figure 3 Architecture du prototype 15
2. Lorsqu'un utilisateur accède à un document via son URL, le système lui retourne automatiquement une vue du document compatible avec ses droits. Celle-ci est produite dynamiquement par un processeur XSLT en appliquant Doc.XSL. Les templates contenus dans cette feuille de style XSLT sont utilisés pour calculer les différentes vues conformément à l'algorithme décrit dans la section 3.4. La feuille de style Doc.XSL nécessite en paramètre l'identifiant de l'utilisateur (fourni par le serveur Web après authentification) ainsi que la feuille XSS décrivant la hiérarchie des sujets. La vue obtenue est enregistrée dans le cache. 5. Comparaison avec d'autres travaux Par rapport à d'autres modèles notre proposition présente plusieurs avantages. Notre modèle permet l écriture de politiques de sécurité précises et opérant à un niveau de granularité très fin puisque n importe quel nœud de l'arbre représentant un document XML peut être protégé de façon indépendante. La sémantique d une autorisation est définie précisément et est toujours la même quel que soit le type du nœud protégé. Notre modèle permet l écriture de règles d autorisation basées sur la localisation, la structure et le contenu des données à protéger. Notre politique de résolution des conflits est simple et facile à mettre en œuvre. Notre proposition est totalement conforme avec les standards en vigueur puisqu'elle utilise le langage XPath pour adresser des fragments de document XML et le langage XSLT pour calculer les différentes vues. Dans [3], la sémantique d'une autorisation est variable. Une autorisation peut être soit locale, elle s'applique alors à un élément et à ses attributs, soit récursive, elle s'applique alors aussi aux sous-éléments. L'expressivité est limitée puisque certains nœuds, comme les nœuds de type texte, ne peuvent être protégés de façon indépendante. De plus, la politique de résolution des conflits est relativement complexe. Dans [4], la sémantique des autorisations est définie comme étant polymorphique, c'est-à-dire qu'elle varie selon le type de l'objet à protéger. Ce modèle n'offre pas la possibilité de protéger tous les types de nœuds. Dans [5], le modèle ne permet pas de protéger indépendamment les attributs et les nœuds de type texte. En résumé, aucun de ces trois modèles n'exploite totalement la puissance du langage XPath. En ce qui concerne notre prototype, le fait d utiliser XSLT nous permet de choisir le processeur offrant les meilleures performances, que ce soit celui d Apache 5, Oracle 6 ou IBM, et nous garantit également une compatibilité constantes avec les standards du W3C [1,7,8]. De plus, l'intégration de notre prototype dans un serveur Web est immédiate. Les prototypes [12,13,14] qui implantent les modèles [3,4,5] utilisent un processeur propriétaire développé en Java pour produire les vues. Ces processeurs n'offrent pas la puissance et l'efficacité d'un processeur dédié à XSLT. De plus, en cas de modifications dans les recommandations du W3C, ces processeurs doivent être reprogrammés. 6. Conclusion et perspectives Dans cet article, nous avons défini un modèle de contrôles d'accès pour documents XML. Nous travaillons actuellement à l'extension de ce modèle. 5 http://xml.apache.org/xalan 6 http://technet.oracle.com/tech/xml/ 16
Nous étudions la possibilité d'intégrer la définition d'autorisations provisionnelles. Dans [5], une autorisation provisionnelle est définie comme une règle indiquant à l'utilisateur que l'autorisation ne lui sera accordée que si lui ou le système effectue certaines actions (enregistrement de la tentative d accès dans un fichier log par exemple). Le modèle présenté dans cet article assume implicitement qu'un utilisateur n'a pas accès aux DTD des documents. Les prochaines versions de notre modèle incluront la possibilité de protéger le contenu d'une DTD et surtout d'un schéma XML de la même façon qu'un document. Dans cet article, nous nous sommes limités aux autorisations en lecture. En effet, pour des documents destinés à être publiés sur Internet, le privilège en lecture est clairement le privilège le plus important à prendre en compte. Nous étendons toutefois actuellement notre modèle (et notre prototype) aux contrôles des accès en écriture. 7. References [1] T. Bray et al. "Extensible Markup Language (XML) 1.0". World Wide Web Consortium (W3C). http://www.w3c.org/tr/rec-xml (October 2000). [2] M. Bartel et al. "XML-Signature Syntax and Processing". W3C Candidate Recommendation. http://www.w3c.org/tr/xmldsig-core (October-2000). [3] E. Damiani, S. De Capitani di Vimercati, S. Paraboschi, P. Samarati, "Securing XML Documents,'' in Proc. of the 2000 International Conference on Extending Database Technology (EDBT2000), Konstanz, Germany, March 27-31, 2000. [4] E. Bertino, S. Castano, E. Ferrari and M. Mesiti. "Specifying and Enforcing Access Control Policies for XML Document Sources". World Wide Web Journal, vol. 3, n. 3, Baltzer Science Publishers. [5] M. Kudo and S. Hada. "XML Document Security based on Provisional Authorisation". Proceedings of the 7th ACM conference on Computer and communications security. November, 2000, Athens Greece. [6] A. Gabillon, E. Bruno. A Filtering Model for XML documents. Accepted for the next WWW10 Conference Workshop on Information Filtering which will be held in Hong Kong in May 2001. [7] J. Clark. "XSL Transformations (XSLT) Version 1.0". World Wide Web Consortium (W3C). http://www.w3c.org/tr/xslt (November 1999). [8] J. Clark et al.. "XML Path Language (XPath) Version 1.0". World Wide Web Consortium (W3C). http://www.w3c.org/tr/xpath (November 1999). [9] S. Jajodia, P. Samarati, V. Subrahmanian and E. Bertino. A Unified Framework for Enforcing Multiple Access Control Policies. Proc. of the 1997 ACM International SIGMOD Conference on Management of Data, Tucson, May 1997. [10]F. Cuppens, A. Gabillon. Cover Story Management. Data and Knowledge Engineering, to be published. 17
[11]Cocoon. http://xml.apache.org/cocoon/index.html [12] E. Damiani, S. De Capitani di Vimercati, S. Paraboschi, P. Samarati "XML Access Control Systems: A Component-Based Approach'' in Proc. IFIP WG11.3 Working Conference on Database Security, Schoorl, The Netherlands, August 21-23, 2000. [13] E. Bertino, M. Braun, S. Castano, E. Ferrari, M. Mesiti. "AuthorX: A Java-Based System for XML Data Protection". In Proc. of the 14th Annual IFIP WG 11.3 Working Conference on Database Security, Schoorl, The Netherlands, August 2000. [14] AlphaWorks. XML Security Suite (xss4j). http://www.alphaworks.ibm.com/tech/xmlsecuritysuite. 18