Présenté par :
Bouafia Doria.
Ziraoui Bouchra.
Proposé et encadré:
Docteur N.Boustia.
1
1. Problématique .
2. Travaux réalisés dans le même axe de recherche
( la délégation).
3. Objectifs .
4. Le contrôle d’acc...
réaliser un modèle de contrôle d’accès
comprenant la modélisation du concept de
délégation formalisé avec une logique non
...
4
Sujet Institution/
organisme de recherche
Caractéristiques
Managing Delegation in
Access Control Models
ENST BRETAGNE • ...
5
I. Conception d’un modèle de contrôle d’accès :
1) Inspiré d’OrBAC.
2) Incluant la modélisation de la délégation .
3) Ba...
les modèles de contrôle
d'accès discrétionnaires.
DAC
les modèles de contrôle
d'accès obligatoires.
MAC
Modèle de sécurité...
7
organisation
Action
sujet
Activité
contexte
Objet
Rôle
Vue
Niveau
concret
Niveau
abstrait
8
Action
sujet
Activité
contexte
Objet
Rôle
Vue
Habilite
Utilise
Considère
Organisation
Définit
9
Action
sujet
Activité
contexte
Objet
Rôle
Vue
Permission
Est-Permis
Niveau
concret
Niveau
abstrait
10
L’organisation
VueRôle Activité
Sous-
rôle1
Sous-
rôle2
Sous-
vue1
Sous-
vue2
Sous-
Activité1
Sous-
Activité2
1 2 3
11
Le modèle AdOr-BAC permet d‘administrer une politique de sécurité Or-
BAC. Il permet de gérer toutes ces relations. [2]...
12
Rôle assignment Licence assignment
La délégation permet de donner à un utilisateur particulier
un privilège, sans donner ce privilège à toutes les
personnes ...
14
Délégation
temporaire/
permanente
Délégation
monotone/non
monotone
Délégation Grant-
dependant/Grant-
independant
Délég...
15
Révocation simple
Révocation GD
Révocation en
cascade
Révocation GID
16
17
TBOX
ABOX
Inférence
Langage de
description
Base de
connaissances
Définition des
concepts et leur
propriétés
Déclaration...
18
Critère de
comparaison
Logique du premier
ordre
Logique de
description
Complexité Calcul des prédicats
semi décidable
A...
19
CClassicδε
comprend tous les connecteurs
de la LD C‐CLASSIC
les connecteurs δ
et ε d’ALδε
21
20
21
La TBOX
Des entités et
relations d’OrBAC
La ABOX
des individus de la
TBOX décrite
(instances)
Représentation
logique
Re...
22
Contexte
défaut
Contexte
exception
δ Est-Permis ⊑ δ Permission ⊓ Habilite ⊓ Utilise
⊓ Considère
Est-Permis ε ⊑ Permissi...
23
Licence
assignement
Rôle
assignement
Licence
Délégation
Grant option
Licence
Licence transfer
Rôle
Délégation
Vues
admi...
24
25
Licence
Délégation
Contexte
exception
Contexte défaut
Délégation
Partielle
Délégation Permanente Délégation Temporaire
...
26
Rôle
Délégation
Délégation totale
Habilite ⊑ UtiliseRD.Rôle_Délégation ⊓ AssigneeRD.bénéficiaire ⊓
AssignmentRD.Rôle.
27
Grant Option
Licence
Contexte
exception
Contexte défaut
Délégation à
n-pas.
Délégation à
1-pas.
 Permission ⊑ UtiliseL...
28
Licence
Transfer
Contexte
exception
Contexte défaut
Délégation
Non monotone
Délégation
Monotone
 Licence_Délégation ⊑ ...
29
30
Révocation GD
Révocation GID
Révocation en
cascade
Définit ⊑ UtiliseL.Licence_Délégation ⊓
CessionnaireL.cessionnaire.
...
31
32
Le Système d’information médical du service de
cardiologie de l’hôpital Frantz-Fanon.
1. Nous avons dressé trois organi...
33
Ajout/modification
/suppression
Ajout /
suppression
Service
d’interrogation
Pour avoir
l’état actuel de
la base
Des ent...
34
Expression de la
délégation
Administration de
la délégation
Révocation avec ses
différents types
Expression des
différe...
35
Nous avons conçu un modèle de sécurité dynamique et
contextuelle où:
 on peut exprimer la délégation avec ses différen...
36
Prendre en compte d’autres contextes tels que le contexte temporel et
spatial.
Intégrer à notre modèle, en plus des per...
37
Prochain SlideShare
Chargement dans…5
×

Modèle de contrôle d'accés

1 040 vues

Publié le

Modèle de contrôle d'accés insipiré d'ORBAC ,

Publié dans : Sciences
1 commentaire
1 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
1 040
Sur SlideShare
0
Issues des intégrations
0
Intégrations
8
Actions
Partages
0
Téléchargements
62
Commentaires
1
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Mesdames membres du jury
    Honorable assistance bonjour,
    aujourd’hui nous allons présenter notre projet de fin d’étude, portant comme intitulé «  Délégation non monotone dans le contrôle d’accès»
    Ce sujet a été proposé et encadré par ….
    Et a été réalisé par moi-même ainsi que ma binome Ziraoui ⊓ .
  • Pour présenter notre projet nous avons dressé le plan suivant :
  • Pour définir la problématique qui a été posée dans notre sujet on décompose son intitulé .
    En décomposant on distingue trois notions : la délégation , la non monotonie , et le contôle d’accés .
    Ainsi la problématique qui a été posé était de :
    Nous detaillerons ces trois notions plus tard

  • premier sujet sur la délégation…. Ce sujet a été traiter au sein de l’ecole nationale supérieure télécom de bretagne , l’institution meme ou est né OrBac ( modèle que nous définirons plus tard ) les caractéristiques de ce sujet est que le modèle de contrôle d’acc »s a été formalisé avec une logique du premier ordre ….
    Deuxième sujet …. Ce sujet a été proposé a l’université de saad dahleb et a l’université de Houari Boumediene mais sa proposition a été faite intialement par le LRIS laboratoire de recherche au sein de l’USTHB , ce modèle a été formalisé avec une logique de description ….
  • Les objectifs que nous avons dressé pour notre projet  :…..
    Ces objectifs permettent de montrer l’apport de notre projet , cet apport consiste à l’utilisation des logiques non monotones dans la modélisation de la délégation mais pas seulement on utilise également ce type de logique pour modéliser les entités et relations d’OrBAC qui nous aident à exprimer la délégation .
  • Les modèles de contrôle d’accès se divise en deux classe : Les modèles de contrôle Discrétionnaire DAC, et les modèles de contrôle obligatoire Mac, on a aussi noté l’apparition du modèle a base de rôle RBAC ,
    L’inconvénient majeur de ces modèles est l’impossibilité de modéliser des permissions dynamiques ,
    D’où l’appariation d’un nouveau modèle de contrôle d’acces nomme OrBac, qui lui, offre la possibilité de modéliser des permission dynamique et contextuelle .
    Nous allons présenter brièvement ce modèle
  • En premier lieu les entites d’OrBAc
    L’entité centrale du modèle OrBac est l’organisation, en effet OrBac est basé sur cette entité.
    Les autres entites d’orbac qui sont : ….
    Sont organisé en deux niveaux( niveaux concret, niveaux abstrait)
  • Dans le modèle OrBac chaque entité du niveau abstrait est une abstraction d’une entité du niveau concret pour les lier OrBac possède des relations .
    Le sujet est mis en correspondance avec le rôle grace a la relation habilite, l’objet avec la vue grace a la relation utilise et l’action avec l’activité grace a la relation considère , le contexte avec toutes les entités concrètes grace a la relation définit ,
    Toutes ses relations sont relié a l’organisation qui demeure l’entité centrale .
  • Dans Orbac , une permission qui est une relation, qui lie quatre entités :rôle , vue , activité et contexte .et cela au niveau abstrait ,
    au niveau concret une permission noté alors, est permis lie les entités sujet , objet et action.
  • Orbac offre la possibilité de modéliser des hiérarchies. Qui ont trois type
    en premier les hiérarchies de rôle en effet un rôle peut avoir des sous rôles et ainsi de suite, le même raisonnement s’applique en deuxième aux vue, et en troisième aux activités
    Cette hiérarchisation est particulièrement utile pour la modélisation du mécanisme d’inférence d’héritage .
  • L‘administration est un élément important d‘une politique de sécurité. Un modèle d‘administration doit permettre de déterminer les utilisateurs qui ont le droit de faire évoluer la politique de sécurité.
    ………………………………………………
    Adorbac comporte en particulier trois sous modèles
    La vue UPA permet la mise en Œuvre des mécanismes de délégation
  • Pour administrer la politique de sécurité il faut définir des fonctions administratives en considérant différentes vues administratives. Les objets qui appartiennent à ces vues ont une sémantique spéciale. On doit prendre en considération deux vues administratives, la première est la vue rôle-assignment et la seconde est la vue licence assignment.
    La vue rôle-assignment : l’objectif de cette vue est d’assigner à un utilisateur un rôle.
    La vue licence assignment: l’objectif de cette vue est de donner la permission à un utilisateur ou un rôle de faire une action ou une activité
  • De manière générale ……
  • Voici les types de délégations , notons que les delegations qui sont dans le meme oval ne peuvent pas avoir lieu en meme temps .
  • La révocation est un aspect important dans les modèles de délégation, quand on délègue un droit il faut pouvoir le révoquer
    Il existe deux types de révocation ,
    Un premier type permet de ne révoquer le droit qu’à une personne désignée c’est une révocation simple. 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

    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
  • La notion de non monotonie dans ce cas est lié au formalisme utilisé pour l’écriture du modèle de sécurité .
    OrBAC est basé sur la logique du premier ordre où le contexte est un simple argument. Le modèle que nous avons réalisé repose sur la logique de description non monotone. Pour mieux définir la notion de non monotonie dans une logique de descriptions on commence par la présentation des logiques de description .

  • Modéliser une base de connaissances en logique de description revient à formaliser une TBOX et une Abox , la Tbox contenant La définition ……
    Et la Abox la declaration des instances c’est-à-dire des individus , toutes deux sont formalisées avec un langage de description , l’inference se fait sur les deux niveaux terminologique pour la TBOX et factuel pour la ABOX
  • Après la présentation de la logique de description nous dressons un tableau comparatif avec les logique des prédicats pour montrer pourquoi il est intéressant de formaliser les modèles de sécurité avec ce genre de logique .
    Du point de vue compléxité , le calcul des predicats ( l’inference) est semi decidable en logique des premier ordre quant aux logiques de decription les algorithmes d’inference sont décidables et parfois meme polynomiaux , il est plus interessant aussi d’utiliser une logique de desecription pour des connaissances structurées commes celles presentes dans les organisation ce qui est notre cas .
  • 1.De nombreux travaux ont été introduits dans le but d’étendre les DLs et d’arriver à un meilleur niveau d’expressivité La  logique  de  description  C‐CLASSIC  est   une variante des logiques de descriptions classiques elle comprend un algorithme de calcul de subsomption polynomial, correct et complet.

    2.ALδε permet d’introduire les notions défauts et exception, qui sont très importantes pour la représentation non monotone de connaissances, symbolisées par les deux connecteurs et ε.
  • Puisque La modélisation de notre modèle de contrôle d’accés s’est faite en logique de description , elle s’est faite suivant la modélisation d’une TBOX et d’une ABOX ,
  • La tbox de notre modèle est une ………..des entités d’orbac et de la délégation .

    La Abox de notre modèle est aussi une représentation logique mais cette fois ci des individus de la Tbox décrite.

    L’inférence dans notre modèle se fait avec le mécanisme d’héritage qui
    fait partie des inférences terminologiques

    Nous allons présenter la tbox représentant la délégation puisque c’est le but de notre étude .
    Avant dela nous prestons les regles de securité appliqué dans notre modèle

  • Une permission par défaut existe pour un rôle R, une activité Av et une vue V dans une organisation Or (δ Permission) .
    Un sujet S est habilité dans ce rôle R (Habilite) .
    Un objet O est utilisé dans cette vue V (Utilise) .
    Une action Ac implémente cette activité Av (Considère).
    Alors Le sujet S est par défaut permis d’effectuer l’action Ac sur l’objet O (δ Est- Permis).
    Etant donné que Est-Permis ⊑ δ Est-Permis (une permission concrète peut être déduite D’une permission par défaut), on peut dire finalement que le sujet S a la permission D’effectuer l’action Ac sur l’objet O.
    Dans le cas où on a une exception sur un concept permission (Permission ε), on dit qu’on a une exception sur le concept Est-Permis noté Est-Permis ε. On sait que Est- Permis (une permission concrète ne peut être déduite d’une permission exceptionnelle), de cela on déduit que le sujet S n’est pas permis d’effectuer l’action Ac sur l’objet O.
    Aussi dans notre modèle : ……..

  • Pour modéliser la délégation nous avons choisi d’utiliser les vues administratives définies dans AdOrbac : Licence assignement, Rôle assignement
    De La vue licence assignement hérite la vue Licence délégation et de la vue rôle assignement hérite la vue rôle délégation
    Ces vues ont les mêmes attributs que les vues administratives Avec un attribut supplémentaire appelé le cessionnaire, en plus de cela . de la vue licence délégation hérite deux autre vue : la vue licence transfert et la vue Grant Option Licence qu’on définira plus tard dans la modélisation de types de délégation .

  • Dans notre modèle la délégation est auto-active et a accord unilateral , bien que nous n’avons pas modélisé ces deux types de delegations , ils sont modélisé implicitement , puisque le cessionnaire dans notre modèle et le détenteur du droit et qu’il délègue ses droits sans accord de la partie bénéficiaire .
  • Pour modéliser une délégation partielle , on utilise la vue licence délégation , dans un contexte défaut , la délégation est permanente , et dans un contexte exception la délégation est temporaire .

    Par défaut le bénéficiaire de la licence délégation aura la permission de faire l’action Action sur l’objet Objet .

    Dans un contexte exception le bénéficiaire perd la permission de faire l’action Action sur l’objet Objet .
  • Pour modéliser une délégation totale, on utilise la vue rôle délégation,
    Avec cette règle , Le bénéficiaire de la rôle délégation sera habilité a faire le role «  role »
  • Pour modéliser une délégation à 1 pas /à n pas , on utilise la vue grant option licence , dans un contexte défaut , la délégation est une délégation à n pas , et dans un contexte exception la délégation est une délégation à 1 pas .

    Par défaut le bénéficiaire de la délégation a n pas aura la permission de faire l’action Action sur l’objet Objet tant que son niveau lui permet .

    Dans un contexte exception le bénéficiaire a la permission de faire l’action Action sur l’objet Objet seulement si son niveau est egal au niveau max de la permission que laquelle on a généré l’exception.
  • Pour modéliser la délégation monotone/non monotone utilise la vue licence transfer pour modéliser , dans un contexte défaut , la délégation est non monotone , et dans un contexte exception la délégation est monotone .
    Dans un contexte defaut si (L) appartient à la vue licence_délégation alors (L) appartient aussi à la vue licence_transfer en d’autre L sera une licence transferable ( l’utilisateur perdra le droit qu’il délègue)

    Dans un contexte exception si (L) appartient à la vue licence_délégation alors (L) ne vas plus appartenir aussi à la vue licence_transfer
    L n’est plus transferable c’est-à-dire que l’utilisateur conserve le droit qu’il délègue .
  • Avec une révocation GD seul le cessionnaire peut révoquer les droits données par la licence qu’il a délégué .
    si (L) appartient à la vue licence_ délégation et (cessionnaire) est le cessionnaire de (L) alors le cessionnaire détient l’autorisation de révoquer (L) .

    Avec une revocation GID chaque utilisateur qui a délégué un droit meme si il nest pas le cessionnaire initiale peut revoquer ce droit
    si (L) appartient à la vue licence_ délégation,
    (cessionnaire) est le cessionnaire de (L),
    (GR) est habilité à faire le Rôle,
    Et (U) est habilité à faire le Rôle alors l’utilisateur (U) détient l’autorisation de révoquer (L).


    POUR la revocation en cascade
    On definit une nouvelle vue , vue delegation en cascade la suppression des objets appartenant a cette vue conduira à une révocation en cascade , notons que la vue delegation en cascade herite de la vue licence delegation.
  • Pour appliquer notre modèle nous avons choisi un système d’information médical , ce choix nous a paru évident vue que le modèle OrBAC a été initialement crée pour le domaine médical .le système d’information qu’on a choisi est le
  • En conclusion les objectifs initiaux ont été atteint ………..il reste tout de meme un certain nombre de perspectives à ce projet …
  • Modèle de contrôle d'accés

    1. 1. Présenté par : Bouafia Doria. Ziraoui Bouchra. Proposé et encadré: Docteur N.Boustia. 1
    2. 2. 1. Problématique . 2. Travaux réalisés dans le même axe de recherche ( la délégation). 3. Objectifs . 4. Le contrôle d’accès. 5. La délégation . 6. La notion de non monotonie. 7. Modélisation . 8. Réalisation . 9. Conclusion et perspectives . 2
    3. 3. réaliser un modèle de contrôle d’accès comprenant la modélisation du concept de délégation formalisé avec une logique non monotone . 3 Délégation non monotone dans le contrôle d’accès
    4. 4. 4 Sujet Institution/ organisme de recherche Caractéristiques Managing Delegation in Access Control Models ENST BRETAGNE • Modèle de délégation pour OrBAC • Formalisme utilisé : logique du premier ordre La délégation des permissions dans le contrôle d’accès avec logique de description Saad Dahleb/ LRIS -USTHB • Modèle de délégation pour OrBAC • Formalisme utilisé: logique de description.
    5. 5. 5 I. Conception d’un modèle de contrôle d’accès : 1) Inspiré d’OrBAC. 2) Incluant la modélisation de la délégation . 3) Basé sur une logique non monotone qui est une logique défaut () et exception (). II. Application de ce modèle sur un exemple concret.
    6. 6. les modèles de contrôle d'accès discrétionnaires. DAC les modèles de contrôle d'accès obligatoires. MAC Modèle de sécurité à base de rôle. RBAC Inconvénient Majeur : Ces modèles ne permettent de modéliser que les politiques de sécurité qui se restreignent à des permissions statiques .[1] 6 [1]:Anas Abou El Kalam, Rania El Baida, Philippe Balbiani,Salem Benferhat,Frédéric Cuppens, Yves Deswarte, Alexandre Miège,Claire Saurel, Gilles Trouessin, « ORBAC : un modèle de contrôle d’accès basé sur les organisations », projet RNRT MP6 (Modèles et Politiques de Sécurité des Systèmes d’ Informations et de Communication en Santé et en Social). OrBAC
    7. 7. 7 organisation Action sujet Activité contexte Objet Rôle Vue Niveau concret Niveau abstrait
    8. 8. 8 Action sujet Activité contexte Objet Rôle Vue Habilite Utilise Considère Organisation Définit
    9. 9. 9 Action sujet Activité contexte Objet Rôle Vue Permission Est-Permis Niveau concret Niveau abstrait
    10. 10. 10 L’organisation VueRôle Activité Sous- rôle1 Sous- rôle2 Sous- vue1 Sous- vue2 Sous- Activité1 Sous- Activité2 1 2 3
    11. 11. 11 Le modèle AdOr-BAC permet d‘administrer une politique de sécurité Or- BAC. Il permet de gérer toutes ces relations. [2] PRA (Permission-Role Assignment) URA (User-Role Assignment) : UPA (User-Permission Assignment) : Délégation [2]:Mokhtari Mohamed Amine ,Ghersi Cherifa « Mémoire pour l’obtention d’un Master « Délégation dans le contrôle d’accès avec logique de description » , juillet 2012
    12. 12. 12 Rôle assignment Licence assignment
    13. 13. 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. [3] [3]:www.orbac.org. 13
    14. 14. 14 Délégation temporaire/ permanente Délégation monotone/non monotone Délégation Grant- dependant/Grant- independant Délégation par accord unilatéral/bilatéral Délégation totale/partielle Délégation simple/multiple Délégation par agent /auto-active Délégation à un-pas/à pas-multiple
    15. 15. 15 Révocation simple Révocation GD Révocation en cascade Révocation GID
    16. 16. 16
    17. 17. 17 TBOX ABOX Inférence Langage de description Base de connaissances Définition des concepts et leur propriétés Déclaration des instances ( individus)
    18. 18. 18 Critère de comparaison Logique du premier ordre Logique de description Complexité Calcul des prédicats semi décidable Algorithmes d’inférence décidables et parfois polynomiaux. Structuration des connaissances NON OUI
    19. 19. 19 CClassicδε comprend tous les connecteurs de la LD C‐CLASSIC les connecteurs δ et ε d’ALδε 21
    20. 20. 20
    21. 21. 21 La TBOX Des entités et relations d’OrBAC La ABOX des individus de la TBOX décrite (instances) Représentation logique Représentation logique De la délégation Héritage
    22. 22. 22 Contexte défaut Contexte exception δ Est-Permis ⊑ δ Permission ⊓ Habilite ⊓ Utilise ⊓ Considère Est-Permis ε ⊑ Permission ε ⊓ Habilite ⊓ Utilise ⊓ Considère  Par défaut, le contexte est normal·  toute action qui n’est pas permise est interdite. Est-Permis ⊑ Est-Permis ε Est-Permis ⊑ δ Est-Permis
    23. 23. 23 Licence assignement Rôle assignement Licence Délégation Grant option Licence Licence transfer Rôle Délégation Vues administratives Vues de Délégation Cessionnaire C’est un sujet ou un rôle qui délègue une licence, c’est le délégant.
    24. 24. 24
    25. 25. 25 Licence Délégation Contexte exception Contexte défaut Délégation Partielle Délégation Permanente Délégation Temporaire  Permission ⊑ UtiliseL.Licence_Délégation ⊓ BénéficiaireL.bénéficiaire ⊓ PrivilègeL.Action⊓ CibleL.Objet . Permission ε ⊑ UtiliseL.Licence_Délégation ⊓ BénéficiaireL.bénéficiaire ⊓ PrivilègeL.Action⊓ CibleL.Objet . 1 1 2 2
    26. 26. 26 Rôle Délégation Délégation totale Habilite ⊑ UtiliseRD.Rôle_Délégation ⊓ AssigneeRD.bénéficiaire ⊓ AssignmentRD.Rôle.
    27. 27. 27 Grant Option Licence Contexte exception Contexte défaut Délégation à n-pas. Délégation à 1-pas.  Permission ⊑ UtiliseL.GOL ⊓ BénéficiaireL.bénéficiaire⊓ PrivilègeL.Action ⊓ CibleL.Objet ⊓ niveau <=niveauMax Permission ⊑ UtiliseL.GOL ⊓ BénéficiaireL.bénéficiaire⊓ PrivilègeL.Action ⊓ Cible.Objet⊓ niveau <=niveauMax 1 1 2 2
    28. 28. 28 Licence Transfer Contexte exception Contexte défaut Délégation Non monotone Délégation Monotone  Licence_Délégation ⊑ UtiliseL.licence_transfer Licence_Délégation  ⊑ UtiliseL.licence_transfer 1 1 2 2
    29. 29. 29
    30. 30. 30 Révocation GD Révocation GID Révocation en cascade Définit ⊑ UtiliseL.Licence_Délégation ⊓ CessionnaireL.cessionnaire. Définit ⊑ UtiliseL.Licence_Délégation ⊓ CessionnaireL.cessionnaire ⊓ HabiliteGR.Rôle⊓ HabiliteU.Rôle. Délégation en cascade Licence délégation
    31. 31. 31
    32. 32. 32 Le Système d’information médical du service de cardiologie de l’hôpital Frantz-Fanon. 1. Nous avons dressé trois organigrammes pour la hiérarchisation de rôles , d’activités et de vues . 2. Cette hiérarchisation est particulièrement utile pour appliquer le mécanisme d’inférence d’héritage . 3. Nous avons dressé une ABOX reflétant le service de cardiologie tel qu’il est, en prenant en considération que les rôles principaux vue l’effectif de ce service.
    33. 33. 33 Ajout/modification /suppression Ajout / suppression Service d’interrogation Pour avoir l’état actuel de la base Des entités OrBAC Des relations OrBAC
    34. 34. 34 Expression de la délégation Administration de la délégation Révocation avec ses différents types Expression des différents types de délégation Gestion de cessionnaires
    35. 35. 35 Nous avons conçu un modèle de sécurité dynamique et contextuelle où:  on peut exprimer la délégation avec ses différents types en utilisant les entités et relations définies dans le modèle OrBAC.  la modélisation a été réalisée avec une logique de description augmentée des operateurs  et  pour l’expression du contexte .
    36. 36. 36 Prendre en compte d’autres contextes tels que le contexte temporel et spatial. Intégrer à notre modèle, en plus des permissions les obligations et les recommandations. Etendre la prise en charge des types de délégations à tous les types existants .
    37. 37. 37

    ×