12

Formalisation d’une Session Collaborative Sécurisée

Mohamed Amine MADANI, Mohammed ERRADI Networking and Distributed Systems Research Group, SIME Lab

University Mohammed V-Souissi, ENSIAS Rabat, Morocco

madani.medamin@gmail.com, erradi@ensias.ma

Résumé—Les applications collaboratives sont des applications distribuées à travers lesquelles plusieurs utilisateurs peuvent interagir et partager les mêmes objets pour atteindre un objectif commun. Ainsi la sécurité des interactions entre les membres d’un groupe collaboratif constitue un défi majeur auquel il faut faire face. Ceci afin d’assurer des interactions sécurisées et offrir un bon degré de confiance dans l’utilisation d’une application collaborative. Ce travail présente un mécanisme de sécurité lors d’une session collaborative, appelé « sécurité à base de session ». L’approche proposée est basée sur le modèle de contrôle d’accès OrBAC, en l’augmentant d’un niveau intermédiaire appelé « Niveau Session » entre le niveau organisationnel et le niveau concret du modèle OrBAC. Ensuite, une démarche formelle à base de règles et d’arbres de permissions est proposée pour être intégrée à ce modèle, afin de contrôler l'accès au niveau des sessions collaboratives. Enfin, nous présentons une spécification formelle de notre approche pour une application collaborative distribuée pour le télédiagnostic dans le domaine de la neuroscience. Cette spécification est implémentée et vérifiée à l'aide du langage Prolog (Programmation Logique).

Mots-clés-Contrôle d’Accès, Modèle OrBAC, Système Collaboratif, Session Collaborative Sécurisée

I. INTRODUCTION Les applications collaboratives sont des applications distribuées à travers lesquelles plusieurs utilisateurs peuvent interagir et partager les mêmes objets pour atteindre un objectif commun. Vu la sensibilité et le caractère confidentiel des donnés échangées, les interactions entre les membres du groupe collaboratif doivent être sécurisés.

Pour atteindre un niveau de sécurité satisfaisant, il est nécessaire de définir une politique de sécurité correspondant aux besoins de l’application. Cette politique doit garantir les droits d'accès aux données et ressources d'un système en mettant en place des mécanismes d'authentification et de contrôle d’accès lors d’une session collaborative. Dans cet article, nous proposons une nouvelle approche pour sécuriser les échanges lors d’une session collaborative.

Cet article est organisé comme suit : la section suivante, propose un état de l’art des travaux existants. La section 3, présente les concepts de base du modèle OrBAC. LA section 4, décrit notre approche qui est une extension du modèle OrBAC. La section 5, présente une démarche formelle d’intégration de notre approche basée sur l’utilisation de règles et d’arbres de

permissions. Dans la section 6, nous proposons une étude de cas. Enfin, la section 7 conclut ce travail.

II. MOTIVATION ET TRAVAUX EXISTANTS: Les modèles de contrôle d’accès qui existe dans la littérature comme DAC [1], MAC [2], RBAC [3], TBAC [4] ou TMAC [5] ne permettent pas de modéliser des politiques de sécurité spécifiques aux applications collaboratives. Diverses approches ont été proposées traitant cette problématique. Ces approches sont:

� Le modèle Multi-OrBAC [6] (MultiOrganization-Based Access Control) est modèle de contrôle d'accès pour les applications complexes, hétérogènes inter opérables et distribuées, Ce modèle de sécurité est dynamique et adaptable, permettant de spécifier des politiques de sécurité différentes dans chaque organisation.

� Le modèle PolyOrBAC [7,8] est une approche basée sur le modèle de contrôle d’accès OrBAC, et la technologie des services Web, ce qui permet de bénéficier des différents avantages d’OrBAC et des services Web, puis de proposer un modèle de contrôle d’accès collaboratif.

� D'autres travaux traitent l'aspect session, comme le modèle Smatch [9] qui est une approche pour contrôler l'accès de manière dynamique au niveau des sessions. Cependant, ce modèle ne prend pas en considération les sessions collaboratives.

Dans ce travail, nous allons proposer une nouvelle approche basée sur le modèle de contrôle d'accès OrBAC, pour sécuriser les interactions entre les utilisateurs lors d'une session collaborative.

III. MODÈLE DE BASE (ORBAC) Le modèle de contrôle d’accès Or-BAC [10, 11]

(Organization Based Access Control) vise à résoudre certains problèmes rencontrés par les modèles de contrôle d’accès existants et à établir une politique de contrôle d’accès plus abstraite. Il est basé sur les mêmes principes du modèle RBAC en intégrant de nouvelles notions. Il reprend les concepts de rôle, d'activité, de vue et de contexte.

Dans Or-BAC, l'expression d'une politique d'autorisation est centrée sur le concept d'organisation (contrairement à RBAC où la politique d'autorisation est centrée sur le concept de rôle). Une organisation est un groupe structuré d’entités

This work was supported by the Moroccan IT Research Program: CSPT SECOM Project

978-1-4673-1053-6/12/$31.00 ©2012 IEEE

13

actives. Le modèle OrBAC organise les sujets, les objets et les actions respectivement en rôles (comme dans RBAC), vues et activités.

Le modèle OrBAC définit aussi la notion de contexte comme une situation spécifique dans laquelle une règle est valide. OrBAC définit des permissions par la règle de la forme Permission(org,r, v, a, c), où ‘org’ est une organisation, ‘r’ un rôle, ‘v’ une vue, ‘a’ une activité et ‘c’ un contexte. de la même manière on définit les interdictions Interdiction(org, r, v, a, c), les obligations obligation(org, r, v, a, c) et les recommandations recommandation(org, r, v, a, c).

Les sujets, les actions et les objets sont respectivement abstraits en rôles, en activités et en vues, comme le représente (la figure1). Nous obtenons alors une politique de sécurité à deux niveaux (niveau abstrait et niveau concret). Le modèle Or-BAC permet ainsi d‘établir une politique de sécurité abstraite (rôle, activité, vue) indépendante des choix d‘implémentation (sujet, action, objet).

�

Figure 1. Modèle OrBAC.

IV. MODELE ETENDU SESSION-ORBAC () Dans ce chapitre, nous présentons un nouveau modèle basé

sur le principe de la « Session Collaborative », que nous avons appelé Session-OrBAC (figure 2). Ce modèle est étendu du modèle OrBAC, il bénéficie des avantages du modèle OrBAC. L’idée principale du modèle est d’ajouter au modèle OrBAC (Voir le concept du modèle OrBAC dans le chapitre précédent), un nouveau niveau intermédiaire entre le niveau organisationnel et le niveau concret, que nous avons appelé « niveau session » (Voir figure 1), afin de contrôler l’accès lors d’une session collaborative.

Dans ce niveau, nous avons défini des nouvelles entités relatives à la session collaborative comme : le rôle dans la session, la vue dans la session, l’activité dans la session et le contexte dans la session. L’objectif de cette approche est de séparer les propriétés de sécurité définies sur des actions exécutées dans les sessions collaboratives, de celles définies sur des actions exécutées hors d’une session de collaboration, et proposer une politique de sécurité dynamique pour sécuriser les interactions lors d’une session collaborative. Ensuite nous allons définir les différents concepts du modèle étendu Session-OrBAC.

A. Session collaborative La session collaborative est l’entité de base dans notre

modèle, elle désigne une entité abstraite, regroupant un ensemble des utilisateurs (appelés membres de la session), qui accomplissent des tâches spécifiques, en accédant à des ressources partagées pour atteindre un objectif commun. Une session de collaboration est composée d’un ensemble de paramètres :

� Identifiant de la session

� Type de la session

� Membres de la session

� Ressources partagées sur la session

� Comportement de la session (ensemble des états et transitions)

Figure 2. Modèle Session-OrBAC

B. Le rôle dans la session (Rôle_Session) L’entité Rôle_session ‘RS’ est utilisée pour structurer le lien entre le rôle, l’organisation et la session. Elle désigne un ensemble des membres d’une session collaborative jouant le même rôle. Nous introduisons deux relations entre ces entités : � La relation Membre(S1, U, RS) , signifie que l’utilisateur

‘U’ est membre de la session ‘S1’, en jouant le rôle_session ‘RS’.

� La relation Habilite(org, RS, R), signifie que l’organisation ‘org’ habilite l’ensemble des utilisateurs appartenant à l’entité ‘RS’ de jouer le rôle ‘R’.

14

�org Organisations, � u Sujets, � a Actions, � o Objects, � R Rôles, � A Activités, � V Vues �S Sessions, �C Contextes such as C=CO � CS

� RS Rôle_Session, � AS Activité_Session, � VS Vue_Session Si Permission (org, R, A, V, C) �

Habilite (org, RS, R) � Considère (org, AS, A) � Utilise(org, VS, V) � Définit(org, S, CO) � Permission_Session (S, RS, AS, VS, CS)

Si Permission_Session (S, RS, AS, VS, CS) � Membre (S, u, RS) � Exécutée(S, a, AS) � Relatif (S, o, VS) � Définit(S, u, a, o) � EstPermet(u, a, o)

C. L’activité dans la session (Activité_session) L’entité Activité_session correspond à des actions ayant un objectif commun, qui seront exécutées dans une session donnée. Alors on définit l’entité activité_session ‘AS’ comme étant l’ensemble des actions de l’activité ‘A’ qui seront exécutées dans la session S1. Nous introduisons deux relations entre ces entités :

� La relation Exécutée(S1, a, AS), signifie que l’action ‘a’ appartenant à l’entité activité_session ‘AS’, sera exécutée dans la session ‘S1’.

� La relation Considère(org, AS, A), signifie que l’organisation ‘org’ considère que les actions appartenant à l’entité ‘AS’ font partie de l’activité ‘A’.

D. La vue dans la session (Vue_session) L’entité Vue_session désigne un ensemble d’objets (relatifs à une session collaborative) satisfaisant une propriété commune. Autrement dit, vue_session ‘VS’ est un ensemble des objets utilisés par l’organisation ‘org’ dans la vue ‘V’ qui sont relatifs à la session ‘S1’. Nous introduisons deux nouvelles relations entre ces entités :

� La relation Relatif(S1, o, VS) : signifie que l’objet o appartenant à la Vue_Session ‘VS’ est relatif à la session S1.

� La relation Utilise(org, VS, V) : signifie que les objets appartenant à la Vue_Session ‘VS’, sont utilisées par l’organisation ‘org’ dans la vue ‘V’.

E. Le concept contexte : La notion du contexte a été introduite (dans le modèle OrBAC) pour exprimer les circonstances et les conditions concrètes dans lesquelles une organisation attribue des autorisations de réaliser des activités sur des vues. Dans notre approche, le contexte ‘C’ est composé deux types de contexte : le contexte organisationnel ‘CO’ le contexte de la session ‘CS’ (C=CO � CS).

� Le contexte organisationnel ‘CO’ est défini pour exprimer les conditions permettant de générer une permission au niveau session à partir d’une permission organisationnelle. Nous introduisons une nouvelle relation entre l’organisation, la session et le contexte organisationnel : Définit(org, S, CO), signifie que dans l’organisation ‘org’, le contexte ‘CO’ est vrai pour la session ‘S’.

� Le contexte de la session ‘CS’ est introduit pour exprimer les conditions et les situations permettant de générer une permission concrète à partir d’une permission au niveau session. Nous introduisons une nouvelle relation entre la session ‘S’, le sujet ‘u’, l’action ‘a’, l’objet ‘o’ et le contexte de la session ‘Cs’: Définit(S, u, a, o, CS), signifie que dans la session ‘S’, le contexte ‘CS’ est vrai pour le triplet (u, a, o).

F. Expression de politiques de sécurité dans le modèle étendu

La dérivation des droits d’accès (c’est-à-dire l’instanciation des propriétés de sécurité) est formellement exprimée dans la figure ci-dessous (figure3).

Figure 3. Expression de la politique de sécurité

V. DEMARCHE D’INTEGRATION DU MODELE SESSION-ORBAC

Dans cette section, nous présentons une démarche d’intégration de l’approche Session-OrBAC pour spécifier la sécurité d’un système collaboratif distribué. La figure (figure4) décrit la manière de laquelle ce modèle sera appliqué à un tel système.

Figure 4. Démarche d’intégration du modèle Session-OrBAC

Lors de l’initiation d’une session collaborative « session 1 (Id1, Type1) » (dont l’identifiant est ‘Id’ et de type ‘Type1’). Le serveur des permissions organisationnelles OrBAC va générer un fichier XML, comportant l’ensemble des permissions relatives à la session 1 (Id1, Type1). Pour décider si une action (exécutée dans la session) est autorisé ou pas, il suffit d’accéder au fichier ‘Fichier.XML’ relatif à la session 1. Ce fichier sera détruit au moment de la clôture de session.

Notre démarche consiste à définir les permissions organisationnelles, en précisant dans le contexte organisationnel de chaque permission (définie sur des actions

15

� � Extraire(�, Type1) /* Tel que� = {PO1, PO2, …, POn} est l’ensemble des permissions organisationnelles, POi= O-Permission(org, R, A, V, C)*/ /* � = {PO1, PO2, …, POj} (j<=n) sont les permissions organisationnelles définies sur des actions exécutées dans des sessions collaboratives de type ‘Type1’*/ � � Dériver(�, S1) /* � = {P1

S1, P2S1, …, Pj

S1} est l’ensemble des permissions relatives à la session ‘S1’ dérivées à partir de l’ensemble des permissions organisationnelles ‘�’ telle que : Pi

S1 = S1-Permission(S1, RS, AS, VS, CS) )*/

/*L’algorithme qui permet de décider si un utilisateur ‘user’ est autorisé à exécuter une action ‘a’ sur un objet ‘o’, pendant de la session ‘S1’ dans le contexte ‘CS’. � = {P1

S1, P2S1, …, Pj

S1} est l’ensemble des permissions relatives à la session ‘S1’ dérivées à partir des permissions organisationnelles.(telle que : Pi

S1 = S1-Permission(S1, RS, AS, VS, CS) )*/ Si ‘user’ est membre de la session ‘S1’, alors i�1, décision�False Tant que (��Ø) faire On prend une permission Pi

S1

Si (membre(S1, user, RS) � exécutée(S1, a, AS) � relatif(S1, o, VS) � définit(S1, user, a, o, CS)) Alors décision�True, sortir de la boucle Sinon décision� False, i�i+1 FinSi FinTant que Sinon décision� False FinSi Fin

exécutées dans la session) la condition « type de la session ». Alors que les permissions relatives à la session (niveau session) seront dérivées à partir des permissions organisationnelles.

A. Formalisation des permissions organisationnelles Les permissions organisationnelles sont de type PO = O-Permission(org, R, A, V, C), signifie que l’organisation org accorde au rôle ‘R’ la permission de réaliser une action (de l’activité ‘A’) sur la vue ‘V’ dans le contexte ‘C’. On note ‘�’ est l’ensemble des permissions organisationnelles d’une organisation ‘org’ : � = {PO1, PO2, …, POn} tel que n est le nombre des permissions organisationnelles. Dans le niveau organisationnel, on définit deux types des permissions: des permissions définies sur des actions exécutées dans la session et des permissions définies sur des actions exécutées hors de la session. Les permissions relatives à la session (définies dans le niveau session), seront dérivées à partir du premier type (permissions définies sur des actions exécutées dans la session).

B. Formalisation des permissions de niveau session

Figure 5. Génération des permissions relatives à la session S1

Figure 6. Algorithme de décision

Lors de l’initiation d’une session collaborative de type ‘Type1’, le serveur des permissions organisationnelles va extraire à partir de l’ensemble ‘�’ des permissions organisationnelles, le sous-ensemble des permissions qui sont relatives à ce type de session ‘Type1’ (C’est-à-dire les permissions dont le contexte dépend de ce type de session ‘Type1’)(voir figure5). On note � = {PO1, PO2, …, POj} (j<=n), tel que ‘j’ est le nombre des permissions relatives au type de la session ‘Type1’. Enfin, le serveur va dériver des permissions appartenant au niveau session à partir de chaque permission ‘POi’. Par exemple, si on suppose qu’on a trois sessions collaborative ‘S1’, ‘S2’, ‘S3’ de type ‘Type1’, alors les permissions ‘Pi

S1’, ‘PiS2’, ‘Pi

S3’ (appartenant au niveau session) sont dérivées à partir de la permission organisationnelle ‘POi’.

On pose � = {P1S1, P2

S1, …, PjS1} l’ensemble des

permissions relatives à la session ‘S1’ dérivées à partir de l’ensemble �. Tel que Pi

S1 = S1-Permission(S1, RS, AS, VS, CS). Pour décider si un utilisateur ‘user’ est autorisé à exécuter une action ‘a’ sur un objet ‘o’, pendant la session ‘S1’ dans le contexte ‘CS’, nous allons utiliser les permissions appartenant à l’ensemble � (figure 6).

VI. ÉTUDE DE CAS : PROJET TENEMO Dans ce chapitre, on va prendre l’exemple d’une session

collaborative de type ‘télémédecine’ dans laquelle un groupe d’utilisateurs (médecin d’accueil, médecin du Samu, neurologue, Radio-neurologue et Techno-radiologue) collaborent à travers une plateforme collaborative pour le télédiagnostic dans le domaine de la neuroscience (projet TENEMO : Télé-NEuroScience sur une plateforme collaborative Mobile sur Internet), dans l’objectif d’observer et de traiter un malade qui s’est présenté et admis aux urgences d’un hôpital d’accueil (HA) situé à la périphérie de CHU Rabat, avec des troubles de la conscience et des troubles de la motricité.

A. Spécification des règles de sécurité Dans cette partie, nous allons définir les règles de sécurité relatives au travail collaboratif décrit dans l’exemple précédent. Puis nous allons spécifier la permission organisationnelle relative à chaque règle :

1) Règle1 : Seul le médecin (Ahmed) du SAMU est autorisé à inviter le médecin (Mohamed) de HA et le neurologue (Kamal) de CHU à joindre la session collaborative. La permission organisationnelle relative à cette règle : Permission (System_GL, médecin_samu, Envoi, Invitation, C) Le contexte C est défini comme suit, C={CO�CS0} tels que :

� CO : Type(Télémédecine, Session), signifie que la session dans laquelle cette action sera exécutée, doit être de type Télémédecine.

� CS0 : Etat(Initial, Session), signifie que la session doit être dans l’état Initial.

2) Règle2 : Seul le médecin (Mohamed) de HA a le droit de partager le dossier médical du malade concerné dans la session de collaboration. La permission organisationnelle

16

relative à cette règle : Permission (System_GL, médecin_ha, partage, dossier_médical, C). Le contexte C est défini comme suit, C={CO�CS1} tels que :

� CO : Type(Télémédecine, Session) � CS1 : Etat(collaboration_clinique, Session)

3) Règle3 : A l’état para-clinique, seul le neurologue de CHU a le droit de déterminer les types des images de scan que le techno-radiologue doit effectuer. La permission organisationnelle relative à cette règle :Permission (System_GL, neurologue, détermination, dossier_médical, C). Le contexte C est défini comme suit, C={CO�CS2} tels que:

� CO : Type(Télémédecine, Session) � CS2: Etat(collaboration_paraclinique, Session)

4) Règle4 : Seuls les neurologues (Kamal, Mehdi et Maurice) de CHU ont le droit d’interpréter les résultats des examens biologiques (TDM, Scan,…). La permission organisationnelle relative à cette règle : Permission (System_GL,neurologue,interprétation,examen_biologique,C). Le contexte C est défini comme suit, C= {CO�CS2} tels que :

� CO : Type(Télémédecine, Session) � CS2:Etat(collaboration_paraclinique, Session)

5) Règle5 :Seul le 1er neurologue (Kamal) intégrant la session a le droit de prendre une décision sur le type de soins que va suivre le malade. La permission organisationnelle relative à cette règle : Permission (System_GL, neurologue, décision, dossier_médical, C). Le contexte C est défini comme suit, C= {CO ��CS3} tels que : (CS3=P1��P2)

� CO : Type(Télémédecine, Session) � P1 :Etat(prise_décision, Session) � P2 : first_membre(user, neurologue, session), signifie

que utilisateur exécutant cette action doit être le premier neurologue intégrant cette session.

B. Permissions relatives à la session Dans cette partie, nous allons spécifier les permissions relatives à la session (définies définies niveau session), dérivées à partir des permissions organisationnelles spécifiées précédemment.

Le tableau (table I) représente les utilisateurs interagissant dans la session S1, ainsi que leur rôle dans cette session. Ensuite, le tableau (table II) représente les actions qui seront exécutées dans la session ‘S1’, ainsi que l’activité à laquelle chaque action appartient. Enfin, le tableau (table III) représente les objets relatifs la session ‘S1’, ainsi que la vue à laquelle chaque objet correspond.

TABLE I. RÔLES DANS LA SESSION

Notation Rôle_session Domaine RS1 médecin_ha {Mohamed} RS2 médecin_samu {Ahmed} RS3 neurologue {Kamal, Mehdi, Maurice}

TABLE II. ACTIVITÉS DANS LA SESSION

Notation Activité_session Domaine AS1 accès {OpenFile(), lire} AS2 partage {OnPartage()} AS3 interprétation {OnCommenter(), OnInterpret()} AS4 envoi {appel, OnSend()} AS5 détermination {saisie, OnDetermine()} AS6 décision {saisie, OnDecide()}

TABLE III. VUES DANS LA SESSION

Notation Vue_session Domaine VS1 dossier_médical {DM1.html, DM1.doc} VS2 Examen_biologique {examen1.doc, examen2.doc} VS3 Image_scan {scan1, scan2, scan3} VS4 invitation {invt1, invt2}

Le tableau (table IV) suivant représente les permissions relatives à la session S1, dérivées à partir des permissions organisationnelles spécifiées dans la section précédente. Chaque ligne du tableau correspond à une permission au niveau session. Par exemple la première ligne du tableau s’interprète de la façon suivante : La permission S-Per1 est dérivée à partir de la permission organisationnelle définie sur la règle R1. Si un utilisateur est membre de la session ‘S1’ jouant le rôle_session ‘RS2’ (médecin_samu), alors cet utilisateur est autorisé à exécuter une action appartenant à l’activité_session ‘AS4’ (envoi) sur un objet de la vue_session ‘VS4’ (invitation), dans le contexte ‘CS0’.

TABLE IV. PERMISSIONS RELATIVES À LA SESSION S1

S-perm Session

Rôle Session

Vue Session

Activité session

Contexte session

Décision

S-Per1�R1 S1 RS2 VS4 AS4 CS0 True S-Per2�R2 S1 RS1 VS1 AS2 CS1 True S-Per3�R3 S1 RS3 VS1 AS5 CS2 True S-Per4�R4 S1 RS3 VS2 AS3 CS2 True S-Per5�R5 S1 RS3 VS1 AS6 CS3 True

Figure7. Arbre de permissions relatives à la session S1

17

Enfin, nous allons transformer le tableau ((table IV) des permissions relatives à la session S1 en un arbre [12] de permissions relatives à la session S1 (voir figure7).

Par exemple l’utilisateur ‘Kamal’ (premier neuologue intégrant la session ‘S1’) est autorisé à exécuter l’action ‘OnDecide()’ de l’activité ‘AS2’ sur l’objet ‘DM1.html’ de la vue ‘VS1’, dans le contexte ‘CS3’ (voir le chemin en couleur bleu dans l’arbre des permissions).

C. Implémentation Dans cette section, nous avons implémenté la spécification des règles de sécurité relatives à notre exemple, afin de vérifier la cohérence et la complétude de cette spécification. Pour cela nous avons utilisé Prolog, « langage de programmation logique ». D’abord nous avons spécifié en Prolog l’arbre des permissions définies précédemment, puis nous avons développé l’algorithme permettant de décider si une action est autorisée ou pas. La figure suivante représente la spécification en Prolog de l’arbre des permissions définies pour les règles de sécurité relatives à notre exemple.

Figure 8. Implementation

VII. CONCLUSION

Ce travail présente une nouvelle approche fondée sur une politique de sécurité, pour sécuriser les interactions entre les utilisateurs d’un groupe collaboratif en protégeant l'accès aux ressources partagées pendant une session collaborative. Dans cette approche, nous avons proposé un nouveau modèle de contrôlé d'accès que nous avons appelé Session-OrBAC. Ce modèle est une extension du modèle OrBAC et il est spécifique pour contrôler l’accès lors d’une session collaborative.

L’objectif de cette approche est d’assurer des interactions sécurisées et offrir un bon degré de confiance dans l’utilisation d’une application collaborative, tout en fournissant aux utilisateurs une meilleure qualité de service. Aussi, une démarche formelle à base de règles et d’arbre de permissions a été proposée pour être intégré à ce modèle. Ensuite, nous avons présenté une spécification formelle de notre approche pour une application collaborative de télémédecine. Enfin nous avons implémenté ce modèle et vérifié cette spécification à l'aide du

langage Prolog. Comme perspectives de ce travail nous comptons:

� Vérifier la conformité des propriétés de sécurité de niveau organisationnel par rapport à celles du niveau session et à celles du niveau concret.

� Prendre en considération les besoins de mobilité si l’on considère que le cas d’une application collaborative distribuée dans un contexte mobile.

� Proposer une solution pour détecter et résoudre le problème des conflits éventuel, dans le cas où les interdictions ou les obligations peut être également prises en compte.

� Proposer un modèle d'administration spécifique à cette approche permettant d'administrer les politiques exprimées grâce à notre modèle

� Etudier la complexité d’algorithme de prise de décision si l’on considère que notre modèle soit utilisé dans des systèmes plus critiques.

REFERENCES [1] B. Lampson. “Protection”, 5th Princeton Symposium on

Information Sciences and Systems, pp. 437-443, Mars 1971. [2] D. Bell et L. LaPadula. “Secure computer systems:Unified

exposition and multics interpretation”, Technical Report ESD TR-73-306, The MITRE Corporation, Mars 1976.

[3] R. Sandhu, E. Coyne, H. Feinstein et C.E.Youman. “Role-based access control models”. IEEE Computer, 29(2), pp. 38-47, 1996.

[4] R. Thomas et R. Sandhu. “Task-based Authorization Controls (TBAC): A Family of Models for Active and Enterprise-oriented Authorization Management”. 11th IFIP WorkingConference on Database Security, Lake Tahoe, California, USA, pp. 166-181, 1997.

[5] R. Thomas. “TMAC: A primitive for Applying RBAC in collaborative environment”. 2nd ACM, Workshop on RBAC, Fairfax, Virginia, USA, pp . 13-19, Novembre 1997.

[6] A. El Kalam et Y. Deswarte, “Multi-OrBAC: a New Access Control Model for Distributed, Heterogeneous and Collaborative Systems”, 8th IEEE International Symposium on Systems and Information Security (SSI 2006), Sao Paulo, Brésil, novembre 2006.

[7] A.El Kalam, Y. Deswarte, A. Baina et M. Kaaniche, “Access Control for Collaborative Systems: A Web Services Based Approach”, IEEE International Conference on Web Services (ICWS 2007), , pp. 1064-1071, 2007.

[8] A. Baina, “Contrôle d'Accès pour les Grandes Infrastructures Critiques: Application au réseau d'énergie électrique”, Thèse de doctorat, Université de Toulouse, 29 septembre 2009.

[9] N. Cuppens, F. Cuppens et M. Nuadi, “Smatch Model: Extending RBAC Sessions in Virtualization Environment”, 6th International Conference on Availability, Reliability and Security), pp. 17-26, 2011.

[10]A. El Kalam, P. Balbiani, S. Benferhat, F.Cuppens, Y. Deswarte et C. Saurel, “OrBAC”, IEEE 4th Int. Workshop on Policies for Distributed Systems, IEEE Computer Society Press, Italy, pp. 120-134, June 2003.

[11]A. El Kalam, “Modèles et politiques de sécurité pour les domaines de la santé et des affaires sociales”, Thèse de doctorat, Université de Toulouse, 04 décembre 2003.

[12]A. Liu, et M. Gouda “Diverse Firewall Design”, IEEE Transactions on Parallel and Distributed Systems, VOL. 19, NO. 8, pp. 595-604, Août 2008.