OrBAC

• Les objectifs et avantages d’OrBAC

• Les interactions d’OrBAC

• La notion de contexte

• La notion de hiérachie

• La notion de délégation

• Les prédicats d’OrBAC

• La gestion de conflit

• Le profil XACML

• Les extensions d’OrBAC

AdOrBAC

• L’administration via les vues

• Les vues d’AdOrBAC

Les publications

• Les publications liées à OrBAC

• Les publications liées à ADOrBAC

OrBAC

Références d’articles sur Or-BAC

Les objectifs et avantages d’OrBAC

L’objectif d’ OrBAC est de permettre la modélisation d’une variété de politiques de sécurité basées sur le contexte de l’organisation. Pour arriver à ce but, et afin de réduire la complexité de gestion des droits d’accès, le modèle OrBAC repose sur quatre grands principes :

• L’organisation est l’entité centrale du modèle
• Il y a deux niveaux d’abstraction (cf. Les interactions d’OrBAC) :
  un niveau concret : sujet , action, objet
  un niveau abstrait : rôle, activité, vue
• La possibilité d’exprimer des permissions, des interdictions, et des obligations
• La possibilité d’exprimer les contextes

Ainsi, en plus d’avoir une politique se sécurité indépendante de son implémentation, OrBAC a d’autres avantages. Il permet d’exprimer aussi bien des permissions, que des interdictions, que des obligations. Il prend en compte les contextes, les hiérachies et la délégation.
L’introduction d’un niveau permet aussi la structuration des entités comme on le voit sur le schéma suivant:
Ainsi dans OrBAC, un rôle est un ensemble de sujets sur lesquels sont appliquées les mêmes régles de sécurité. Identiquement, une activité est un ensemble d’actions sur lesquels sont appliquées les mêmes régles de sécurité. Une vue est un ensemble d’objets sur lesquels sont appliquées les mêmes régles de sécurité.

Les interactions d’OrBAC

Sur le schéma suivant, on peut apercevoir les interactions existantes dans ORBAC. Afin de ne pas surchargé celui-ci l’interaction entre le contexte et les entités concrêtes n’est pas représenté.

Les prédicats d’OrBAC liés aux intéractions seront descrits dans la section du même nom.

La notion de contexte

On voit apparaître sur ce schéma des interactions une entité qui n’apparait pas dans les autres modèles de contrôle d’accès : le contexte. Celui-ci est défini pour une organisation, un sujet, une action, des objets donnés. Les contextes permettent d’exprimer des permissions ou des interdictions dans certaines circonstances (urgence à l’hôpital, heures de travail dans une entreprise,...). Il est facile d’imaginer que dans un contexte d’urgence, on désirera qu’un infirmier puisse accéder au dossier d’un patient lambda sans avoir besoin d’appeler l’administrateur afin que celui-ci lui donne les droits (peut-être trop tard). Cette possibilité de nuancer les autorisations n’est pas offertes par DAC, MAC, RBAC, alors que dans de nombreuses organisations (hôpital, entreprise,...) il existe un réel besoin de ne donner des droits que dans des circonstances précises.
Pour le modéle OrBAC, on a regroupés les différents contextes par type (comme sur le schéma ci-dessus) :

• Contexte temporel : Ce sont des contextes régissant la durée de validité des priviléges.
• Contexte spatial : Il peut être lié à l’appartenance à un réseau, ou la position géographique, ou à tout autre situation spatial.
• Contexte déclaré par l’utilisateur : Ce type de contexte est activé, par exemple, par le médecin en cas d’urgence, ou pour signaler que l’on effectue un audit. Dans ces cas exceptionnels, des permissions peuvent être données alors qu’elles seraient interditent dans un cas normal. L’utilisateur qui déclare le contexte est obligé en contrepartie de faire un compte-rendu des opérations effectuées et peut être des raissons qui l’on motivé à déclaré ce contexte.
• Contexte prérequis : Leur utilisation permet de contraindre les sujets concernés par les permissions ou les interdictions dépendant de ces contextes et qui vient réduire ou étendre les droits d’accès hérités du rôle associé.
• Contexte provisionnel : Ce contexte de donner des privilèges en fonction de l’historique. Par exemple, le contexte "accés limités à 2 fois" regarde si le document a été accédé au moins 2 fois.

A noter que dans une modélisation OrBAC, on définit toujours un contexte par défaut.

La notion de hiérachie

Afin de gérer plus facilement des sous-organisations, en automatisant la dérivation des permissions, OrBAC permet de définir des hiérarchies sur les rôles, les activités, les vues et les contextes. On a ainsi l’héritage des permissions et des interdictions en descendant dans la hiérarchie des rôles, des activités, des vues et des contextes. Tout comme dans RBAC, l’héritage permet de simplifier la tâche de l’administrateur en automatisant partiellement l’attribution des privilèges. Comme dans RBAC, il existe deux façons de définir la hiérarchie de l’héritage :

• La première vision pour définir la hiérarchie est la hiérarchie organisationnelle. Le directeur est hiérarchiquement supérieur à un ingénieur. Dans certains cas, il peut donc hériter de toutes les permissions de ce rôle (pour vérifier le travail de celui-ci). On dit alors que R1 est senior de R2 et R2 est junior rôle de R1, si un utilisateur jouant le rôle R1 est supérieur hiérarchique de R2.
• La deuxième vision est la hiérarchie obtenue par la relation de spécification/généralisation est définie telle que R1 est un senior rôle de R2 si chaque fois qu’un utilisateur joue le rôle de R1, il joue le rôle de R2. Par exemple sur la hiérarchie présentée sur le schéma un peu plus en dessous, le chirurgien est aussi un médecin. Donc à chaque fois qu’un utilisateur est associé au rôle de chirurgien, il joue aussi le rôle de médecin. Le rôle chirurgien est un senior rôle de du rôle médecin. Un rôle R1 senior de R2 hérite donc les permissions affectées à R2.

Dans OrBAC, ces deux hiérarchies réapparaissent mais les droits qui leur sont associés sont quelque peut modifier. En effet, avec le modèle OrBAC, on peut définir des permissions mais aussi des interdictions. Dans OrBAC, on peut aussi spéciliser un rôle. On voit donc apparaître une hiérachie liée à cette spécification. Dans cette hiérachie si on veut qu’un rôle senior puisse avoir plus de pouvoir que son rôle junior, alors il faut que le rôle senior hérite des permissions de son rôle junior et que les interdictions liées au rôle senior soient héritées par son rôle junior. De plus, par rapport à RBAC, OrBAC introduit le concept d’organisation, ce qui donne une nouvelle dimension à l’héritage. En effet, il est possible qu’un rôle puisse toujours englober un certain sous-rôle quelle que soit l’organisation dans laquelle on se place. Par exemple, dans tout hôpital, le rôle de chirurgien est une spécialisation du sous-rôle médecin. OrBAC permet donc au chirurgien d’hériter de tous les droits du médecin en ne définissant qu’une seule fois les droits. Le reste se fait grâce à la relation de spécialisation/généralisation. Identiquement, les vues et les activités possèdent des sous-vues et des sous-activités. On les hiérarchise donc afin de créer pour elles aussi cette relation de spécialisation/généralisation.

Un petit exemple de dérivation de priviléges par la hiérarchie dans OrBAC, sur le schéma, si on a :
Permission(Org.HOP, Médecin, Opérer, patient, ctx.MéduPat.OUctx.Urg)
alors à partir de la hiérachie définie, on dérive automatiquement :
Permission(Org.HOP, Urologue, Opérer, patient, ctx.MéduPat.OUctx.Urg) et
Permission(Org.HOP, Chirurgien, Opérer, patient, ctx.MéduPat.OUctx.Urg)

La notion de délégation

La délégation permet de donner à un utilisateur particulier un privilège, sans donner ce privilège à toutes les personnes ayant le même rôle que lui. La délégation, bien que très utilisée, est très peu modélisée dans les politiques de sécurité car ce concept est très complexe.
En effet, grâce à une délégation, une permission peut être donnée par le détenteur d’un droit à un tiers pour agir à sa place ou à la place d’un autre. On voit déjà ici apparaître qu’une délégation peut faire intervenir plusieurs parties :

• Le sujet qui posséde le privilége
• Le sujet a qui on délégue le privilége
• Le sujet qui délégue le privilége (pour agir à sa place ou à la place d’un autre)

Il existe trois types de situation dans lesquelles la notion de délégation apparaît :

• la maintenance d’un rôle
• la décentralisation de l’autorité
• le travail de collaboration

La maintenance d’un rôle correspond au cas où un utilisateur doit déléguer une partie de ses permissions afin qu’on puisse remplir toutes ses obligations pendant son absence. La décentralisation de l’autorité est surtout utile dans le cas où on modifie une partie de l’organisation. En pratique, ce cas peut correspondre à l’ouverture d’un nouvel hôpital dans lequel on va transférer une partie des médecins exerçant dans les autres hôpitaux de la région. Le cas du travail en collaboration est évident, si on souhaite que notre partenaire puisse lire les documents que l’on possède sur un projet donné, il faut lui en donner l’autorisation.

Cependant, la délégation pose de nombreux problèmes. Entre autre, un utilisateur X ayant obtenu tous les droits d’un autre utilisateur Y peut ôter les droits à Y si X possède certains droits administratifs. Il peut aussi arriver que l’on oublie de révoquer une délégation faite à Z et qui n’a plus d’utilité d’être, ce qui peut laisser la possibilité à Z de se faire passer pour quelqu’un d’autre. C’est l’une des raisons pour lesquelles il est important de définir deux types de permission, celles qui sont délégables et celle qui ne peuvent l’être.


De plus, la délégation est liée à une multitude de notions :

• Délégation temporaire/permanente : Il faut tout d’abord distinguer les délégations temporaires ou permanentes. En effet, on peut souhaiter qu’un utilisateur ait de façon permanente un droit, afin de ne pas à avoir à renouveler sans cesse ce droit.
• Délégation monotone/non-monotone : C’est le droit de conserver son privilège quand on le délègue. Dans le cas où la délégation est monotone, la personne qui délègue le droit conserve ce droit. Tandis que si la délégation est non-monotone, la personne qui délègue un droit perd ce droit.
• Délégation "grant-dependant"/"grant-independant" : Dans le cas, où la délégation est temporaire et monotone, alors il faut alors choisir quelles sont les personnes susceptibles de révoquer les droits sous-délégués. Si on autorise uniquement la personne ayant déléguée originellement le droit à révoquer un droit délégué, alors on dit que c’est une délégation de type "grant-dependant". Si on autorise toute personne X ayant délégué un droit, avant que Y ait reçu ce droit par délégation, à révoquer ce droit à Y, alors on dit que la délégation est de type "grant-independant". Ce dernier type de délégation permet d’ôter rapidement un droit à une personne qui peut être malveillante, sans avoir à retrouver qui était à l’origine de la délégation (ce qui peut être très fastidieux si l’organisation est importante).
• Délégation totale/partielle : On peut choisir de déléguer partiellement ou totalement un ensemble de droits. Lorsque l’on souhaite déléguer la totalité de ses droits à quelqu’un, par exemple son remplaçant, alors on applique une délégation totale. Par contre, si on ne veut donner qu’une partie de ces droits, pour déléguer juste une tâche à quelqu’un, alors on a une délégation partielle.
• Délégation par agent/auto-active : Il y a deux façons d’administrer la délégation, si une personne X veut déléguer un droit à Y. La première solution est que c’est X qui administre la délégation. C’est la délégation auto-active. La deuxième solution est que X demande à un agent d’affecter ce droit à Y. C’est la délégation par agent. L’agent pouvant être n’importe quelle tierce personne dans l’organisation. Généralement, l’agent ne peut pas s’affecter les droits qu’il gère. Il est possible de définir le nombre de sous-délégation possible.
• Délégation à un-pas/à pas-multiple : Dans la délégation à n-pas, un même droit pourra être délégué à une chaîne de n personnes. Par exemple, X délègue à Y un droit D à 2-pas et Y délègue D à 1-pas à Z.
• Délégation simple/multiple : De plus, il faut choisir si lorsqu’on autorise une personne à déléguer, elle peut elle-même déléguer son droit à une unique personne, ou à plusieurs personnes (c’est la délégation multiple).
• Délégation par accord unilatéral/bilatéral : Pour déléguer un droit, il faut qu’au moins une personne donne son accord. On peut envisager deux types d’accord pour la délégation. L’accord unilatéral ne prend en compte que la décision de la personne désirant déléguer son droit. L’accord bilatéral vérifie que les deux parties, celle qui délègue et celle qui reçoit, sont d’accord.
• Révocation de la délégation simple/en cascade : Si la délégation est temporaire, il faut pouvoir la révoquer. On a pu voir précédemment deux types de délégation jouant sur la révocation. Lorsque la délégation est "grant-dependant" alors seule la personne à l’origine de la délégation peut ôter ce droit. Quand la délégation est de type "grant-independant" seules les personnes ayant engendré la délégation d’un droit à une personne peuvent lui révoquer ce droit. Cependant, la personne, dont les droit ont été révoqués, a peut être pu déléguer ce droit auparavant. Cette situation peut poser des problèmes dans certaines cas. Selon le type de délégation, la personne ayant était déchue d’un droit peut récupérer ce droit grâce à une personne à qui elle aurait délégué le droit. Pour anticiper ce problème, on peut créer deux types de révocation. Un premier type permet de ne révoquer le droit qu’à une personne désignée. Le deuxième type permet de révoquer le droit sur une personne, ainsi que sur toutes les personnes ayant reçu ce droit par délégation, c’est une révocation en cascade.

La délégation a de multiples avantages et offre de nombreuses possibilités. Cependant, il apparaît que si on l’autorise à mauvais escient, alors elle peut aller à l’encontre de la politique. En effet, la révocation d’une délégation permet à une personne d’ôter un droit D à une personne X. Mais que se passe-t-il lorsque la personne X possède ce droit avant la délégation? Des personnes mal intentionnées pourraient ainsi utiliser la délégation afin d’effectuer des révocations qu’ils n’avaient pas le droit de faire. D’où l’importance de bien administrer sa polititque de contrôle d’accès, si la délégation est mise en place.

Les prédicats d’OrBAC

Afin de comprendre les règles définies dans OrBAC, on récapitule dans ces tableaux les différents prédicats liés à OrBAC.
Les predicats liés à l’affectation des entités abstraites aux organisations :

Nom de prédicat	Domaine	Description
Relevant_role	Org*Role	Si org est une organisation et r un rôle, alors Relevant_role signifie que le rôle r est défini dans l’organisation org
Relevant_activity	Org*Activity	Si org est une organisation et a une activité, alors Relevant_activity signifie que l’activité a est définie dans l’organisation org
Relevant_view	Org*View	Si org est une organisation et v une vue, alors Relevant_view signifie que la vue v est définie dans l’organisation org

Les predicats liés aux relation d’abstraction :

Nom de prédicat	Domaine	Description
Empower	Org*Subject*Role	Si org est une organisation, s un sujet et r un rôle, alors Empower signifie que l’organisation org habilite le sujet s dans le rôle r
Consider	Org*Action*Activity	Siorg est une organisation, A une action et a une activité, alors Consider signifie que l’organisation org considére l’action A comme faisant partie de l’activité a
Use	Org*Object*View	Si org est une organisation, o un objet et v laune vue, alors Use signifie que l’organisation org utilise l’objet o dans la vue v

Les predicats liés au definition des contextes :

Nom de prédicat	Domaine	Description
Hold	Org*Subject*Action *Object*Context	Si org est une organisation, s un sujet, A une action, o un objet et c un contexte, alors Hold signifie que dans l’organisation org, le contexte c est défini pour le sujet s,l’action A etl’objet o

Les predicats liés aux permission abstraites :

Nom de prédicat	Domaine	Description
Permission	Org*Role*Activity *View*Context	Si org est une organisation, r un rôle, a une activité, v une vue et c un contexte, alors Permission signifie que dans l’organisation org accorde la permission au rôle r de raliser l’activité a dans la vue v dans le contexte c
Prohibition	Org*Role*Activity *View*Context	Si org est une organisation, r un rôle, a une activité, v une vue et c un contexte, alors Prohibition signifie que dans l’organisation org refuse la permission au rôle r de réaliser l’activité a dans la vue v dans le contexte c

Les predicats liés aux permission concrètes :

Nom de prédicat	Domaine	Description
Is_permitted	Subject*Action*Object	Si s est un sujet, A une action et o un objet, alors Is_permitted signifie que le sujet s a concrétement la permission de réaliser l’action A sur l’objet o
Is_prohibited	Subject*Action*Object	Si s est un sujet, A une action et o un objet, alors Is_prohibited signifie que le sujet s ne peut pas concrétement réaliser l’action A sur l’objet o

La gestion de conflit

OrBAC permet d’exprimer des permissions et des interdictions. OrBAC offre donc la possibilité de spécifier une politique mixte. Il existe dans OrBAC une troisième catégorie de privilège: l’obligation. La notion d’obligation décrit les actions qu’un utilisateur doit faire sur un ensemble d’objets. Par exemple, dans un contexte d’urgence, un infirmier aura le droit d’accéder au dossier médicaux mais uniquement s’il fait ensuite un rapport, c’est une obligation.

La politique mixte pose de nombreux problèmes liés à la gestion des conflits potentiels et des règles redondantes. Afin d’éluder le problème des règles redondantes, on ajoute des prédicats. Ceux-ci, pour deux règles données R1 et R2, interdisent d’avoir la priorité de R1 moindre que celle de R2, lorsque toutes les conditions suivantes sont vérifiées :

• R1 et R2 sont définies pour une même organisation
• R1 est définie pour un rôle r1 et R2 est définie pour un rôle r2, avec r1 sous-rôle de r2
• R1 est définie pour une activité a1 et R2 est définie pour une activité a2, avec a1 sous-activité de a2
• R1 est définie pour une vue v1 et R2 est définie pour une vue v2, avec v1 sous-vue de v2
• R1 est définie pour un contexte c1 et R2 est définie pour un contexte c2, avec c1 sous-contexte de c2

Il peut apparaître un conflit, par exemple si un même utilisateur possède deux rôles et que l’un de ces rôles lui permet de faire une activité et l’autre lui interdit. On est sûr que s’il n’y a aucun conflit au niveau abstrait, il n’y en aura pas au niveau concret. Ceci est du au fait que les permissions concrètes sont déduites des permissions organisationnelles, de même pour les interdictions. Donc on résout les conflits potentiels au niveau abstrait On décide pour cela de donner des priorités aux interdictions et permissions du niveau abstrait. Cependant, si le conflit subsiste (par exemple: l’interdiction et la permission on même priorité) alors OrBAC prévient le concepteur de la politique. Celui-ci choisit alors de modifier les règles liées aux priviléges, ou le niveau des priorités des privilèges.

Donc, OrBAC simplifie la conception de la politique de contrôle d’accès en automatisant la dérivation des permissions, iIl a l’avantage d’offrir une politique mixte qui gère les problèmes conflictuels.

Le profil XACML

Les extensions d’OrBAC

On peut apercevoir sur le schéma suivant les différentes extensions identifiées du modèle OrBAC, avec en orange les parties déjà traitées par l’équipe.

AdOrBAC

L’administration permet d’ajouter et de révoquer des entités ainsi que des privilèges. C’est dans l’optique d’avoir un modèle auto-administré qui permet de représenter plusieurs façons de gérer les accès que se présente AdOrBAC. Nous avons vu que le modèle OrBAC possède plusieurs relations entre ces diverses entités (cf. le schéma représentant le modèle OrBAC).
AdOrBAC doit gérer toutes ces relations. De plus, comme OrBAC est un modèle auto-administré, AdORBAC doit donc exprimer l’administration de OrBAC dans le même formalisme que OrBAC lui-même.

Références d’articles sur AdOrBAC

L’administration via les vues

L’administration par les vues fonctionne comme un guichet qui offre un ticket. Sur un billet d’avion on a tout les informations qui autorise et permettent à un passager de prendre son vol. De même, dans une permissions donner par une vue, la vue regroupera les diverses informations nécessaires à la permission.

Ainsi pour définir, une permission pour un rôle donné (dans la vue PRA), on doit donné l’organisation, le rôle, la vue, l’activité et le contexte lié à la permission.

Les vues d’AdOrBAC

Il faut vérifier chaque relation qui permet de décrire OrBAC donc associer des vues a presque chacune de ces relations distinctes. Presque, car pour la relation use, il est facile de vérifier la permission d’affecter ou de révoquer un objet dans une vue. On donne dans ce cas à l’utilisateur du rôle r la permission d’effectuer l’activité d’affectation assign la vue v dans un contexte c dans une organisation org, Permission(org,r,assign,v,c) .

AdOrBAC permet de contrôler les activités d’administration suivantes:

• affectation (et révocation) des utilisateurs aux rôles
• affectation (et révocation) des actions aux activités
• affectation (et révocation) des objets aux vues
• affectation (et révocation) des contextes aux entités concrètes
• affectation (et révocation) des permissions aux rôles
• affectation (et révocation) des utilisateurs aux permissions
• gestion des rôles
• gestion des activités
• gestion des vues
• gestion des contextes
• gestion des organisations
• gestion des entités concrètes