Transcript Document

ABAC et XACML

Attribute Based Access Control eXtensible Access Control Markup Language INF6153 1

ABAC et XACML

 ABAC = Attribute Based Access Control  XACML = eXtensible Access Control Markup Language  ABAC est un modèle de contrôle d’accès  XACML est un langage standardisé utilisant le modèle ABAC INF6153 2

Attribute Based Access Control

   Dans ABAC, la décision est prise sur la base de conditions booléennes sur des valeurs d’attributs Sujet Ressource et Action sont des catégories qui regroupent des attributs    P.ex. attributs du sujet pourraient être: âge, rôle, nom, type etc … Les attributs ont des valeurs P.ex. Nom(sujet)=Gervais, Genre(sujet)=masculin, Age(sujet)=25, Identif(action)=écriture, Type(action)=modification La requête de contrôle d’accès est un ensemble de couples (attribut=valeur) – elle représente l’état du demandeur    P. ex. (Nom(sujet)=Gervais) et (Age(sujet)= 25) et (Identif(action)=lecture) et (Identif(ressource)=livre RBAC) Les règles de contrôle d’accès sont basées sur des cibles représentées par des expressions booléennes – la logique Permettre si (Type(sujet)= étudiant) et (Type(action)= consultation) et (Type(ressource)=livre en réserve) et (Temps(requête)= heures de travail) INF6153 3

Autre Exemple de Condition

    Le sujet qui fait requête est un étudiant de notre université Il est localisé dans le bâtiment Taché ou Brault, pas St-Jerôme L’heure est entre 8h et 20h Il n’est pas dimanche INF6153 4

Règles et politiques

 Les règles nous les avons vues  Les politiques sont des ensembles de règles  Normalement les règles dans une politique sont reliées par une idée commune  P.ex. on pourrait avoir des politique:  accès à la bibliothèque virtuelle   qui réunit toutes les règles qui déterminent l’accès à cette bibliothèque accès aux dossiers de comptabilité 

INF6153 5

Éléments architecturels de ABAC

    PEP: Policy Enforcement Point:  Donne ou refuse un accès PDP: Policy Decision Point:  Prend la décision si l’accès doit être donné ou refusé  Utilisant les politiques et règles qui sont enregistrées dans une base de données appelée Policy Store PAP: Policy Administration Point  Gère le Policy Store: ajout, enlèvement de politique PIP: Policy Information Point - fournit les informations dont le PDP a besoin pour prendre ses décisions   Les modèle d’attributs et les ontologies, v. après L’état de l’environnement:    P.ex. l’heure Location de l’usager ou de la ressource Etc.

6 INF6153

ABAC Schéma architecturel

DP: Digital Policy INF6153 Source: NIST Special Publication 800-162 7

Implémentation

 Différentes implémentations sont possibles  

Le PEP est associé à l’objet et les PDP-PIP sont à distance On peut avoir plusieurs PEPs pour plusieurs objets

Mais aussi, on peut avoir dans le PEP des politiques déjà actualisées sans avoir besoin d’accès continu au PDP

INF6153 8

Modèle d’attributs

     Un système ABAC a un modèle qui connaît tous les attributs qui peuvent être utilisés, dans des requêtes ou dans des règles Dans le modèle, les valeurs peuvent être organisés en ontologies, p.ex. on peut savoir      qu’un ‘fichier d’inventaire’ est un ‘fichier de comptabilité’ qu’il est au niveau ‘secret’ qu’un ‘acroread’ est un type de ‘read’ qu’un ‘professeur auxiliaire’ est un ‘professeur’ qu’il y a différents types d’étudiants:  à temps plein, à temps partiel, de 1er cycle, de 2ème cycle etc.

Les hiérarchies de rôles, s’il y en a, sont donc stockées dans cette base de données Ainsi que les niveaux d’autorisation s’il est désiré d’implémenter MAC Etc.

INF6153 9

Ontologies

   Une ontologie est un ensemble de concepts reliés par des relations   Un ensemble de connaissances formalisé est une ontologie  P.ex. le système métrique Une structure organisationnelle, une hiérarchie de rôles est une ontologie Les ontologies sont importantes dans le cas d’entités qui doivent partager un ensemble de connaissances Elles établissent les concepts sur lesquels les entités doivent être d’accord, concepts qui rendent la communication possible  P.ex. dans le cas du commerce électronique  Un catalogue est une ontologie qui établit un ensemble de connaissances communes entre vendeur et acheteurs INF6153 10

Le PDP comme moteur d’inférence

     Si le PEP informe le PDP que: 

(Jamel) demande (d’entrer) (à la bibliothèque) à (22h),

Le PDP doit trouver dans le Policy Store la règle appropriée: 

Refuser (aux étudiants) (l’accès) (aux locaux de l’université) (après 20h)

Mais il ne sait pas que Jamel est un étudiant, qu’il est après 20h etc Après requête du PDP, le PIP informe le PDP que, sur la base des attributs    

Jamel est un étudiant à temps partiel un étudiant à temps partiel est un étudiant entrer est un accès la bibliothèque est un local de l’université

Le PIP informe aussi le PDP que, sur la base de l’état de l’environnement 

nous sommes à 22h>20h.

  Le PDP conclut que la demande d’accès doit être niée Le PDP en informe le PEP qui informe l’étudiant INF6153 11

Point intéressant, Independence des sujets

 Contrairement à presque tous les modèles discutés dans ce cours, le fonctionnement d’ABAC ne dépend pas de l’existence d’une liste prédéfinie de sujets:  

« aucun ne peut lire des fichiers réservés en dehors des heures de travail » « un employé aux prêts ne peut pas avoir accès aux fichiers des investissements »

INF6153 12

Cohérence globale

 Une difficulté pour les systèmes ABAC est le fait que la terminologie et les concepts (l’ontologie) doivent être cohérents dans les différentes composantes  p.ex. dans l’exemple précédent, le PDP, PIP et PAP doivent avoir la même compréhension de:    « Jamel » « étudiant » « bibliothèque » « local de l’Université » « 22h »   Est-ce-vrai? réfléchissez sur cet exemple et déterminer exactement quels concepts doivent être connus par les différentes entités du système, et quel types de connaissances doivent être partagés entre les entités Ceci n’est pas facile à planifier et doit être cohérent avec la politique de l’organisation INF6153 13

+ et -

+

D’un côté ABAC permet de représenter les politiques d’une organisation avec des critères plus complexes et détaillés que MAC ou RBAC on peut utiliser un nombre illimité d’attributs et des expressions booléennes complexes

-

D’un autre côté il exige une planification des concepts d’entreprise (ontologies) beaucoup plus complexe que ce qui est demandé par MAC ou RBAC

+

Nous verrons que MAC et RBAC peuvent être implémentés en ABAC INF6153 14

Meta règles de résolution de conflits

 Si le PDP détecte des règles qui conduisent à des décisions opposés, il fait référence à des métarègles qui pourraient avoir été fournies par l’administrateur  Métarègles: règles pour déterminer l’exécution de règles  P.ex.:   Deny overrides: s’il y a une règle qui nie l’accès, elle est appliquée malgré autres règles qui pourraient le permettre  On utilise celle-ci si on désire limiter l’accès le plus possible Permit overrides: s’il y a une règle qui permet l’accès, elle est appliquée malgré autres règles qui pourraient l’empêcher INF6153 15

Utilisation de ABAC pour plusieurs organisations

INF6153 16

Cas pratique pour l’exemple précédent

   Plusieurs organisations partagent une base de données Chacune a des critères d’accès basés sur les informations qui l’intéressent Exemple:  

Citoyenneté Canada et Revenu Canada utilisent la même base de données, mais chacune selon ses propres critères:

 

Citoyenneté Canada pourrait dire qu’un certain type d’employé n’a pas accès aux dossiers des personnes ayant obtenu la citoyenneté avant l’an 2000 Revenu Canada pourrait dire qu’un certain type d’employé n’a pas accès aux dossiers de personnes qui font plus de 30,000$/an Le PDP doit être capable de prendre des décisions d’accès basées sur les critères de l’un ou de l’autre, selon l’origine de la requête

INF6153 17

Ontologies communes

 Afin que ceci fonctionne, toutes les organisations impliquées doivent utiliser les mêmes concepts dans leur Attribute Store   Conformes à ceux qui sont utilisés dans le PDP auquel tous font accès Cette cohérence est difficile à obtenir en pratique:  Le problème est déjà assez difficile pour une seule organisation … INF6153 18

« Trust Chain » ou Chaîne de confiance

 La « chaîne de confiance » est la chaîne de tous les usagers ou composants sur lesquels repose la fiabilité du mécanisme de décision  S’il y a une faille, on cherche le responsable en parcourant cette chaîne  Au fur et à mesure que la technique de contrôle d’accès devient plus complexe, la « chaîne de confiance » devient plus longue et complexe INF6153 19

Chaîne de confiance simple pour les Access Control Lists (DAC-ACL)

Essentiellement, dans DAC-ACL la confiance repose sur les propriétaire des objets qui créent les ACL INF6153 20

Chaîne de confiance plus complexe pour ABAC

Dans ABAC, la chaîne de confiance inclut plusieurs sources sur lesquelles le propriétaire de l’objet n’a aucun contrôle: les créateurs et classeurs des attributs (taxonomies et ontologies), les développeurs de politiques, etc. INF6153 21

ABAC, XACML, OASIS

 XACML est une norme de OASIS, qui donne une définition précise de ABAC, avec des variations et des extensions   Une architecture normalisée Un langage basé sur XML  Cette norme est en développement depuis plusieurs années et la première version a été disponible en 2003  Nous sommes à la 3ème version de 2013  OASIS: https://www.oasis-open.org/   Organization for the Advancement of Structured Information Standards Une organisation de normalisation internationale, qui travaille sur plusieurs normes de sécurité INF6153 22

XACML fournit

 Une architecture de système, une base pour l’implémentation  Des principes de communication entre les composants  Un langage pour les règles et le politiques  Un langage pour les requêtes et les réponses  Types de données normalisés, fonctions, algorithmes de combinaison  Extensibilité  Différents profils 

Pour RBAC, pour l’intimité …

INF6153 23

XACML Architecture

INF6153 24

Policy Enforcement point

• Reçoit les demandes d’accès • Fait des requêtes concernant les demandes d’accès et met en œuvre les réponses • Permission ou refus • Invoque le service des obligations INF6153 25

PAP: Policy Administration Point

Entretien de la base de données des politiques INF6153 26

PDP: Policy Decision Point

• • • • Contient la base de données des politiques Traite les requêtes d’accès Recherche et évalue les politiques pertinentes Retourne la décision au PEP INF6153 27

PIP: Policy Information Point

Contient et distribue les informations nécessaires pour l’évaluation des règles.

INF6153 28

Context Handler

• • Fait la conversion entre le format utilisé à l’extérieur du système et celui utilisé à l’intérieur • le format XACML Centre de relai pour le système • (Donc les usagers d’un système XACML ne sont pas obligés d’utiliser le langage XACML) INF6153 29

Contexts

xacml Policy.xml

domain-specific inputs xacml Context/ Request.xml

PDP xacml Context/ Response.xml

domain-specific outputs INF6153 30

Dans l’ensemble …

INF6153 Conversion de format  XACML 31

Tel que décrit dans la norme

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

PAPs

write

policies

and

policy sets

and make them available to the

PDP

. These

policies

or

policy sets

represent the complete

policy

for a specified

target

.

The

access

requester sends a request for

access

to the

PEP

.

The

PEP

sends the request for

access

to the

context handler

in its native request format, optionally including

attributes

of the

subjects

,

resource

,

action

,

environment

and other categories.

The

context handler

constructs an XACML request

context

, optionally adds attributes, and sends it to the

PDP

.

The

PDP

requests any additional

subject

,

resource

,

action

,

environment

and other categories (not shown)

attributes

from the

context handler

.

The

context handler

requests the

attributes

from a

PIP

.

The

PIP

obtains the requested

attributes

.

The

PIP

returns the requested

attributes

to the

context handler

.

Optionally, the

context handler

includes the

resource

in the

context

.

The

context handler

sends the requested

attributes

and (optionally) the

resource

to the

PDP

. The

PDP

evaluates the

policy

.

The

PDP

returns the response

context

(including the

authorization decision

) to the

context handler

.

The

context handler

translates the response

context

to the native response format of the

PEP

. The

context handler

returns the response to the

PEP

.

The

PEP

fulfills the

obligations

.

(Not shown) If

access

is permitted, then the

PEP

the

resource

; otherwise, it denies

access

.

permits

access

to INF6153 32

Concernant le fonctionnement interne

 La norme XACML dit peu sur le fonctionnement interne des différentes composantes  Il se limite aux fonctionnalités d’évaluation logique des requêtes et politiques  Beaucoup d’intelligence pourrait se trouver dans les PDP et PIP, mais la norme n’en parle presque pas  Laissé à l’implémentation, évidemment INF6153 33

Exemples du langage XACML

 XACML est un langage complexe avec beaucoup d’options, voici une idée générale … INF6153 34

Exemple de requête

Bart Simpson, with e-mail name " [email protected]

", wants to read his medical record at Medi Corp.

< Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 http://docs.oasis-open.org/xacml/3.0/xacml-core-v3-schema-wd-17.xsd" ReturnPolicyIdList="false">

[email protected]

file://example/med/record/patient/BartSimpson

read

INF6153 35

Formalisation

Name(subject-id (subject)) = [email protected]

 URI(resource-id(resource)) = file://example/med/record/patient/BartSimpson  String(action-id(action)) = read INF6153 36

Concept de catégorie et d’attributs

 Les catégories peuvent avoir attributs  Dans XACML 2, il n’y avait que les catégories conventionnelles: 

Sujet, Action, Ressource, Environnement

 Dans XACML 3, on peut définir des nouvelles catégorie avec leurs propres attributs, ce qui augmente la flexibilité du langage 

P.ex. Service

 Ceci permet d’ajouter des conditions relatives aux nouvelles catégories: 

Nom(Sujet)=X et … et Ident(Service)=RéservationHotel

INF6153 37

Policy Language Model

INF6153 38

Structure de Politiques et règles

INF6153 39

Cibles ou Targets

 Les ensembles de politiques, politiques et règles contiennent des cibles qui identifient les cas où ils sont applicables INF6153 40

Target-Cible:

doctors, read or write med records

read

write

doctor

medical record

INF6153 41

Structure simplifiée…

    Any of  All of  Read   /All of All of  Write  /All of /Any of Any of   All of  Doctor  Medical Record /All of /Any of Read ou write Pour tous les docteurs et medical records INF6153 42

Cible dans les politiques et règles

 Expression booléenne qui détermine les conditions pour l’application de la politique ou règle  Les cibles contiennent des AnyOf qui contiennent des AndOf – sans emboîtement ultérieur (v. diagr. UML)  Il y a une conjonction implicite au 1 er niveau  Exemple précédent en logique: 

(Name(action)=read

Role(subject)=doctor

Name(action)=write)

Type(resource)=med_rec

 Quand une requête arrive, le PDP cherche les policy sets, politique et règle qui correspondent à la requête 

utilisant les cibles

INF6153 43

Un docteur demande d’écrire sur un dossier médical La requête Cible de la règle

Name(subject-id (subject)) = [email protected]

URI(resource-id(resource)) = file://example/med/record/patient/BartSimpson String(action-id(action)) = read À l’aide de l’information obtenues du PIP, le PDP décide que la politique de droite est applicable à la requête de gauche     Any of  All of  Name(action)=read   /All of All of  Name(action)=write  /All of /Any of Any of   All of  Role(subject)=doctor  Type(resource)=med_rec /All of /Any of INF6153 Transformation effectuée utilisant les infos du PIP 44

Règles

 Une règle XACML contient   Effet: la décision: permit ou deny Cible: condition booléenne qui détermine l’applicabilité de la règle par rapport aux éléments de la requête et aux éléments fournis par le PIP   Obligations: choses à faire par le PEP après l’évaluation de la règle   P.ex.: noter la décision prise dans un log; ou envoyer un courriel Une ‘obligation expression’ dans une règle peut prescrire plusieurs obligations et des conditions booléennes pour spécifier quelles obligations sont à exécuter dans chaque cas Avis: comme les obligations mais peuvent être ignorées par le PEP INF6153 45

Politiques, Ensembles de politiques

 Les Policies et Policy sets contiennent:    

Cible Algorithmes de combinaison de règles Un ensemble de règles Obligations

 

Advices

Quelques autres choses reliées INF6153 46

Exemple de règles définissables en XACML

 A person may read any record for which he or she is the designated patient.

 A person may read any record for which he or she is the designated parent or guardian, and for which the patient is under 16 years of age.

 A physician may write to any medical element for which he or she is the designated primary care physician, provided an email is sent to the patient.  An administrator shall not be permitted to read or write to medical elements of a patient record.

INF6153 47

Exemple de politique contenant quatre règles

Politique pour la lecture écriture des documents des patients

    

Permit: Role(subject)=patient

Le patient peut lire ses documents Name(action)=read; Permit: (Role(subject)=parent

Name(action)=read; Role(subject)=guardian)

Les parents ou gardiens peuvent lire les documents des mineurs

Age(patient) < 16

Permit: Role(subject)=primary_physician

Name(action)=write; Obligation: send notification

Les docteurs peuvent écrire sur les documents de leur patients, mais une notif doit être envoyée Deny: Role(subject)=administrator Name(action=write));

 

( Name(action)=read

Les administrateurs ne peuvent ni lire ni écrire sur les documents des patients

INF6153 48

Précisions ultérieures

 Quelques détails sont omis, p.ex. il faudrait préciser   qu’un patient ne peut lire que les docs qui se réfèrent à lui même etc.

Exercice: trouver toutes les conditions nécessaires

INF6153 49

Exercice

 Déterminer comment ces quatre règles peuvent être codées en XACML utilisant « Any-of » et « All-of »  Cet exemple est pris de la norme XACML et la solution complète se trouve là-dedans INF6153 50

Politiques et algorithmes de combinaison

    Nous avons vu que, dans une politique ou ensemble de politiques, il pourrait y avoir plusieurs règles applicables pour une requête donnée Ces règles pourraient donner des résultats différents Les algorithmes de combinaison sont associés aux politiques (et ensembles de politiques) pour déterminer le résultat dans ces cas C’est l’administrateur des politiques qui détermine l’algorithme de combinaison à utiliser dans chaque politique (ou ensemble de politiques) INF6153 51

Pourquoi plusieurs règles applicables

 Le PID pourrait retourner plusieurs valeurs pour certains attributs  Alice pourrait être programmeur, aussi représentante syndicale, etc.

 On pourrait avoir des règles et des exceptions   Seulement le médecin d’un patient peut lire le dossier du patient Dans un cas d’urgence, une infirmière peut aussi  On pourrait avoir des combinaisons de règles de différentes origines  Règles pour toute la division, règles pour un bureau particulier  On pourrait évidemment avoir des erreurs INF6153 52

       

Algorithmes de combinaison

  Chaque règle dans une politique doit avoir comme résultat un des suivants: 

Permit, deny, indeterminate

 Le résultat est indeterminate quand il y a une erreur dans l’évaluation d’une règle   Ces cas sont prévus explicitement dans la méthode d’évaluation des règles P.ex. la règle n’est pas écrite correctement, des éléments manquent, etc.

Les algorithmes suivants peuvent être utilisés et leur résultat peut être un des suivants:  Permit, deny, indeterminate, not applicable Deny overrides Permit overrides Deny unless permit Permit unless deny First applicable Only one applicable Etc.

Aussi, l’usager peut définir ses propres algorithmes INF6153 53

Statut d’erreur pour Indeterminate

 Indeterminate{D}  Peut être retourné par une évaluation qui aurait pu terminer dans une Deny s’il n’y avait pas une erreur  Indeterminate {P}  Pareil pour Permit  Indeterminate{DP}  Pareil pour Permit ou Deny  Le statut d’erreur peut être utilisé par le système,  p.ex. des programmes peuvent être écrits pour prendre des décisions ultérieures sur la base du statut INF6153 54

Exemple: deny overrides

       If any decision is "Deny", the result is "Deny".

Otherwise, if any decision is "Indeterminate{DP}", the result is "Indeterminate{DP}".

Otherwise, if any decision is "Indeterminate{D}" and another decision is “Indeterminate{P} or Permit, the result is "Indeterminate{DP}".

Otherwise, if any decision is "Indeterminate{D}", the result is "Indeterminate{D}".

Otherwise, if any decision is "Permit", the result is "Permit".

Otherwise, if any decision is "Indeterminate{P}", the result is "Indeterminate{P}".

Otherwise, the result is "NotApplicable".

INF6153 55

Exemple: only one applicable

    If only one policy is considered applicable by evaluation of its target, then the result of the policy-combining algorithm is the result of evaluating the policy. If more than one policy is considered applicable by virtue of its target, then the result of the policy-combination algorithm is "Indeterminate".

If no policy is considered applicable by virtue of its target, then the result of the policy-combination algorithm is "NotApplicable". If an error occurs while evaluating the target of a policy, or a reference to a policy is considered invalid or the policy evaluation results in "Indeterminate", then the policy set is "Indeterminate", with the appropriate error status {P}, {D} ou {DP} .

INF6153 56

Algorithmes de combinaison de règles et de politiques

 Les algorithmes de combinaison peuvent être appliqués 

Entre règles

Entre politiques

 Ils peuvent donc exister aux deux niveaux INF6153 57

Exemple de réponse

[c1] [c2] [c3] [c4] [c5] NotApplicable [c6] Une réponse « Not applicable » ou « Indeterminate » a pour résultat de refuser l’accès: équivalente à « Deny » Cependant ceci peut être nuancé comme nous avons vu pour Indeterminate INF6153 58

Obligations et avis

 Une réponse peut impliquer des Obligations ou des Avis, qui sont des actions à exécuter par le PEP après la réponse  Leur applicabilité peut être assujettie à des expressions conditionnelles  Les obligations doivent être exécutées par le PEP, les Avis peuvent être ignorés 

Exemples:

  

Envoyer un courriel à l’administrateur, au titulaire du dossier Faire un enregistrement dans un fichier de contrôle Etc.

INF6153 59

Séparation de tâches

 Pour la séparation de tâches statique, XACML offre la possibilité de spécifier, au niveau des politiques, que certaines combinaisons d’attributs ne sont pas permises Policy PolicyId="contractor:AND:employee:disallowed RuleCombiningAlgId="&rule-combine;deny-overrides  La séparation de tâches dynamique est laissée comme exercice, mais voir: http://docs.oasis-open.org/xacml/cd-xacml-rbac-profile-01.pdf

INF6153 60

Délégation

     La délégation permet à un sujet de donner ses permissions, en tout ou en partie, à un autre sujet  normalement pour un temps déterminé Les droits de délégation sont séparés des droits d’accès  Ils sont considérés comme des politiques administratives  donc les politiques d’accès ne changent pas XACML 3 a un modèle de délégation assez sophistiqué  Il est basé sur le modèle d’administration de XACML Le concept de ‘propriétaire’ de ressource est défini comme dans DAC Un propriétaire peut déléguer l’administration de ses ressources INF6153 61

Exemple

Le concept de ‘propriétaire’ de ressource est défini comme dans DAC

Le propriétaire a droits d’administration et peut les déléguer Le propriétaire ou son délégué peuvent donner des permissions

On peut avoir plusieurs niveaux de délégation Avant de permettre à Carol d’utiliser l’imprimante, le PDP doit vérifier la chaîne entière des délégations, jusqu’au propriétaire INF6153 Source: Gerry Gebel, XACML 3.0 Enhancements 62

Puissance de XACML-ABAC

      Il peut être utilisé pour MAC car les niveaux de sécurité peuvent être des attributs des usagers et objets  Cependant XACML manque la capacité de prévenir des exceptions à MAC, donc il n’est pas vraiment ‘mandatory’ Il peut être utilisé pour DAC avec son modèle d’administration et propriété Il peut être utilisé pour RBAC car le rôle est un attribut du sujet   Il y a dans XACML un ‘profil RBAC’ qui peut être utilisé pour écrire RBAC en XACML Cependant dans XACML il est beaucoup plus difficile de répondre à la question:  Quels sont les permissions d’un sujet spécifique, d’un rôle spécifique?

XACML a aussi des profils pour la protection de la propriété intellectuelle:  Copyright, Brévet etc.

L’implémentation de XACML est plus complexe que l’implémentation de RBAC V. ce qui a été dit pour ABAC INF6153 63

Exercice

 Déterminer que XACML est en fait capable de représenter RBAC 0, 1, 2, et 3  Il y a des articles sur ceci dans la litérature … 

http://docs.oasis-open.org/xacml/cd-xacml-rbac-profile 01.pdf

 Cette proposition pourrait être trop compliquée INF6153 64

Optimisation

 En pratique, plusieurs raccourcis ou raffinements peuvent être utilisés pour améliorer la performance du système, ou l’adapter  Exemples:      Le PEP pourrait inclure des décisions déjà pré-calculées pour des cas fréquents (cache) Des éléments différents, ou même tous les éléments, pourraient être implémentés dans la même boîte Ou, les différentes unités fonctionnelles peuvent être scindées et réparties dans le système  Dans ce cas, des mécanismes de coordination doivent être mis en œuvre N’importe, à condition que les résultats restent les mêmes que pour le modèle idéal Le modèle décrit dans la norme n’est qu’un modèle convenable pour expliquer la norme  Pourrait n’avoir aucune relation avec une implantation INF6153 65

Encore à faire

 XACML est plus récent que RBAC et est moins bien établi  Il manque aussi de la théorie et outils qui sont bien établis pour RBAC INF6153 66

Utilisation conjointe de RBAC et ABAC

 Des organisations qui utilisent déjà RBAC peuvent aussi utiliser ABAC pour des règles basées sur les attributs  Normalement après RBAC car ABAC est plus ‘fin’ Requête

RBAC ABAC

Accept Refus Refus INF6153 67

Ergonomie et interfaces

 Clairement, le langage XACML ne peut pas être traité directement  Il a besoin d’éditeurs et interfaces qui permettent à l’usager   de formuler les politiques et les requêtes de manière lisible et de recevoir les réponses de manière lisible  Traducteurs entre domain-specific inputs et XACML  Ces éditeurs et interfaces ne font pas partie de la norme, donc il y en aura toute une variété   Produits par différents boîtes de logiciels ou chercheurs

http://www.site.uottawa.ca/~bernard/access_control.html

INF6153 68

Adoption industrielle

 Cherchez les mots clés ABAC et XACML dans le www, vous y trouverez toutes sortes d’histoires, expériences pratiques et discussions …  Quelques compagnies ont beaucoup investi dans XACML    Au début c’était surtout la compagnie SUN Microsystems Après l’achat de SUN par Oracle, c’est Oracle qui a continué le développement Le comité XACML inclut aussi un bon nombre de compagnie bien connues INF6153 69

Sources - Remerciements

     La première partie sur ABAC vient de LNIST Special Publication 800-162. Guide to Attribute Based Access Control, Definitions and Considerations, Final –Draft, Sept. 2013   La plupart des exemples montrés viennent du site OASIS d’XACML, contenant la norme et un bref tutoriel sur XACML:

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml https://www.oasis-open.org/committees/download.php/2713/Brief_Introduction_to_XACML.html

Audumbar Chormale: Tutorial on XACML, présentation .ppt dans le site de l’UMBC: University of Maryland Baltimore Country. Beaucoup d’informations dispo dans www sur ABAC et XACML, en français aussi  Cependant faites attention à quelle version de XACML elles se réfèrent!

 La version 3 est très récente: 2013  Faire une recherche sur: « XACML 3.0 Gerry Gebel » pour des informations sur les développements en XACML Remerciements à Bernard Stépien qui m’a aidé pour ces diapositives INF6153 70

La première délégation dans la Bible (livre de l’Exode)

           18.14 Le beau-père de Moïse vit tout ce qu'il faisait pour le peuple, et il dit: Que fais-tu là avec ce peuple? Pourquoi sièges-tu seul, et tout le peuple se tient-il devant toi, depuis le matin jusqu'au soir?

18.15 Moïse répondit à son beau-père: C'est que le peuple vient à moi pour consulter Dieu.

18.16 Quand ils ont quelque affaire, ils viennent à moi; je prononce entre eux, et je fais connaître les ordonnances de Dieu et ses lois.

18.17 Le beau-père de Moïse lui dit: Ce que tu fais n'est pas bien.

18.18 Tu t'épuiseras toi-même, et tu épuiseras ce peuple qui est avec toi; car la chose est au-dessus de tes forces, tu ne pourras pas y suffire seul.

18.19 Maintenant écoute ma voix; je vais te donner un conseil, et que Dieu soit avec toi! Sois l'interprète du peuple auprès de Dieu, et porte les affaires devant Dieu.

18.20 Enseigne-leur les ordonnances et les lois; et fais-leur connaître le chemin qu'ils doivent suivre, et ce qu'ils doivent faire.

18.21 Choisis parmi tout le peuple des hommes capables, craignant Dieu, des hommes intègres, ennemis de la cupidité; établis-les sur eux comme chefs de mille, chefs de cent, chefs de cinquante et chefs de dix.

18.22 Qu'ils jugent le peuple en tout temps; qu'ils portent devant toi toutes les affaires importantes, et qu'ils prononcent eux-mêmes sur les petites causes. Allège ta charge, et qu'ils la portent avec toi.

18.23 Si tu fais cela, et que Dieu te donne des ordres, tu pourras y suffire, et tout ce peuple parviendra heureusement à sa destination.

18.24 Moïse écouta la voix de son beau-père, et fit tout ce qu'il avait dit.

INF6153 71