Une plate forme UML-XML pour la gestion des rôles d'un Système d'information Gilles Goncalves, Fred Hémery LABOGP - Université d'Artois Technoparc - Zone Futura 62400 Béthune tél: 03 21 63 71 64 fax: 03 21 61 17 80 mél: {goncalves, hemery}@univ-artois.fr

Résumé : Nous présentons dans cet article une plate forme logicielle pour générer automatiquement les profils utilisateur nécessaires à l'utilisation d'un système d'information. Cette plate forme est basée sur l'utilisation d'un AGL associé au langage UML et sur des composants JAVA que nous avons développés pour la génération des rôles dans un format XML . Dans une première partie, nous rappelons les raisons qui ont motivé nos travaux . Dans une deuxième partie, nous montrons comment nous utilisons les concepts présents dans UML pour construire un modèle de contrôle d'accès basé sur la notion de rôle. Nous présentons dans une troisième partie le formalisme d'échange XML que nous avons retenu pour représenter la sémantique des rôles. Enfin dans une dernière partie, on propose une traduction possible de ces rôles vers un middleware construit à partir du Kit Java Security .

Mots clés : système d'information, modélisation UML, contrôle d'accès, rôles, RBAC, XML

1 Introduction L'ouverture des S.I. (Système d'Information) de l'entreprise vers les partenaires privilégiés (i.e. Sous-traitant, fournisseurs, clients) permet de mettre en place de nouvelles organisations (i.e. Réseaux d'entreprises, entreprises étendues, entreprises virtuelles) qui se veulent plus réactives et plus flexibles face à la concurrence accrue engendrée par la mondialisation des marchés. Cette ouverture est maintenant facilitée par l'utilisation des nouvelles technologies ou progiciels intégrés que sont l'Intranet, l'Extranet, les places de marchés, les SCM, etc. Il devient dès lors primordial pour une entreprise de protéger son Système d'information[MANA97] contre toute modification abusive ou tout accès non autorisé[SAND94]. Dans cet article nous nous intéresserons plus particulièrement à la gestion du contrôle d'accès associé à chaque utilisateur du S.I. Celui-ci est utilisé pour limiter les possibilités d'utilisation du système d'information par les utilisateurs autorisés à s'y connecter. La gestion des utilisateurs et de leurs droits d'accès au SI (i.e. permissions) est réalisée par un administrateur sécurité chargé de la mise en place d'une politique de sécurité qui a été définie en amont par l'entreprise.

Les concepts de base que l'on manipule dans un modèle de contrôle d'accès sont les sujets (utilisateurs ou programmes) qui accèdent aux objets (données ou services) en utilisant un mode d'accès (lecture, écriture, exécution). L'un des systèmes de contrôle d'accès le plus connu est la matrice de contrôle d'accès[LAND81]. Elle définit les droits ou privilèges de chaque utilisateur sur chaque objet. Le contrôle d'accès basé sur la notion de rôle (Rôle Based Access Control RBAC)[ SAND96] fait l'objet depuis quelques années d'une attention particulière et il est considéré aujourd'hui comme une alternative aux traditionnels contrôles d'accès de type discrétionnaire ou mandataire. Les concepts de bases qui caractérisent un modèle RBAC découlent des systèmes multi-utilisateurs et multi-tâches des années 1970. Au lieu d'affecter les permissions aux utilisateurs directement, ils sont affectés dans un premier temps à des rôles. Un rôle représente une compétence ou une autorité vis à vis du système d'information. La gestion des permissions est alors beaucoup plus simple puisque dans un second temps, il reste uniquement à associer les différents rôles aux acteurs de l'entreprise. Pour chaque utilisateur, on définit ainsi un profil d'utilisation nécessaire à l'accomplissement de son ou ses rôles dans l'entreprise. Bien que la notion de rôles facilite la gestion du contrôle d'accès par l'administrateur sécurité, il lui reste néanmoins la difficulté d'identifier clairement ces rôles avant de les affecter aux acteurs de l'entreprise. Généralement un rôle représente une tâche qui intervient dans un ou plusieurs processus de l'entreprise. Un rôle peut aussi être identifié comme une suite de fonctions qui seront exécutées par un même acteur de l'entreprise. Un rôle devra donc réunir un ensemble de permissions qui lui permettront d'exécuter les fonctions et d'accéder aux données manipulées par ces fonctions. Les travaux que nous présentons visent à simplifier la détermination des rôles voire à l'automatiser dans la plupart des cas. Pour cela nous séparons comme le fait Thomsen dans [THOM98] la responsabilité de cette gestion entre d'une part le développeur du SI qui connaît parfaitement les fonctionnalités de son application et l'administrateur sécurité qui maîtrise les contraintes imposées par la politique de sécurité de l 'entreprise. Le premier est à même de déterminer les rôles qui interagissent avec le SI, tandis que le second connaît les critères d'affectation de ces rôles aux acteurs de l'entreprise. Il nous semble primordial de clairement identifier l'ensemble des rôles du SI dès le début de la conception de celui ci. Pour cela, nous utilisons comme langage de modélisation un langage de conception orientée objet UML. L'intérêt de cette approche est de prendre en compte simultanément les aspects conceptuels de la création du S.I. et de son schéma de sécurité associé. Une conséquence de cette approche est de bien séparer également les aspects conceptuels du modèle de sécurité de sa mise en oeuvre sur une plate forme utilisant une base de données particulière. Dans la section suivante nous montrons les différents concepts du langage UML qui nous ont permis de formaliser un modèle de contrôle d'accès de type RBAC.

2 Un modèle de contrôle d'accès RBAC basé sur UML Formellement un modèle RBAC peut être caractérisé par trois entités[ SAND96] : un ensemble d'utilisateurs U interagissent avec le système d'information, un ensemble de rôles R qui représentent des responsabilités bien identifiées dans l'organisation de l'entreprise,

et un ensemble de permissions P qui indiquent un droit d'accès particulier sur un ou plusieurs objets du système d'information. On distingue également dans le modèle RBAC, un ensemble de relations qui relient ces entités (voir figure 1): une relation R-R encore appelée relation d'héritage permet de définir des hiérarchies de rôles, une relation P-R permet d'associer un ensemble de permissions à un rôle, et une relation U-R associe un ensemble de rôles à un utilisateur donné.

Fig. 1 Le modèle RBAC Nous avons dans nos travaux précédents étendu ce modèle en y introduisant une quatrième entité appelée « Fonction » qui permet d'obtenir plus de flexibilité aux changements de responsabilités des acteurs dans l'entreprise. Un rôle sera ainsi identifié comme une suite de fonctions qui seront exécutées par un même acteur de l'entreprise. Un rôle devra donc réunir un ensemble de permissions qui lui permettront d'exécuter les fonctions et d'accéder aux données manipulées par ces fonctions (voir figure 2).

Fig. 2 Le modèle RBAC étendu A partir de ce modèle nous montrons dans [GONC00] comment nous rapprochons le concept d'acteur introduit dans les diagrammes de cas d'utilisation avec la notion de rôle des systèmes RBAC. Un acteur pouvant interagir avec le système au travers de plusieurs cas d'utilisation, nous avons rapproché ce concept avec celui de fonction introduit dans le modèle RBAC étendu. Chaque cas d'utilisation représente un service ou une fonction que le S.I. est susceptible de rendre aux utilisateurs. Il est ainsi possible identifier à partir d'un diagramme de cas d'utilisation, l'ensemble des fonctions qui sont nécessaires pour l'exécution d'un rôle. Nous pensons que ce niveau supplémentaire apportera davantage de flexibilité dans la gestion des droits. Supposons qu'une nouvelle organisation doit être mise en place dans une entreprise et qu'il s'avère nécessaire de redistribuer autrement les fonctions de chacun des acteurs. Dans ce cas, la seule modification à faire pour l'administrateur serait de modifier les liaisons entre les rôles et les fonctions en tenant compte de la nouvelle affectation. Les utilisateurs auront toujours les mêmes rôles mais seules les fonctions associées seront différentes. Nous introduisons donc deux nouvelles relations au modèle RBAC de base. La relation P-F qui consiste à associer des permissions aux fonctions et la relation F-R qui associe les fonctions aux rôles. En fait, un cas d'utilisation synthétise une collaboration entre objets que l'on peut décrire à l'aide de diagrammes d'interaction (diagrammes de séquence et diagrammes de collaboration).

Chaque cas d'utilisation peut être décrit par une ou plusieurs collaborations. Une collaboration est décrite par un ou plusieurs diagrammes d'interaction. L'examen de ces diagrammes d'interaction nous permet de connaître l'ensemble des messages nécessaires à l'interaction et donc d'en déduire les permissions associées à l'exécution d'une fonction. On a fait l'hypothèse que le seul mode d'accès considéré ici était le droit d'exécution d'une méthode sur un objet comme dans le modèle Iris[AHAD92].

3 Un format d'échange XML Dans la section précédente nous avons rappelé les équivalences que l'on peut faire entre les concepts RBAC et le langage UML. Le but de cette section est d'expliquer la méthode que nous avons utilisée pour retrouver les concepts de rôles, de fonctions, de permissions proposés dans notre modèle RBAC étendu et ce à partir de l'analyse du langage UML utilisé pour modéliser le travail du concepteur. La figure [traitUML] nous donne les fichiers utilisés dans notre démarche.

Fig. 3 Traitement du métamodèle UML pour déterminer les éléments de sécurité

3.1 Le fichier d'entrée au format XMI [OMG00] Le fichier que nous utiliserons en entrée pour notre méthode est un fichier au format XMI (eXchange MetaData Interchange) qui a été produit par notre atelier de génie logiciel [RATI]. L'intérêt du fichier XMI est qu'il devient un standard d'échanges entre les différents AGL ce qui pérennise notre méthode. Le contenu du fichier décrit le méta modèle du langage UML à l'aide de la syntaxe XML (eXtensible Markup Language). A partir du fichier XMI, nous allons à l'aide d'un analyseur XML récupérer les informations pertinentes du méta-modèle UML pour obtenir les concepts de notre modèle RBAC étendu. C'est à dire les acteurs et les cas d'utilisation décrits dans les diagrammes de cas d'utilisation, les objets, les méthodes décrits dans les diagrammes d'interaction (séquences ou collaborations).

3.2 Le fichier de sortie au format XML Afin de rester indépendant de tout système de contrôle d'accès cible et de nous permettre de traiter des applications distribuées (CORBA,EJB,...) et hétérogènes, le résultat de cette analyse est stocké dans un fichier qui utilise la syntaxe XML. Le document DTD présenté dans la section suivante contient l'ensemble des concepts de notre modèle RBAC étendu et donne l'aspect d'un document valide résultat de l'analyse du document XMI utilisé en entrée. Le fichier DTD décrit la syntaxe XML des fichiers obtenus après traitement du fichier XMI. Le fichier complet est donné en annexe. Celui ci traduit la structure générique d'un modèle RBAC étendu. La figure [fichXML] représente l'architecture de ce document DTD dérivé du modèle RBAC étendu .

Fig. 4 Diagramme de classes déduit du fichier XML

3.3 Présentation des éléments du fichier DTD L'élément racine du document DTD qui est donné en annexe contient 7 types de fils •

les rôles: les acteurs du méta-modèle UML

•

les fonctions: les cas d'utilisation du méta-modèle UML

•

les permissions: les appels de méthode sur des objets

•

les objets et classes: entités sur lesquelles s'appliquent le contrôle d'accès

•

les méthodes et opérations: entités définissant les types d'accès qui s'appliquent sur les objets.

Comme nous l'avons précisé dans la première partie, dans notre modèle l'affectation des personnes aux rôles n'est pas traitée. Elle reste à la charge et de la compétence de l'administrateur sécurité. •

Un rôle est caractérisé par un nom, une liste de fonctions associées qui exprime la relation R-F de notre modèle et une liste de rôles qui exprime la relation R-R de notre modèle.

•

Une fonction est caractérisée par un nom, une liste de rôles (relation R-F), une liste de fonctions (relation F-F) et une liste de permissions (relation F-P).

•

Une permission est caractérisée par une liste de méthodes, une liste d'objets et une liste de fonctions (relation F-P)

•

Une méthode est caractérisée par une liste de permissions, une opération qu'elle implémente et une liste d'attributs

•

Un objet est caractérisé par un nom, une liste de permissions et une classe

•

Une opération est caractérisée par un nom et une liste de méthodes qui l'implémentent

•

Une classe est caractérisée par un nom et une liste d'objets qui l'instancient.

Le document obtenu est utilisé par une plate forme d'évaluation en cours de développement qui montrera comment à partir d'un travail de conception décrit en langage UML, il est possible de produire les règles d'accès aux données d'un système d'information cible. Actuellement le système cible que nous utilisons est la machine virtuelle java, la plate forme produit les fichiers nécessaires à la mise en oeuvre d'une exécution de l'application avec un contrôle d'accès dont les règles sont le résultat du traitement du travail de conception. Une présentation de cette réalisation est donnée dans la section suivante.

4 Utilisation du fichier XML avec une plate forme Java Le langage Java est principalement utilisé dans le développement d'application distribuées. Il est notamment largement utilisé dans la mise en place de solution e-business. Ce contexte d'application comme nous l'avons indiqué dans l'introduction nécessite la garantie que les données utilisées le sont dans le cadre d'une politique de sécurité clairement établie. Dans cette section, nous allons proposer un exemple d'utilisation du fichier XML présenté dans la section précédente. Le travail consiste à mettre en correspondance les concepts que nous avons introduits qui sont basés sur le modèle RBAC avec les concepts de sécurité utilisés par la machine virtuelle Java pour contrôler l'accès aux ressources lors de l'exécution d'une application.

4.1 Présentation des concepts de contrôle d'accès utilisés dans la JVM (Java Virtual Machine) 4.1.1

Évolution du modèle de sécurité en Java

Les concepts de sécurité proposés par le langage Java [GONG97, JAVA98, LAI99, WALL97, GAVR98] ont pour origine la nécessité de garantir que le code mobile développé dans le cadre d'une application distribuée est sûr. C'est pourquoi dans les premières versions (JDK1.0.2), la sécurité était assurée en opposant le code local (chargé localement) avec le code distant (chargé à partir du réseau). La politique de sécurité n'autorisait aucune permission au code distant et donnait toutes les permissions au code local. Il a été rapidement convenu que cette politique de sécurité était trop rigide. L'introduction de la notion de domaine a permis de mettre en place une politique de sécurité qui tienne compte de l'origine (lieu de chargement) et/ou d'une identification du concepteur (par un mécanisme de signature électronique). Le domaine permet de distinguer les codes mobiles et de leur donner des privilèges différents suivant leur origine et/ou leur identification. Les privilèges sont indiqués par des permissions d'exécuter une ou des actions sur une ou des cibles. Enfin dans les dernières versions Java, le programmeur a la possibilité de mettre en place une politique de sécurité qui prenne en compte l'identité de la personne qui exécute le code : le principal.

Nous allons maintenant nous intéresser aux concepts qui sont utilisés pour bâtir une politique de sécurité en Java. Le contrôle d'accès est assuré par la mise en oeuvre de 5 concepts: 1. Le code source: introduit la notion de code mobile qui constitue une partie de l'application distribuée, qui pourra être obtenue après une phase de chargement par réseau et qui constitue une entité sur laquelle on appliquera des règles de contrôle d'accès. 2. Les permissions: propose un mécanisme de vérification du droit d'exécuter le type d'accès sur une ressource. 3. La politique de sécurité: mécanisme qui permet d'accorder des permissions à un regroupement de code. 4. Le domaine de protection: regroupe un code source et un ensemble de permissions, il est utilisé dans la phase d'exécution pour mettre en oeuvre le contrôle d'accès aux ressources. 5. Le principal: représente l'interface (l'identité) de l'entité (un utilisateur ou une autre application) vis à vis de l'application. Nous allons développer les concepts qui seront utilisés par la suite, le domaine de protection étant le mécanisme permettant à la machine virtuelle de réaliser concrètement le contrôle d'accès pendant son exécution ne sera pas présenté. 4.1.2

Les permissions

Une permission est un concept qui a deux propriétés: une cible et une action. La cible représente une ressource et l'action représente un type d'accès sur la cible. Le langage Java propose une classe abstraite pour mettre en oeuvre le concept, et met à la disposition du programmeur des classes spécialisées pour les ressources usuelles (fichiers, socket, propriétés, ...). Il permet aussi le développement de permissions propres à son application. Dans l'exemple qui suit, la classe NotePermission est une spécialisation de la classe Permission et va permettre au programmeur de mettre en place un contrôle d'accès sur une classe Note avec comme type d'actions la visualisation (getValeur) et la modification (setValeur) par exemple.

public NotePermission extends Permission { private String nom; public NotePermission (String nom, String action) { this.nom = nom; traite (action) } Private void traite (String action) { StringTokenizer st = new StringTokenizer(action, ",\t "); while (st.hasMoreTokens()) { String tok = st.nextToken(); if (tok.equals("getValeur")) ... if (tok.equals("setValeur")) ... } } }

4.1.3

La politique de sécurité

La politique de sécurité permet de mettre en place un mécanisme d'affectation des permissions aux codes sources. Le langage met à disposition une classe abstraite qui peut être spécialisée. Il propose une mise en oeuvre basée sur la lecture d'un fichier texte.

grant CodeBase "http://labogp.univ-artois.fr" SignedBy "Saisie" { permission labogp.NotePermission "ctrlX","getValeur" ... }

Un fichier de politique de sécurité est une suite de grant, dans l'exemple on indique que le code obtenu à l'adresse http://labogp.univ-artois.fr et qui est signé par saisie aura la permission NotePermission sur la cible ctrlX avec comme type d'accès autorisés getValeur. Un autre fichier de politique de sécurité est nécessaire pour affecter des permissions à un code source qui sera exécuté par une entité authentifiée (un principal).

grant CodeBase "http://labogp.univ-artois.fr" SignedBy "Saisie" Principal Enseignant "Martin" { permission labogp.NotePermission "ctrlX","getValeur" ... }

Dans l'exemple, on précise que seul le principal de type Enseignant et de nom Martin disposera de la permission NotePermission. 4.1.4

Le principal

Le principal représente l'entité qui va exécuter le code. L'identité d'une entité (Subject) a été obtenue après une phase d'authentification (mot de passe, certificats, ...). Une entité (Subject) peut avoir plusieurs identités vis à vis du système. Le langage met à la disposition du programmeur les interfaces abstraites Principal et PrincipalComparator qui permettent de mettre en place une hiérarchie de Principal. 4.1.5

Le code source

Le code source permet de nommer une partie de l'application. Il est caractérisé soit par un lieu de chargement (CodeBase) soit par une signature électronique (SignedBy) qui est fonction du contenu du code.

4.2 Traduction du modèle RBAC étendu dans le modèle de sécurité Java. Dans cette section, nous allons indiquer nos choix de traduction des concepts RBAC étendu dans le modèle de sécurité Java. La figure 5 indique qu'il y a pratiquement une correspondance directe.

Fig. 5 Correspondance entre les concepts RBAC étendu et Java 4.2.1

Un rôle = un principal

Un rôle correspond au concept de principal introduit en Java. De plus le concept PrincipalComparator permet de mettre en place une hiérarchie de rôles[LAI99]. 4.2.2

Une fonction + une clé = un code source signé

La fonction correspond à une notion de tâche particulière à effectuer dans un système d'information. Le code source fait apparaître la notion de partie d'application. Nous avons donc la encore choisi de faire une correspondance directe entre fonction et code source. Une fonction peut être en relation avec d'autres fonctions (généralité, dépendance, voir [GONC00]). Pour mettre en relation les parties d'application nous avons choisi d'utiliser la notion de signature (SignedBy) qui correspond mieux à notre concept de fonction par rapport à la notion de CodeBase qui s'intéresse plus au concept de code mobile et qui ne nous intéresse pas directement ici. Donc en définitive: un code source signé = une fonction + une clé pour construire la signature Dans notre modèle, nous avons indiqué que les fonctions peuvent être en relation de

généralisation ou de dépendance (inclusion, extension). Pour conserver ces relations, nous allons associer les signatures de chaque fonction. Par exemple dans la figure 6 (a), si la fonction F1 Visualisation par etudiant est spécialisée par la fonction F11 Visualisation à l'Ecran par l'étudiant et la fonction F12 Visualisation sur papier par l'Etudiant, alors le code source F1 sera signé par les clés de F1, F11 et F12. De même pour les relations de dépendance si dans l'exemple de la figure 6 (b) la fonction F1 Saisie Evaluation est en relation avec la fonction F2 Authentification Utilisateur alors le code source de F1 sera signé par les clés F1 et F2.

Fig. 6 La généralisation entre fonctions 4.2.3

Les permissions RBAC et Java

Dans notre modèle, une permission correspond au droit d'exécuter une méthode sur un objet, ce concept peut être repris directement dans le langage Java. L'implantation de notre modèle à l'aide du Java Development Kit (JDK1.3) et d'une extension Java Authentication and authorization System (JAAS) est en cours de réalisation.

5 Conclusion Nous avons montré comment utiliser les concepts d'UML pour définir une gestion du contrôle d'accès au S.I. de l'entreprise basée sur un modèle RBAC. Cette définition se fait conjointement par le concepteur du S.I. et l'administrateur sécurité. L'administrateur sécurité se trouve ainsi dégager de la responsabilité d'identifier les différents rôles. Pour valider notre approche une plate-forme UML-XML-JAVA a été conçue et les deux premiers éléments ont été développés. Le dernier élément de cette plate forme est actuellement en cours de réalisation. Dans les extensions futures de nos travaux, on s'intéressera à la prise en compte des contraintes d'applications et des contraintes de l'entreprise pour spécifier un modèle de contrôle d'accès de type RBAC niveau 3 [SAND97,OSBO00,GAIL00]. Le caractère générique de la syntaxe XML nous permet d'envisager son exploitation dans des middlewares basés sur une approche EJB ou encore CORBA.

6 Référence MANA97

Managing Information System Security, Macmillan, 1997

JAVA98

Java Security, O’Reilly, 1998

OMG00

OMG XML Metadata Interchange (XMI) Specification, Version 1.1, Technical report, Cooperative Research Centre for Distributed Systems Technology (DSTC), Novembre 2000

THOM98

Dan Thomsen, Dick O'Brien, Jessica Bogle. Role Based Access Control Framework for Network Entreprises In 14th Annual Computer Security Applications Conference Decembre 1998

SAND96

Ravi Sandhu, Edward J. Coyne, Hal L. Feinstein, Charles E. Youman. Role based access control models. IEEE Computer. 1996

GONC00

Gilles Goncalves, Fred Hémery. Des cas d'utilisation en UML à la gestion de rôles dans un Système d'Information. Inforsid 2000 Lyon

SAND94

Ravi Sandhu, Pierangela Samarati. Access Control: Principles and Practices. IEEE Communication. 1994

GAIL00

Gail-Joon Ahn Radi Sandhu. Role-Based Authorization Contraints Specification. ACM Transactions on Information and Systems Security. Volume 3, Novembre 2000

OSBO00

Sylvia Osborn Ravi Sandhu Qamar Munawer. Configuring Role-Based Access Control to Enforce Mandatory and Discretionary Access Control Policies. ACM Transactions on Information and Systems Security. Volume 3, février 2000

LAI99

Charlie Lai, Li Gong, Larry Koved, Anthony Nadalin, Roland Schemers. User Authentication and Authorization in the Java Platform. 15th Annual Computer Security Applications Conference. Phoenix, AZ, Decembre 1999

WALL97

Dan S. Wallach, Dirk Balfanz, Drew Dean, Edward W. Felten. Extensible Security Architectures for Java. Technical report. Department of Computer Science Princeton University. 1997

LAND81

Landhwehr C. E. Formal models for computer security. ACM Computing Surveys. Volume 13, num 3, 1981

GONG97

Li Gong, Marianne Mueller, Hemma Prafullchandra, Roland Schemers. Going Beyond the sandbox: An overview of the new Security Architecture in the Java Development Kit 1.2. USENIX Symposium on Internet Technologies and Systems. Monterey, California, Decembre 1997

AHAD92

Ahad R. and All. Supporting access control in an object-oriented database language. 3rd Int. Conf. Extending Database Technology (EDBT). 1992

RATI

Rational Software Corporation. Rational Rose 98i Using Rose.

SAND97

Ravi S. Sandhu. Role-Based Access Control. Laboratory for Information Security Technology. 1997

GAVR98

Serban I. Gavrila, John F. Barkley. Formal Specification for Role Based Access Control User/Role and Role/Role Relationship Management. 3rd ACM Workshop on Role-Based Access Fairfax VA. 1998.

7 Annexe Le fichier RBACe.dtd contient une définition de la structure du fichier XML obtenu après le traitement du fichier XMI représentant le méta modèle UML du modèle de l’application.