Des cas d'utilisation en UML la gestion de rles dans un systme d'information

Gilles Goncalves, Fred Hmery

LABOGP, Universit d'Artois, Technoparc, zone Futura 62400 Bethune{goncalves, hemery}@univ-artois.fr, Tel : 03 21 63 71 64, Fax : 03 21 61 17 80

Rsum :
Nous proposons dans cet article une mthode qui dtermine les rles qu'un utilisateur sera susceptible de jouer dans un S.I. (systme d'information) et qui permet de dduire les permissions qui seront associes chaque rle. Cette approche est base sur l'utilisation d'une mthode de conception oriente objet associe au langage UML. Cet article est compos de la manire suivante: dans une premire partie, nous indiquerons les avantages de btir les rgles qui rgissent la politique de scurit au niveau de la conception du S.I. Dans une deuxime partie, nous dcrirons comment les concepts de base introduits dans le modle RBAC (Role Based Access Control) peuvent tre obtenus partir d'une description du systme d'information en UML, c'est dire l'ensemble des rles et leurs relations et les permissions associes. En conclusion nous indiquons comment, partir d'une plate forme d'valuation, nous pouvons mettre en place un contrle d'accs efficace en utilisant les informations saisies dans la phase de conception du S.I.

Mots-cls :
scurit des systmes d'information, contrle d'accs bas sur la notion de rle, conception oriente objet, langage UML

Abstract :
We propose in this paper a methodology to create roles played by users of an IMS (Information Management System). The proposed approach is based on the UML description of the IMS. The paper is composed as follows. In a first part, we describe our main motivations when starting this work. A second part shows how basic concepts found in a RBAC (Role Based Access Control) model can be derived in an UML design. In a third part, we give a means to create roles starting from an UML description of an IMS. We conclude in a last part, by giving a description of our validation platform we want to realize.

Keywords :
security, role based access control, information system design, UML language

1 Motivation
Les Systmes d'information des entreprises sont considrs de plus en plus comme une arme stratgique par les dcideurs. De nouvelles organisations (i.e. Rseaux d'entreprises, entreprises tendues, entreprises virtuelles) se mettent en place afin d'accrotre la ractivit et la flexibilit des entreprises. Pour ce faire, les entreprises sont amenes de plus en plus souvent partager une partie de leur S.I. (Systme d'Information) avec leurs partenaires privilgis (i.e. Sous-traitant, fournisseurs, clients) si elles veulent conqurir de nouvelles parts de march. Cette ouverture est maintenant facilite par l'utilisation des nouvelles technologies d'information et de communication que sont l'Intranet, l'Extranet, le commerce lectronique, etc. Il devient primordial de protger le systme d'information contre toutes modifications abusives ou encore contre les accs non autoriss[SAND94].

Pour garantir une utilisation cohrente du S.I., trois techniques sont couramment utilises: l'authentification base sur l'identit de lutilisateur; le contrle d'accs qui dtermine les permissions de chaque utilisateur identifi et authentifi; et enfin le traage de l'accs au systme d'information.

Dans cet article nous allons nous intresser plus particulirement la gestion du contrle d'accs. Le contrle d'accs est utilis pour limiter les possibilits d'utilisation du systme d'information par les utilisateurs autoriss. Dans ce but, chaque utilisateur est associ un profil d'utilisation du systme d'information. Ce profil reprsente la liste des permissions qui sont accordes l'utilisateur. La gestion des utilisateurs et de leurs droits d'accs est ralise par un administrateur charg de la mise en place de la politique de scurit dfinie par l'entreprise. Les concepts de base d'une mthode de contrle d'accs sont les sujets (utilisateurs ou processus) qui accdent aux objets (donnes ou services) en utilisant un mode d'accs (lecture, criture, excution). Deux phases sont gnralement distingues pour mettre en place un contrle d'accs 1. une phase d'laboration de l'ensemble des rgles qui dfinissent la politique de scurit de l'entreprise; et 2. une phase d'implmentation de l'ensemble des mcanismes pour mettre en place les rgles prcdentes. La matrice de contrle d'accs [LAN81] est l'une des implmentations les plus connues d'un systme de contrle d'accs. Deux modles de politique de scurit sont principalement utiliss: la politique discrtionnaire [WOOD79]; et la politique mandataire [BILA77],[BELL75].

Dans la politique discrtionnaire, les rgles expriment quels sont les types d'accs autoriss par utilisateur et par objet. La propagation des droits d'accs d'un utilisateur un autre est souvent base sur la notion de propritaire de l'objet. La flexibilit d'utilisation d'une telle politique de contrle d'accs en fait l'outil privilgi dans les environnements commerciaux et/ou industriels. L'inconvnient majeur de cette politique est qu'elle ne gre pas le contrle de flux. Le contrle d'accs peut tre mis en dfaut par l'utilisation abusive de la dlgation des droits. Pour rsoudre ce problme la politique mandataire peut tre utilise. Cette politique est base sur la classification des objets et des sujets. Le niveau de scurit associ un objet reflte le niveau de sensibilit de l'information contenue dans l'objet alors que le niveau de scurit associ un sujet reprsente le niveau de confiance qu'accorde le systme d'information au sujet. Ce type de politique est adapt aux environnements gouvernementaux ou militaires o la classification des sujets et des objets est clairement identifies par des hirarchies rigoureuses. Le modle de contrle d'accs bas sur la notion de rle (Role Based Access Control, RBAC) fait l'objet depuis quelques annes d'une attention particulire et il est considr comme une alternative aux traditionnels contrles d'accs de type discrtionnaire et mandataire. Les concepts de bases que l'on retrouve dans RBAC sont dduits des systmes multi-utilisateurs et multiapplications des systmes des annes 1970. Au lieu d'affecter directement les permissions aux utilisateurs, elles sont affectes aux rles dans un premier temps. Un rle reprsente une comptence ou une autorit vis vis du systme d'information. La gestion des permissions est simplifie puisque le nombre de rles est rduit par rapport au nombre d'utilisateurs, de plus leurs comptences et/ou autorits voluent moins vite que les acteurs de l'entreprise. Notre tude propose de faciliter l'identification des rles qui seront utiliss dans un S.I. Nous associons chaque rle une liste de permissions. Enfin nous dfinissons les relations qui existent

entre les rles. Pour raliser ce travail nous utilisons le langage UML associ une mthode de conception oriente objet. L'intrt de cette approche est de prendre en compte simultanment les aspects conceptuels de la cration du S.I. et de son schma de scurit associ. Une consquence de cette approche est de bien sparer les aspects conceptuels du modle de scurit de sa mise en uvre sur une plate-forme particulire. Dans la section suivante nous montrons les similitudes qui existent entre les concepts manipuls dans le langage UML et le modle de contrle d'accs RBAC.

2 Relations entre le modle RBAC et le langage UML

Le modle RBAC est compos de trois entits: un ensemble d'utilisateurs U qui vont interagir avec le systme d'information; un ensemble de rles R qui reprsentent les fonctions ou les responsabilits identifies dans l'organisation modlise; un ensemble de permissions P qui indiquent un mode d'accs particulier sur un ou plusieurs objets du systme d'information.

Il est important de clairement identifier l'ensemble des rles qui vont interagir avec le S.I. Gnralement un rle reprsente une tche qui intervient dans un ou plusieurs processus de l'organisation. Un rle peut aussi tre identifi comme une suite de fonctions qui seront excutes par un mme acteur de l'entreprise. Un rle devra donc tre associ un certain ensemble de permissions lui permettant d'excuter les fonctions et d'accder aux donnes qui seront manipules par ces fonctions. Cela nous permettra d'associer les permissions chacun des rles (relation P-R de la figure 1). L'tape suivante consiste numrer les rles qu'un utilisateur doit possder en fonction de ses responsabilits et de ses comptences vis vis du S.I. (relation U-R de la figure 1).
User(U) 1 * * Role(R) * * * Permission(P)

* Session(S) *

figure 1 Le modle RBAC La figure 1 reprsente un diagramme de classes dans le langage UML qui nous montre les relations qui existent entre les entits du modle RBAC. Une troisime relation (la relation R-R) encore appele relation d'hritage, a t introduite par R.S. Sandhu [SAND96] pour les rles. Cette relation entre rles dfinit une hirarchie de rles qui est trs importante pour reflter la structure de l'organisation mise en place dans une entreprise (voir figure 2). Par la relation d'hritage le rle le plus spcialis dispose de l'ensemble des permissions des rles plus gnraux.

Directeur

Responsable Module Pratique

Responsable Module Thorique

Enseignant

figure 2 hirarchie de rles L'ensemble des relations de la figure 1 ont une multiplicit de type N-N. Dans une entreprise, un utilisateur peut avoir plusieurs responsabilits. Quand un utilisateur se connecte sur une machine il lance une session de travail sur le S.I. Durant la session, l'utilisateur a la possibilit d'activer un ou plusieurs rles pour lesquels il est membre. L'administrateur du S.I. a la possibilit de spcifier des contraintes qui stipulent par exemple que deux rles ne peuvent pas tre actifs en mme temps dans une mme session. Il existe galement des permissions particulires qui permettent de modifier les ensembles U, R, P et leurs relations, elles sont dites administratives. Elles sont en relation avec des rles dits administratifs. Le langage UML [BOOC99] permet au concepteur d'exprimer le rsultat de sa conception dans un formalisme standardis et qui pourra tre repris dans d'autres ateliers de gnie logiciel. En UML le S.I. peut tre reprsent sous diffrents modles. Ces modles sont autant de points de vues sur le S.I. Dans cet article, nous allons nous intresser plus particulirement au modle logique qui regroupe en particulier les diagrammes de cas d'utilisation et d'interactions. Le concept d'acteur introduit dans les diagrammes de cas d'utilisation est trs proche du concept de rle dans le systme RBAC. En UML, un acteur est dfini comme un ensemble de rles qu'un utilisateur va pouvoir utiliser pour interagir avec le S.I. Il reprsente une catgorie d'utilisateurs qui partagent les mmes fonctions ou activits dans une organisation. Une instance du concept d'acteur est un utilisateur qui interagit avec le systme. Dans une phase de conception il n'est pas ncessaire d'indiquer quels sont les utilisateurs physiques qui vont rellement utiliser les rles. Il apparat plus opportun didentifier l'ensemble des acteurs et par l-mme, dterminer l'ensemble des rles utiliss dans le S.I. Donc, nous ne dvelopperons pas la relation U-R introduite dans le modle RBAC. Notre tude porte dans un premier temps sur l'identification des rles d'une manire automatique. Les diagrammes de cas d'utilisation vont nous aider raliser ce travail. Dans la phase d'exploitation, l'administrateur du S.I. n'aura plus qu' associer les utilisateurs physiques aux diffrents rles dans un second temps. Un acteur interagit avec le systme au travers de cas d'utilisation. Chaque cas d'utilisation reprsente un service ou une fonction que le S.I. va rendre accessible aux utilisateurs. Si l'on considre qu'un cas d'utilisation est une fonction par laquelle il est possible d'interagir avec le systme alors nous pouvons indiquer l'ensemble des fonctions qui seront ncessaires pour l'excution d'un rle. La relation entre un acteur et un cas d'utilisation est symbolise par un lien. Un rle peut tre vu comme un ensemble de fonctions. Dans notre proposition, nous avons donc modifi le modle RBAC pour nous permettre d'intgrer ce nouveau composant (voir figure 3).
User(U) 1

* * Role(R) * *

* *

* * Fonction(F)

* *

* Permission(P)

Session(S)

figure 3 Extension du modle RBAC Nous pensons que ce niveau supplmentaire apportera plus flexibilit dans la gestion de la scurit. Supposons qu'une nouvelle organisation soit mise en place dans une entreprise et qu'il s'avre ncessaire de redistribuer diffremment les fonctions de chacun des acteurs, la seule

chose faire pour l'administrateur sera de modifier les liaisons entre les rles et les fonctions en tenant compte de la nouvelle rpartition des fonctions. Les utilisateurs auront toujours les mmes rles avec des fonctions associes diffrentes. De mme si une fonction volue dans lentreprise, limpact des modifications effectues sur les privilges sera transparent pour les rles qui intgrent cette fonction. Nous introduisons deux nouvelles relations au modle RBAC. La relation P-F qui consiste associer des permissions aux fonctions et la relation F-R qui associe les fonctions aux rles. Un rle est donc vu comme un ensemble cohrent de fonctions qui sont matrialises dans le langage UML par des cas d'utilisation. Un cas d'utilisation synthtise une collaboration entre objets qui est dcrite dans les diagrammes d'interactions (diagrammes de squence et diagrammes de collaboration). Chaque cas d'utilisation peut tre dcrit par une ou plusieurs collaborations. Une collaboration est dcrite par une ou plusieurs interactions. Un diagramme d'interactions reprsente un ensemble d'objets qui cooprent en changeant des messages (voir figure 4).

:Enseignant :FSaisie
affiche()

:ListeCtrl

:ListeEtudiant

:ListeEval

:Eval

getCtrl(:Enseignant) getEtudiant(:Crtl) getEval(:Etudiant,:Crtl) getValeur() setValeur()

*[i:=1..nbCtrl] valideSaisie()

figure 4 Interactions entre objets Un message dclenche dans l'objet rcepteur l'activation d'une mthode particulire. Dans ce travail, nous nous basons sur un modle de scurit de type Iris [AHAD92] dans lequel attributs et mthodes d'un objet sont encapsuls dans des fonctions. Tout accs l'interface d'un objet est contrl par rapport au droit d'excution de la fonction correspondante que possde le sujet sur cet objet. Le modle d'accs consiste alors exprimer pour chaque sujet la liste des fonctions qu'il est autoris appeler directement ou indirectement. Le seul mode d'accs considr ici est le droit d'excution qui permet l'excution d'une mthode sur un objet. Par une analyse des diagrammes d'interactions prsents dans le mtamodle du langage UML, nous pouvons dterminer les permissions ncessaires l'excution de mthodes correspondantes au cas d'utilisation [ORAN99]. Ces permissions seront associes la fonction remplie par le cas d'utilisation (i.e. la relation P-F). La relation d'hritage entre rles (i.e. la relation R-R) peut tre facilement obtenue en se rapprochant de la relation de gnralisation entre acteurs. L'acteur spcialis pourra interagir avec les fonctions et/ou les cas d'utilisation associs avec l'acteur plus gnral.
Directeur

Responsable Unit Thorique

Responsable Unit Pratique

Enseignant

figure 5 Relations entre acteurs

Dans l'exemple de la figure 5, l'acteur Directeur pourra utiliser les fonctions qui sont associes aux acteurs Enseignant, Responsable Unit Pratique et Responsable Unit Thorique. Trois autres types de relation entre cas d'utilisation peuvent tre identifies. En effet le strotype include permet d'isoler une fonction qui sera utilise plusieurs reprises par d'autres cas d'utilisation, le strotype extend identifie un scnario particulier. Enfin la relation de gnralisation entre cas d'utilisation permet de prciser une fonction abstraite le plus souvent qui est spcialise en fonction d'un contexte particulier. Pour l'ensemble de ses relations nous tudierons leurs incidences sur la politique de scurit. La section suivante prsente comment, partir d'un parcours du mtamodle UML, il est possible de dduire les rles d'un S.I., les relations qui les relient, leurs relations avec les fonctions du S.I. ainsi que les permissions associes.

3 Cration des rles

Les Ateliers de gnie logiciel actuels comme Rational Rose 98i [ROSE98] utilisent des mthodes de conception orientes objet, avec comme langage de description de leur modlisation le langage UML. Ce langage s'inscrit dans l'architecture en quatre niveaux introduite par l'OMG[OMG99] et permet de dfinir prcisment les concepts utiliss pour reprsenter un modle. Dans notre tude, nous utilisons le mtamodle du langage UML pour dfinir les rles du modle RBAC, les fonctions (introduites dans la section prcdente) qui seront utilises par les rles pour interagir avec le S.I. et enfin les permissions ncessaires pour que l'excution de ces fonctions soit possible. Comme nous l'avons indiqu dans la section prcdente, les diagrammes de cas d'utilisation donnent la liste des acteurs qui vont interagir avec le S.I. et indiquent les cas d'utilisation qu'ils utilisent pour cela. L'analyse des diagrammes de cas d'utilisation va nous permettre de dfinir de manire automatique l'association F-R. Il sera possible de la mme manire de dduire la relation F-F en utilisant la relation de gnralisation entre cas d'utilisation et la relation R-R en utilisant la relation de gnralisation entre les acteurs. La description de chaque cas d'utilisation donne dans les diffrents diagrammes d'interaction (diagramme de squence et diagramme de collaboration) nous indique en particulier les messages qu'il est ncessaire d'changer entre les objets pour raliser une fonction du S.I. Chaque message dclenche l'excution d'une mthode dans l'objet qui le reoit. Si nous ajoutons la permission excute sur chaque mthode associe l'envoi d'un message dcrit dans un diagramme d'interaction, il nous suffit de faire l'union de l'ensemble des permissions et nous obtiendrons de manire automatique la relation P-F. Dans la suite de cette section nous allons expliquer comment nous utilisons le mtamodle qui dcrit le langage UML pour raliser une implmentation du modle RBAC. Nous commenons par donner notre dfinition de la notion de permission. Aprs avoir indiqu la mthode utilise pour obtenir l'ensemble des rles et les fonctions auxquelles ils sont associs, nous indiquerons comment nous associons chaque fonction l'ensemble minimal des permissions qu'elle doit possder pour pouvoir s'excuter. Enfin, nous prsenterons comment, partir des relations entre cas d'utilisation d'une part et les relations entre des cas d'utilisation et les acteurs d'autre part, nous pouvons en dduire les relations entre les rles et les fonctions. Pour illustrer notre prsentation, nous allons utiliser un exemple simple de gestion d'valuations des tudiants. Dans ce systme d'information, un tudiant peut visualiser l'cran ou la suite d'une impression, son bulletin de notes (et uniquement le sien). Un enseignant peut crer de nouvelles valuations pour un groupe d'tudiants. Un enseignant peut modifier uniquement les

valeurs des valuations qu'il a cres. Le directeur de la formation peut modifier toutes les valuations.

3.1 Dfinition d'une permission

Dans le modle RBAC [SAND97a, SAND97b], une permission reprsente une autorisation d'accs d'un type particulier sur un objet ou un ensemble d'objets protgs par le systme de scurit. Nous supposons dans notre tude que la politique de scurit est de type monde ferm, c'est dire que l'autorisation d'accs une entit est conditionne par une permission donne explicitement. L'entit dans notre cas est un objet du S.I. et chaque attribut d'un objet est suppos ne pas tre accessible de l'extrieur en rfrence au principe d'encapsulation du paradigme objet. Donc l'attribut n'est accessible qu'en envoyant un message l'objet qui le contient. Le message va dclencher l'excution d'une mthode de l'objet destinataire. Comme dans le modle de scurit utilis dans IRIS [AHAD92], une permission doit indiquer le droit d'excuter la mthode qui accde aux donnes d'un objet. Des contraintes peuvent tre ajoutes pour indiquer que la permission est valide pour un sous-ensemble des instances d'une classe. Nous formalisons la dfinition d'une permission par le triplet (o,m,C), avec o un objet, m une mthode de l'objet et C un ensemble de contraintes associes la permission. Dans cet article, nous ne parlerons pas des contraintes qui font l'objet d'un travail en cours, donc nous simplifierons cette dfinition formelle par = (o,m). Dans la figure 6, le message getValeur() est envoy de l'objet Robert:Etudiant vers l'objet e:Evaluation. L'tudiant Robert doit avoir le droit d'excuter la mthode getValeur() sur l'objet e.
Robert: Etudiant
getValeur()

e: Evaluation

figure 6 Envoi de message

3.2 Obtention des rles du systme d'information

Pour obtenir l'ensemble des rles qui seront utiliss dans la description du S.I., nous allons examiner sa description dans le langage UML. Le mtamodle qui dcrit la smantique du langage nous permet de retrouver la dclaration de l'ensemble des acteurs. Plutt que de donner l'algorithme de parcours du mtamodle, nous allons utiliser le langage OCL (Object Contraints Language) [UML99] qui est associ UML et qui permet de spcifier des contraintes associes aux concepts utiliss dans le langage. De plus il permet d'exprimer trs facilement des actions de navigation dans le mtamodle UML. Dans la syntaxe OCL, rechercher l'ensemble des acteurs d'un modle revient ajouter une opration tousLesActeurs au concept Model du mtamodle UML. On crira alors:
context modele: Model tousLesActeurs : Set(Actor) tousLesActeurs = modele.contents.select(elem | elem.oclIsKindOf(Actor))

La premire ligne indique que l'on se place dans le contexte d'une variable modele qui reprsente le concept Model du mtamodle UML. La seconde ligne indique que le type de rsultat de l'opration sera un ensemble d'lments Actor. Enfin, la dernire ligne indique

l'opration utilise pour retrouver l'ensemble des acteurs. La variable modele reprsente l'accs la racine du modle qui conceptualise notre systme d'information. Le diagramme de cas dutilisation prsent dans la figure 7, contient trois acteurs : Etudiant, Enseignant, Directeur. Ces trois acteurs seront identifis comme trois rles dans le modle RBAC (voir figure 8).
Modification de toutes Evaluations Modification Evaluations

Directeur

<<include>> Modification de ses Evaluations <<extend>> <<include>>

Saisie Evaluations Enseignant

Vrification Utilisateur

<<extend>>

Cration Evaluation <<include>>

Directeur Enseignant Etudiant

Visualisation Etudiant

Etudiant

figure 7 Gestion des valuations

figure 8 Rles de lapplication gestion des valuations

3.3 Relation de gnralisation entre rles

Un diagramme de cas d'utilisation peut contenir des acteurs lis par une relation de gnralisation. Dans ce cas l'acteur spcialis est en relation avec l'ensemble des cas d'utilisation de l'acteur plus gnral tant donn que l'acteur spcialis peut prendre la place de l'acteur plus gnral. Ce type de relation permet de modliser plus facilement la structure relle de la hirarchie (en terme d'autorit ou de responsabilit) d'une organisation. Cette relation de gnralisation correspond la relation d'hritage du modle RBAC et elle peut tre dduite directement des donnes saisies dans le diagramme de cas d'utilisation. Dans la figure 7, l'acteur Directeur spcialise l'acteur Enseignant et interagit avec le cas d'utilisation spcifique Modification Evaluations. On peut indiquer avec le langage OCL les concepts qui seront utiliss pour dtecter ce type de relation entre acteurs.
Context a : tousLesActeurs parentActors : Set(Actor) parentActors = a.generalization.parent.select(p | p.oclIsKindOf(Actor))

3.4 Affecter les permissions aux fonctions

Comme nous l'avons indiqu dans l'introduction, une fonction dans le modle tendu RBAC correspond un cas d'utilisation dans le langage UML. Nous allons associer chaque cas d'utilisation un ensemble minimal de permissions qui permettra son excution. Un cas d'utilisation est une description d'un ensemble de squences d'actions pouvant inclure des variantes. Chaque squence reprsente une interaction de l'acteur avec le S.I. En UML la ralisation d'un cas d'utilisation est dcrite par une ou plusieurs collaborations entre objets. Une

collaboration est une socit de classes qui cooprent pour proposer un comportement global plus riche que la somme des comportements pris un par un. Une collaboration contient une partie structurelle qui indique les classes qui participent et une partie comportementale qui indique les aspects dynamiques de la collaboration. La partie structurelle est dcrite dans un ou plusieurs diagrammes de classes et la partie comportementale est dcrite dans les diagrammes d'interactions. Une interaction dcrit le comportement des objets en prcisant l'ensemble des messages qu'ils changent. Un message matrialise la spcification d'une communication entre deux objets. Le type de message le plus courant correspond l'appel d'une mthode (call) dans l'objet destinataire. Les autres types de message permettent de renvoyer un rsultat (return), de transmettre un vnement (send), de crer une nouvelle instance (create) et enfin de dtruire l'objet destinataire (destroy). Dans le contexte de notre tude qui s'intresse plus particulirement au contrle d'accs, nous pouvons ajouter qu'un acteur ne pourra excuter une interaction que si l'ensemble des messages qui sont indiqus dans le diagramme d'interactions peuvent tre excuts. Cela signifie que l'acteur doit avoir les permissions pour excuter les oprations qui seront appeles par l'envoi de messages. Dans une interaction chaque message msg(o1,o2,m), envoy d'un objet o1 vers un objet o2 pour excuter une mthode m, doit tre associ une permission qui autorisera l'excution de la mthode m sur o2. L'ensemble des permissions P(i) pour une interaction i correspond : P(i) = {|(o,m) = (o1,o2,m)} avec la fonction qui associe une permission un message. Comme expos prcdemment, une collaboration est dcrite par un ensemble d'interactions. L'ensemble des permissions qui doivent tre associes une collaboration dcrite par un ensemble d'interactions correspond l'ensemble P() tel que P( ) = 7 P(i ) . Enfin l'ensemble des permissions P() qui doivent tre associes un cas d'utilisation (une fonction dans notre extension du modle RBAC) dcrit par un ensemble M de collaborations i vrifie la relation suivante: P( ) = 7 P( i ) . L'algorithme de recherche de P() peut tre obtenu en faisant un
i M
i

parcours du mtamodle associ UML. Les instructions suivantes en langage OCL permettent de dcrire comment la navigation dans le mtamodle UML peut tre conduite pour obtenir l'ensemble des messages changs (et les oprations excutes) pour raliser le cas d'utilisation .
context : UseCase collaborations : Set(Collaboration) collaborations = .collaboration context i: collaborations interactions: Set(Interaction) interactions = i.interaction context interactions messages: Set(Message) messages = self.message context messages action = self.action receiver = self.receiver sender = self.sender context action operation = self.oclIsTypeOf(CallAction).operation

La figure 9 reprsente un des diagrammes de squences qui dcrit le comportement du cas d'utilisation Visualisation Etudiant. Il indique l'ensemble des objets et des messages changs. Tous les messages sont annots par le nom de la mthode appele. L'ensemble P(i) contient les permissions:
{ (affiche, : FVisu), (getCtrl, :ListeCtrl), (getEval, :ListeEval), (getValeur, :Eval)}

:Etudiant
affiche()

:FVisu

:ListeCtrl

:ListeEval

:Eval

getCtrl(:Etudiant) *[i:=1..nbEtdt] getEval(:Etudiant,:Ctrl) *[i:=1..nbEtdt] getValeur()

figure 9 Diagramme d'interactions

3.5 Les relations entre cas d'utilisations

Dans un diagramme de cas d'utilisation, les cas d'utilisation peuvent tre relis par une relation de gnralisation ou de dpendance (inclusion ou extension). La relation de gnralisation entre cas d'utilisation signifie que le cas d'utilisation pre peut tre substitu par le cas d'utilisation fils. Dans l'exemple donn dans la figure 10, si un tudiant veut imprimer ses valuations, il doit utiliser le cas d'utilisation Visualisation sur Papier par l'Etudiant. L'acteur Etudiant est donc considr directement en relation avec les cas d'utilisation fils par transitivit de la relation de spcialisation.

Etudiant Extrieur

Visualisation lEcran par lEtudiant

Visualisation par Etudiant

Etudiant

Visualisation sur Papier par lEtudiant

figure 10 La gnralisation entre cas d'utilisation

Visualisation par ltudiant Etudiant

<<include>> Authentification Utilisateur

Saisie Evaluation Enseignant

<<include>>

figure 11 Dpendance d'inclusion entre cas d'utilisation La relation de dpendance d'inclusion est utilise pour viter de dcrire plusieurs fois les mmes collaborations d'objets. Cette relation peut aussi tre vue comme un exemple de dlgation, c'est dire que le cas d'utilisation qui est inclus reprsente une responsabilit particulire dans le S.I. qui pourra tre utilise par les autres cas d'utilisation qui en auront besoin. Par exemple dans la figure 11, les acteurs Enseignant et Etudiant doivent pouvoir utiliser le cas d'utilisation Authentification Utilisateur pour accder respectivement aux cas d'utilisation Saisie Evaluation et Visualisation par ltudiant. Ces acteurs doivent donc tre considrs comme en relation directe avec le ou les cas d'utilisation inclus.
Cration Evaluation <<extend>> Saisie Evaluation <<extend>> Enseignant Modification Evaluation

figure 12 Dpendance d'extension entre cas d'utilisation La relation de dpendance d'extension entre cas d'utilisation indique que le cas d'utilisation de base va ventuellement tre tendu par le cas d'utilisation la base de la relation. Ce cas d'utilisation peut correspondre la description du traitement d'une exception. Dans la figure 12, l'acteur Enseignant qui saisit une valuation peut tre amen dans un premier temps, crer cette valuation avant de pouvoir la modifier. Un acteur doit donc tre considr comme connect avec les cas d'utilisation qui tendent celui avec lequel il est connect directement. A la suite de l'analyse des relations qui peuvent tre utilises entre cas d'utilisation, nous pouvons en dduire l'ensemble des cas d'utilisation qui sont en relation directe ou indirecte avec un acteur. Les instructions OCL qui suivent, montrent comment on peut obtenir cet ensemble en parcourant le mtamodle UML. Avec dans un premier temps la recherche des cas d'utilisation relis directement :
context a: tousLesActeurs casUtilActeur : Set(UseCase) casUtilActeur = a.associationEnd.select(c|c.type.oclIsTypeOf(UseCase))

Puis en y incluant les cas d'utilisation en relation de gnralisation et de dpendance avec les cas d'utilisation prcdemment rpertoris.

context u: casUtilActeur toutCasUtilActeur: Set(UseCase) toutCasUtilActeur = u.clientDependency.sterotype.name ==``include''and u.clientDependency.select(c|c.supplier.oclIsTypeOf(UseCase)).supplier) -> union(self.casUtilActeur) -> union (u.supplierDependency.stereotype.name == ``extend''and u.supplierDependency.select(c|c.supplier.oclIsTypeOf(UseCase)).client) ->union (self.casUtilActeur) -> union(u.specialization.select(c|c.parent.oclIsTypeOf(UseCase)))-> (self.casUtilActeur)

Dans notre S.I. l'ensemble casUtilActeur pour l'acteur Enseignant sera compos des cas d'utilisation suivants: par association directe Saisie valuation Visualisation par tudiant Cration d'valuation Modification de ses valuations Validation d'utilisateur Modification des valuations

par relation de dpendance d'extension

par relation de dpendance d'inclusion par relation de gnralisation

L'ensemble de ces cas d'utilisation dfinit l'ensemble des fonctions ncessaires pour que le rle Enseignant dduit de l'acteur Enseignant puisse s'excuter. En donnant l'ensemble des fonctions, nous sommes maintenant capables de dduire le profil minimal des permissions qu'il faut accorder un rle pour qu'il puisse s'excuter.

4 Conclusion
Nous avons montr dans cet article comment nous pouvions dduire les rles d'un S.I. en nous basant sur la conception et plus particulirement le mtamodle du langage UML. En analysant les liens des acteurs avec les cas d'utilisations nous avons pu en dduire le profil minimal des permissions qu'il faut affecter chaque rle pour qu'il puisse s'excuter. Actuellement nous implmentons les algorithmes de parcours de mtamodle UML. Les donnes du mtamodle UML sont obtenues partir d'une saisie de la description d'un S.I par un concepteur dans un atelier de gnie logiciel. Une plate forme d'valuation est en cours de ralisation, elle permettra de vrifier que l'on peut utiliser le travail du concepteur pour mettre en oeuvre les rgles d'une politique de scurit. Notre plate forme est base sur l'utilisation du SGBDOO ObjectStore et le systme de scurit associ au JDK1.2[SCOT98].

Rfrences :

[BOOC99]: [ORAN99]: [OMG99]: [UML99]: [SCOT98]: [ROSE98]:

Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999 Vilma Oranci, Du cas d'utilisation aux profils utilisateurs SGBD, Mmoire de DEA Informatique de Lille I, 1999 OMG, Meta Object Facility (MOF) Specification Version 1.3RTF, 27 September, 1999 OMG, OMG Unified Modeling Language Specification, 1999 Scott Oaks, Java Security, O'Reilly, 1998 Rational Rose 98i Using Rose, Rational Software Corporation

[SAND97a]: Ravi Sandhu, role-Based Access Control, Laboratory of Information Security Technology, Fairfax, 1997 [SAND97b]: Ravi Sandhu, Venkata Bhamidipati, The ARBAC97 Model for Role-Based Administration of Roles: Preliminary Description and Outline, 2nd ACM Workshop on Role-Based Access Fairfax VA, 1997 [SAND96]: [SAND94]: [AHAD92]: Ravi Sandhu Edward J. Coyne Hal L. Feinstein Charles E. Youman, Role based access control models, IEEE Computer, 1996. Ravi Sandhu, Pierangela Samarati, Access Control: Principles and Practices, IEEE Communication, 1994. Ahad R. and All, Supporting access control in an object-oriented database language, 3rd Int. Conf. Extending Database Technology (EDBT), Lecture Notes in Computer Science, 1992 Landhwehr C. E., Formal models for computer security, ACM Computing Surveys, 1981.

[LAND81]:

[WOOD79] : Wood C, Summers R.C. and Fernandez E.B., Authorization in multi-level database models, Information Systems, Pergamon Press, 4(2) 1979 [BIBA77]: [BELL75]: Bila K.J., Integrity Considerations for secure Computer Systems, MTR-3153, Mitre Corporation Bedford Mass, 1977 Bell D.E., LaPadula L.J., Secure Computer Systems: Unified Exposition and Multics Interpretation, MTR-2997, Mitre, Bedford, Mass, 1975