Approche de Contrôle d`accès collaboratif entre

Approche de contrôle d’accès collaboratif entre plusieurs
domaines de sécurité dans un environnement ubiquitaire
Fatma GHARSALLI
Abdelghani CHIBANI
Yacine AMIRAT
Laboratoire LISSI
Laboratoire LISSI
Laboratoire LISSI
Université Paris-Est Créteil
Université
Paris-Est Créteil
Université Paris-Est Créteil
120 rue Paul Armangot Vitry sur Seine 120 rue Paul Armangot Vitry sur Seine 120 rue Paul Armangot Vitry sur Seine
94400 France
94400 France
94400 France
[email protected]
[email protected]
ABSTRACT
Without a strong and consistent security approach, ubiquitous
environments will not be able to ensure a successful collaboration
between its various actors. In particular, collaboration between
different security domains in a ubiquitous context can take place
only if access to the resources of these areas is regulated by a
powerful and collaborative access control mechanism. Hopefully,
enabling collaboration among different security domains implies
to enhance access control interoperability between domains
without violating local policies. However, maintaining such a
secure collaboration is not a trivial task because security policy
usually differs between domains since the same concepts are
represented differently. Unfortunately, XACML authorization
language comes short to achieve interoperability objectives. In
this paper, we introduce the access control challenges across
interoperating security domains and we propose a real case study
to illustrate it. Then, we propose an extensible security policy
model supporting multi-domain access control requirements, by
the means of ontology
RESUME
La transparence d‟accès aux services dans les environnements
ubiquitaires nécessite la mise en place de systèmes de contrôle
d‟accès collaboratifs faisant appel à des politiques de sécurité
multi domaine. Dans ce cas, comment mettre en œuvre un
mécanisme d‟interopérabilité de systèmes de contrôle d‟accès
permettant d‟une part, de conserver l‟autonomie et la
confidentialité de la politique locale de chaque domaine et d‟autre
part, d‟autoriser l„accès à un utilisateur externe en fonction des
privilèges qu‟il possède dans son domaine d‟origine. La mise en
œuvre d‟un tel mécanisme n'est pas triviale, car à travers les
différents domaines de sécurité, les concepts utilisés pour
exprimer la politique de sécurité dans un domaine sont en général
représentés et interprétés de manière différente dans un autre
domaine. Utiliser des langages standardisés de définition de
politiques, basés sur XML, tels que XACML ou WS-Policy ne
permet pas de résoudre le problème d'interopérabilité sémantique
de politiques hétérogènes. Dans cet article, nous proposons un
modèle de représentation de métapolitiques de contrôle d‟accès
dans les environnements ubiquitaires, que nous appelons politique
de coalition de domaines. Ce modèle qui offre un haut niveau
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
[email protected]
d'abstraction, consiste à associer aux langages de définitions de
politiques locales une ontologie pour créer un lien sémantique
entre des politiques syntaxiquement hétérogènes de domaines
différents. Une telle approche rend possible la conversion des
privilèges d‟accès aux services partagés entre plusieurs domaines
et facilite l‟administration des métapolitiques.
Categories and Subject Descriptors
D.2.2
General Terms
Security
Keywords
Security policy, Metapolicy, Ubiquitous environments, Multi
Domain, Service, Access Control, Ontology, RBAC, XACML,
REI.
1. INTRODUCTION
La mise en place de systèmes de contrôle d‟accès collaboratifs
constitue un problème de recherche ouvert dans le cadre des
environnements ubiquitaires. Un environnement ubiquitaire est en
général composé de plusieurs domaines de sécurité. Chaque
domaine fournit des services d‟accès à des ressources locales
physiques ou logiques. Pour illustrer cette problématique, prenons
l‟exemple d‟un utilisateur qui utilise habituellement les services
d‟un domaine de départ A et dont les privilèges d‟accès sont
définis par la politique de ce domaine. Cet utilisateur désire
maintenant accéder aux services d‟un domaine d‟arrivée B
sachant que ces services sont régis par une politique différente de
celle du domaine A. Dans la littérature, plusieurs modèles et
langages ont été proposés dans l‟objectif de définir des standards
de représentation de politiques de sécurité cohérentes et
interopérables. Actuellement, le standard RBAC (Role Base
Access Control) apparait comme le modèle le plus adapté pour
mettre en œuvre des systèmes de contrôle d‟accès multi domaine
(Joshi et al.) [1]. Dans ce modèle, la définition d‟une politique de
sécurité est simplifiée car elle est structurée autour des concepts
de rôle et de permission. Grâce à la notion de contexte propre à
RBAC, un système de contrôle d‟accès peut prendre en compte
des informations contextuelles pour gérer les autorisations d‟accès
aux services [7]. Cette propriété fait de RBAC un modèle abstrait
de représentation de politiques de sécurité bien adapté aux
environnements ubiquitaires. En plus de RBAC, XACML
(eXtensible Access Control Markup Langage) permet d‟exprimer
statiquement des règles de contrôle d‟accès dans le format :
Policy(subject, resource, action) et de les combiner dans des
containeurs appelés Policyset [2]. Le sujet peut représenter les
profils, rôles et contextes sécurité des utilisateurs [2]. Cependant,
l‟encodage statique des politiques dans XACML ne permet pas de
translater facilement et sans perte de sémantique une politique
lorsqu‟une requête de demande d‟accès passe d‟un domaine à un
autre. De notre point de vue, il est nécessaire de disposer d‟un
langage de description permettant d‟associer à une politique
XACML et RBAC des annotations sémantiques permettant de
faciliter la mise en correspondance entre les entités de politiques
de domaines différents.
REI est un langage à base d‟ontologies qui permet de définir des
politiques de contrôle d‟accès. Il est basé sur la définition de
contraintes et d‟obligations, et permet d‟exprimer dynamiquement
des politiques grâce à l‟utilisation de la notion de variable.
L'administration des politiques est quant à elle possible par le
biais du concept des « actes de langage ou speech acts » pour
exprimer des actions d‟administration des privilèges des
utilisateurs tels que les délégations, les révocations, la suppression
et les demandes de privilèges d‟accès. Comme dans XACML, les
règles de contrôle d‟accès de REI sont exprimées dans un format
simple mais cependant limité en termes de flexibilité. Une règle
REI est exprimée en combinant trois prédicats principaux. Le
premier prédicat PolicyObject(Action,Conditions) permet de
déclarer des règles de contrôle d‟accès comme par exemple :
permettre(écrire(FichierX),Utilisateur(UserX)) où FichierX et
UserX
sont
des
variables.
Le
deuxième
prédicat
Has(Subject,PolicyObject) permet de définir les privilèges d‟accès
du
sujet,
comme
par
exemple :
Has(permettre(écrire(Liste_Prix),Utilisateur(Mike)). Le troisième
prédicat Action(ActionName, TargetObject,PreCond, Effect)
permet de définir l‟objet sur lequel porte l'action et la liste de préconditions et effets liés à cette action. Cet ensemble est en général
couplé à un moteur d‟inférence permettant d‟évaluer
sémantiquement les privilèges des utilisateurs selon la politique de
sécurité [5] [9].
Pour mettre en œuvre un système de contrôle d‟accès multi
domaine, nous proposons une approche sémantique permettant
d‟une part, de résoudre les problématiques d‟hétérogénéité entre
les domaines de sécurité et d‟autre part, de composer de nouvelles
politiques multi domaine. Afin de garantir sa compatibilité avec
tous les systèmes de contrôle d‟accès reposant sur XACML, cette
approche utilise uniquement le standard XACML sans recourir à
la modification ou à l‟extension de ce dernier. Notre approche
n‟est pas une solution de fédération d‟identités ; elle constitue
plutôt un cadre générique permettant de représenter une politique
commune, qui comporte uniquement les concepts et les règles de
contrôle d‟accès aux services partagés par des domaines
différents.
Cet article est organisé comme suit : Dans le paragraphe 2, nous
analysons la problématique du contrôle d‟accès dans les
environnements multi domaine et nous l'illustrons par un scenario
représentatif. Nous esquissons ensuite dans le paragraphe 3 notre
modèle de représentation sémantique de métapolitiques en
montrant l‟intérêt de ses propriétés de flexibilité et d‟extensibilité
pour la transparence d‟accès aux services dans les environnements
ubiquitaires, Le paragraphe 4 conclut l‟article et dresse les
perspectives de l‟approche proposée.
2. CONTROLE D’ACCES DANS LES
ENVIRONNEMENTS UBIQUITAIRES
MULTI DOMAINE
Modéliser le contrôle d‟accès entre plusieurs domaines consiste
essentiellement à définir un système décentralisé de gestion des
autorisations d‟accès. La mise en œuvre d‟un tel système se heurte
aux problèmes suivants : (i) un utilisateur demandant l‟accès n‟est
pas reconnu/authentifié dans le domaine d‟arrivée, (ii) selon quel
critère l‟autorisation d‟accès sera accordée à un demandeur venant
d‟un domaine externe ? (iii) quels sont les privilèges d‟accès qui
seront attribués au demandeur dans le domaine d‟arrivée ?
Pour illustrer en détail cette problématique, considérons un
scénario inspiré du domaine de la santé. Dans ce scenario, on
considère plusieurs services ubiquitaires fournis par les domaines
suivants : l‟hôpital, la maison, le cabinet du médecin traitant et la
pharmacie. Ces domaines sont gouvernés par des politiques de
sécurité indépendantes et doivent collaborer pour améliorer la
qualité des soins et la sécurité des données des patients.
Figure 1 : Exemple d‟architecture de contrôle d‟accès à
travers plusieurs domaines de sécurité
Le travail présenté dans cet article s‟inscrit dans le cadre du projet
européen MULTIPOL dont l‟objectif est d‟automatiser la chaine
de contrôle d‟accès (autorisation) pour des systèmes ubiquitaires
appartenant à des domaines différents [10]. Plus précisément, il
s‟agit d‟utiliser des mécanismes sémantiques pour décrire et
transformer des politiques de sécurité RBAC locales exprimées
dans le langage XACML en politiques multi domaine
interopérables.
La chaine de contrôle d‟accès de MULTIPOL garantie que les
utilisateurs appartenant à des domaines de sécurité indépendants
vont avoir suffisamment de privilèges pour invoquer un ou
plusieurs services, et uniquement les privilèges requis nécessaires,
sans passer par un provisionnement manuel des privilèges effectué
par le gestionnaire du domaine d‟arrivée (Figure 1).
Considérons d‟abord le cas où il n‟y a pas de système collaboratif
de contrôle d‟accès permettant d‟interconnecter ces domaines et
faciliter l‟accès aux services locaux. Pour illustrer ce cas,
considérons la situation suivante : suite à des douleurs cardiaques,
une personne se déplace aux urgences d‟un hôpital (Domaine A)
(Figure 2). Pour effectuer un diagnostique, le médecin urgentiste a
besoin d‟accéder au dossier médical du patient. Ce dossier est
stocké en partie sur la carte à puce de santé du patient et l‟autre
partie dans le serveur du cabinet médical du médecin traitant
(Domaine B) que le patient à l‟habitude de consulter. Dans ce cas,
le médecin urgentiste aura seulement accès aux données du
patient stockées sur la carte. Considérons maintenant une autre
situation : le médecin urgentiste oriente le patient vers le service
d‟imagerie médicale et ensuite vers un cardiologue d‟un autre
hôpital (Domaine C). Le cardiologue ne peut faire son
diagnostique que s‟il arrive à accéder à tout le dossier médical du
patient, et au rapport d‟imagerie médicale. Etant donné qu‟il n‟y a
aucun système permettant l‟échange et le partage des données
médicales entre les différents domaines, le cardiologue est
contraint de reporter son diagnostique à la prochaine visite du
patient, c‟est à dire une fois l‟ensemble du dossier médical
disponible. Imagions enfin une autre situation : en attendant la
prochaine visite, le cardiologue prescrit au patient des
médicaments pour calmer ses douleurs. Il lui demande également
de transmettre par téléphone à l‟hôpital (Domaine C) le relevé
d‟activité cardiaque après deux jours et de remettre une lettre à
son médecin traitant. Après avoir acheté à la pharmacie (Domaine
D) ses médicaments, le patient contacte comme prévu l‟hôpital
(Domaine C) pour communiquer depuis son domicile (Domaine
E) le relevé de son activité cardiaque. Dans ce scenario, chaque
domaine est régit par une politique de sécurité RBAC. Par
exemple dans le domaine A, les rôles tels que médecin, médecinurgentiste, infirmier, cardiologue, opérateur d‟imagerie, médecinradiologue sont assignés aux membres du domaine en fonction
des services de l‟hôpital (modélisé par des organisations RBAC).
Au sein de chaque domaine de ce scenario, une politique RBAC
exprimée en XACML est suffisante pour permettre à des
utilisateurs locaux d‟utiliser les services locaux permettant de
fournir les données médicales du patient. De même, la politique
de sécurité locale de chaque domaine ne reconnaît que les rôles et
les permissions autorisant les utilisateurs authentifiés dans ce
domaine à accéder aux services locaux. Par conséquent, il n‟est
pas possible d‟assurer un mode d‟accès transparent aux services
d‟un domaine depuis n‟importe quel autre domaine et à n‟importe
quel moment tel que nécessité dans les environnements
ubiquitaires [6].
Figure 2 : Scenario de contrôle d‟accès multi domaine
montrant les demandes d‟accès aux services et les flux
d‟information entre les domaines
Considérons maintenant le cas où on dispose d‟un système de
contrôle d‟accès collaboratif entre domaines. L‟utilisateur d‟un
domaine peut avoir un accès aux services des autres domaines en
fonction de ses privilèges définis de son domaine d‟origine. Si on
reconsidère le scenario précédent, les médecins impliqués
pourront ainsi partager toutes les données du dossier médical du
patient quelque soit leur domaine d‟origine. Par exemple, le
médecin cardiologue peut faire son diagnostique en accédant au
service de consultation du dossier médical du patient, disponible
dans le domaine B. Il peut ainsi prescrire un traitement pour le
patient et transmettre électroniquement une ordonnance médicale
à la pharmacie la plus proche du domicile du patient (Domaine C)
ou de celle de l‟hôpital selon les préférences du patient. Enfin, le
médecin peut surveiller l‟activité cardiaque de son patient en se
connectant depuis son téléphone au terminal de surveillance
cardiaque installé au domicile du patient. Il peut également
recevoir une alarme en cas d‟incident.
Dans ce scenario, nous faisons l‟hypothèse que les différentes
politiques RBAC sont exprimées en XACML. Cette
représentation ne permet pas d‟accorder des autorisations d‟accès
aux personnes authentifiées en raison de la différence syntaxique
et sémantique des termes (rôles, permissions) utilisés dans la
définition des politiques des différents domaines. Par exemple,
l‟accès au dossier médical dans le domaine A est autorisé au rôle
nommé médecin. Lorsque dans le domaine C le cardiologue tente
d‟accéder au même dossier avec le rôle cardiologue , l‟accès sera
refusé car ce rôle n‟existe pas dans la politique du domaine A.
3. UN MODELE SEMANTIQUE DE
CONTROLE D’ACCES MULI DOMAINE
3.1 Méthodologie
L‟hétérogénéité sémantique entre les politiques locales des
différents domaines est le verrou principal, qui rend la tâche
d‟automatisation de la chaine de contrôle d‟accès difficile à mettre
en œuvre dans les environnements ubiquitaires.
Pour résoudre ce problème, nous proposons d‟utiliser le langage
d‟ontologies du web sémantique OWL afin de permettre aux
différents domaines de définir une politique commune ou
métapolitique. OWL est un langage de description sémantique des
connaissances possédant un haut niveau d‟expressivité [8]. Il
permet de représenter des ontologies (sorte de méta données) avec
des constructeurs tels que : classe, propriétés (objet, type de
donnée), instances de classes ou de propriétés. Il permet aussi
d‟associer des propriétés aux classes ou aux propriétés telles que
la transitivité des propriétés, la cardinalité, etc. Il permet aussi
d‟étendre une ontologie avec de nouvelles instances, classes et
propriétés, et d‟effectuer des raisonnements sur ces dernières [3].
Dans notre approche, nous avons utilisé OWL pour définir une
ontologie qui permet de décrire la sémantique d‟une métapolitique
de contrôle d‟accès, commune à plusieurs domaines. Notre
approche reprend les concepts introduits dans RBAC, XACML et
REI pour décrire un modèle de métapolitique de sécurité avec un
haut niveau d'abstraction, que nous appelons politique de coalition
de domaines (communauté ou consortium de domaines). Ce
modèle définit un ensemble de concepts globaux de contrôle
d‟accès correspondant aux rôles, permissions, ressources,
autorisations, obligations, contextes, etc. communs aux politiques
des différents domaines. Ces concepts ne sont en aucun cas
extraits de la politique locale de chaque domaine pour préserver la
confidentialité des politiques. On parle dans ce cas d‟étanchéité
des politiques. La métapolitique peut être traduite et instanciée par
la suite dans le format de représentation de la politique de sécurité
de chaque domaine, tel que XACML, LDAP/RBAC, etc. Elle
peut également être composée avec une politique locale déjà
existante.
Définir la métapolitique de coalition revient à répondre à un
certain nombre de questions: Comment établir une relation de
confiance dans le cadre d‟une politique de sécurité commune?
Quelles sont les règles de sécurité communes qui peuvent
satisfaire les besoins des différents domaines et comment ces
règles peuvent être composées avec les politiques locales des
domaines tout en préservant leurs autonomies/confidentialités et
en évitant des conflits ou des failles de sécurité? Comment
administrer la métapolitique pas plusieurs gestionnaires différents.
Pour ce faire, nous proposons une méthodologie pour créer une
métapolitique de contrôle d‟accès qui se résume en trois étapes
majeures :
1.
2.
3.
Etablir une relation de confiance : Il s‟agit de définir un
contrat de collaboration entre les domaines selon plusieurs
niveaux de sécurité dans le cadre d‟une coalition temporaire
(Ad hoc) ou permanente, dont les membres sont connus et
enregistrés au préalable.
Décrire la métapolitique de coalition : Chaque gestionnaire
d‟un domaine de la coalition peut enrichir l‟ontologie avec
de nouvelles classes et propriétés pour décrire les règles de
contrôle d‟accès aux services de son domaine. La
métapolitique d‟une coalition doit contenir les éléments de
XACML et RBAC tels que sujets, ressources, actions, rôles
et permissions. Elle doit contenir également des règles
d‟administration basées sur les modalités déontiques
(Deontic Object) et les actes de langages de REI (figure 3).
Composition de la politique multi domaine : A l‟aide d‟un
outil
de
mise
en
correspondance
ou
de
composition/optimisation, aligner la métapolitique avec la
politique locale en vue de générer une politique locale multi
domaine qui sera prise en compte par le système de contrôle
d‟accès d‟un domaine donné.
3.2 Description du modèle
Le modèle que nous proposons dans cet article est une ontologie
qui décrit une métapolitique à travers quatre éléments
principaux (Figure 3) inspirés de REI [5]: (i) La structure de la
métapolitique: domaine, organisation, coalition, (ii) Les règles
de contrôle d‟accès d‟une politique. Chaque règle est décrite à
travers un concept abstrait appelé entité qui se décline en trois
classes : l‟utilisateur, la ressource (service) et le rôle. Un rôle
dans la métapolitique correspond à une classe dont certaines
propriétés correspondent à des permissions. (iii) A chaque règle
est associée une modalité déontique : obligation, permission,
prohibition, dispensation; cette modalité portant sur une action
(lire un fichier, déléguer son rôle, etc.) (iv) le contexte d‟accès
et le niveau de sécurité.
Figure 3: Ontologie de la métapolitique
Les éléments de notre ontologie sont décrits à partir d‟un
ensemble de classes génériques (rôles, permissions, ressources,
contexte, domaine, organisation, etc.) et d‟un ensemble de
propriétés faisant le lien entre ces classes. Ces classes génériques
peuvent ensuite être étendues par les gestionnaires des domaines
d‟une coalition pour définir les sous classes et propriétés décrivant
la métapolitique et permettre la collaboration entre leurs domaines
respectifs. Les relations de hiérarchie de rôles telles que définies
dans RBAC sont traduites en une hiérarchie de classes. Par
exemple, la classe rôle Cardiologue hérite de la classe rôle
Médecin et permet ainsi à un cardiologue d‟hériter des
permissions accordées à un médecin. En utilisant le test de
subsomption de classes [8], il est alors possible de raisonner sur
les politiques pour comparer et translater les règles, les contextes
et les profils utilisateurs entre les différents domaines.
Notre modèle répond à des exigences importantes en termes de
gestion des politiques de sécurité multi domaine:
 Extensibilité: Le gestionnaire d‟un domaine peut personnaliser
les politiques de contrôle d‟accès de son domaine sans affecter
la coalition. Il peut étendre et/ou instancier les classes et les
propriétés décrivant les règles de contrôle d‟accès en fonction
de la coalition à laquelle il participe et en fonction de la
politique locale. Pour représenter une coalition de domaines du
secteur médical, du scenario décrit précédemment, nous
étendons la classe Rôle avec des sous classes pour décrire les
rôles sécurité correspondant à chaque métier, service ou
personne ayant l‟accès à l‟hôpital: médecin, patient, etc.
Considérons
maintenant
l‟exemple
d‟une
coalition
d‟opérateurs ; les sous classes de Rôle peuvent correspondre
cette fois-ci à : abonné au forfait, abonné avec carte
prépayée, abonné professionnel, abonné grand public,
collaborateur, prestataire, partenaire, etc. Notre modèle est
conçu de telle sorte qu‟un domaine peut faire partie de plusieurs
coalitions sans créer de conflits. Il est aussi possible qu‟une
règle de contrôle d‟accès dans une politique locale puisse être
composée avec une ou plusieurs métapolitiques.
 Flexibilité: Les classes et les propriétés de l‟ontologie peuvent
être utilisées en fonction des besoins des domaines d‟une
coalition en termes de services partagés. Par exemple, le
gestionnaire d‟un domaine peut décrire une politique en
spécifiant uniquement les permissions et les identités des
utilisateurs autorisés, tandis qu'un autre peut décrire une
politique en utilisant d‟autres concepts comme le profil des
utilisateurs autorisés, leurs rôles, leurs obligations, ou bien
encore des actions d'administration telles que la possibilité de
déléguer les privilèges à une autre personne de la coalition.
Dans d‟autres cas, le gestionnaire peut se contenter de décrire
simplement les permissions et le contexte d‟accès (créneau
horaire, localisation de l‟utilisateur, activité de l‟utilisateur,
etc.).
Description du contexte d’accès et du niveau de sécurité: Le
contexte est aussi un concept clef : certains utilisateurs peuvent se
voir octroyer des privilèges en fonction de leur contexte. Dans le
scenario décrit précédemment, on peut définir dans la politique du
domaine A plusieurs contextes d‟accès. Par exemple, l‟accès au
scanner n‟est autorisé que pour un utilisateur ayant le rôle
radiologue et comme localisation la salle de radiologie de l’étage
1 du bâtiment principal. Le niveau de sécurité est aussi un concept
étroitement lié à la notion de contexte. Un niveau de sécurité
permet d‟autoriser l‟accès à des services en fonction de la
confidentialité de ces derniers. Supposons qu‟à un médecin
cardiologue est assigné un niveau de sécurité moyen. Quand ce
médecin est sollicité par exemple pour un cas d‟urgence dans le
bloc opératoire du service des urgences, le système de contrôle
d‟accès détecte sa présence dans le bloc opératoire et modifie le
niveau de sécurité de moyen à haut pour lui permettre d‟accéder à
tous les services disponibles au niveau du bloc. Le niveau de
sécurité est modélisé en tant que propriété objet d‟OWL dont les
valeurs sont négociées entre les domaines dans le cadre de la
coalition. Le niveau de sécurité peut être représenté différemment
d‟un domaine à un autre. Il est convertit d‟un domaine à un autre
en utilisant la métapolitique.
Description du profil sécurité de l’utilisateur : L‟ontologie que
nous proposons n‟est pas limitée uniquement à l‟utilisation des
rôles dans la description des utilisateurs autorisés. Elle permet
aussi de décrire ces utilisateurs par leurs profils. Un profil
utilisateur dans un domaine de départ est converti en un autre
profil dans le domaine d‟arrivée. La conversion d‟un rôle associé
à un profil est basée d‟abord sur une classification de l‟instance de
rôle puis sur un test de subsomption vis-à-vis des classes de la
métapolitique. Le(s) classe(s) obtenues après le test de
subsomption sont associées à un ou plusieurs rôles dans le
domaine d‟arrivée. Le même procédé de conversion est appliqué
au contexte de l‟utilisateur, au niveau de sécurité et aux autres
attributs du profil tels que le grade, l‟âge, le type de contrat de
travail, la responsabilité légale, l‟ancienneté, etc.
Règles d’administration d’une politique multi domaine
Les actions d‟administration d‟une métapolitique sont décrites
dans notre modèle à l‟aide de règles utilisant des prédicats naire de la forme ‘rule symbolic name’ {Coalition, User, Domain,
Role, Context, Security Level, Action, Ressource, Deontic Object,
PriorityHigherThan (rule symbolic name), PriorityLowerThan
(rule symbolic name) }. Contrairement à REI qui ne permet
d‟écrire que des règles utilisant les prédicats binaires, le modèle
proposé permet d‟exprimer des règles d‟administration
sémantiquement plus riches et d‟effectuer par exemple des
raisonnements sur des relations implicites entre des décisions de
contrôle d'accès concernant les accès aux services et les actions
d‟administration. Il est aussi possible de composer librement des
règles plus ou moins complexes en combinant et en imbriquant
des règles simples.
Dans notre modèle, nous proposons deux classes de règles
d‟administration:
 Règles de gestion de la métapolitique: Ces règles décrivent les
actions que le gestionnaire d‟un domaine peut entreprendre. Il
s‟agit de règles qui permettent de gérer le cycle de vie de la
métapolitique. Par exemple : ajouter/supprimer un rôle, définir
un contexte, définir un type de profil utilisateur autorisé, etc.
 Règles pour l‟administration des privilèges d‟accès des
utilisateurs : Il s‟agit de règles permettant d‟assigner les
privilèges définis dans la métapolitique aux utilisateurs de
l‟environnement ubiquitaire. Exemple : assigner le rôle
patient_jeune à une personne qui vient de rentrer dans l‟enceinte
de l‟hôpital pour consulter un médecin cardiologue. Ce rôle est
défini dans la métapolitique en tant qu‟instance de la classe
Patient.
4. Conclusion
Nous avons proposé dans cet article une première ébauche du
modèle de représentation de politiques de sécurité multi domaine,
permettant un accès transparent aux services d'un environnement
ubiquitaire composé de plusieurs domaines gouvernés par des
politiques de sécurité hétérogènes et étanches. Notre modèle
répond aux limitations du standard XACML dues à sa
représentation statique des règles de contrôle d‟accès. Ce modèle
est une ontologie de métapolitique exploitant la puissance
d‟expressivité et de raisonnement du langage d‟ontologies OWL.
Cette ontologie définit une sémantique commune que doivent
respecter les gestionnaires des domaines de sécurité dans le cadre
d‟une coalition. Notre modèle s‟appuie sur les concepts du
modèle RBAC et des langages XACML et REI pour proposer un
langage de règles utilisant des prédicats n-aire, ce qui permet
d‟écrire des règles d‟administration sémantiquement plus riches.
Nos travaux futurs concernent la proposition d‟un ensemble de
patrons de règles pour l‟administration sémantique de
métapolitiques. L‟ensemble sera géré à travers un outil
d‟administration offrant des fonctionnalités de raisonnement
sémantique, d‟optimisation et de vérification de cohérence des
politiques instanciées. Concernant ce dernier point, il s‟agit de
détecter et de remédier à de possibles conflits et failles de sécurité
qui ne peuvent pas être identifiés dans le format de base des
politiques locales des domaines par exemple XACML ou LDAP.
5. REFERENCES
[1]
J. Joshi, A. Ghafoor, W. Aref, E. Spafford, "Digital Government Security and
Privacy Challenges", William J. McIver, Jr. and Ahmed K. Elmagarmid (eds)
(Fall 2001) Advances in Digital Government: Technology, Human Factors,
and Policy . Boston : Kluwer, 2002, Chapter 7, pages 121-136.
[2] Y. Demchenko, “SAML–XACML Authorization Interface and XACML
Obligations Handling”, EGEE JRA1 Technical Document, Draft version 0.3,
April 29, 2008.
[3] M. Bräuer, H. Lochmann, “Towards Semantic Integration of Multiple
Domain-Specific Languages Using Ontological Foundations”, 4th
International Workshop on (Software) Language Engineering (ATEM'07) colocated with the 10th International Conference on Model Driven Engineering
Languages and Systems (MoDELS 2007), October 2007.
[4] F. Cuppens, A. Miege, « Modelling Contexts in the Or-BAC Model »,
ACSAC ‟03 : Proceedings of the 19th Annual Computer Security Applications
Conference, IEEE Computer Society, 2003, page 416..
[5] L. Kagal, "REI: A Policy Language for the Me-Centric Project", Technical
Report, HP Labs, September 2002.
[6] H. Wang, Y. Zhang, J. Cao, “Ubiquitous computing environments and its
usage access control”, ACM International Conference Proceeding Series, Vol.
152, Proceedings of the 1st international conference on Scalable information
systems, September 2006.
[7] S. Chae, W. Kim, D. Kim, “Role-Based Access Control for Ubiquitous
Computing Environment”, in Lecture notes in computer science: Vol. 3786.
Information security applications (pp. 354–363).Springer Berlin, February
2006.
[8] OWL, http://www.w3.org/TR/owl-features/
[9] C. Coma-Brebel, “Interopérabilité et cohérence de politiques de sécurité pour
les réseaux auto-organisants“. Thèse. doctorat. : ENST Bretagne 2009.
[10] Projet ITEA 2 Multipol, http://www.itea2-multipol.org/project.html
[11] N. Noy, A. Rector, P. Hayes, C. Welty: “Defining N-ary Relations on the
Semantic “ Web. W3C Working Group Note (April 12, 2006) (retrieved
December 13, 2007), http://www.w3.org/TR/swbp-n-aryRelations
[12] G.P. Zarri, “Representation and Management of Narrative Information.
Theoretical Principles and Implementation“, Series: Advanced Information
and Knowledge Processing, 302 pages, Springer, 2009.