ABAC et XACML Attribute Based Access Control e

ABAC et XACML Attribute Based Access Control e. Xtensible Access Control Markup Language INF 6153 http: //w 3. uqo. ca/luigi/INF 6153/index. html 1

ABAC et XACML l ABAC = Attribute Based Access Control l XACML = e. Xtensible Access Control Markup Language l ABAC est un modèle de contrôle d’accès l XACML est un langage standardisé utilisant le modèle ABAC INF 6153 2

Idées fondamentales de ABAC-XACML l Toute entité peut avoir des ‘attributs’ l On peut définir des ‘politiques’ de contrôle d’accès basées sur ces attributs l Permit et Deny l Langage XACML de descriptions de politiques l Modèle architectural INF 6153 3

ABAC: Attribute Based Access Control INF 6153 Les matériaux de cette partie, surtout les figures, proviennent de NIST Special Publication 800 -162 Guide to Attribute Based Access Control (ABAC) Definition and Considerations 4

Catégories et attributs l L’intention de ABAC est d’être plus général et flexible que toutes les méthodes précédentes l Dans ABAC, on prend les décisions sur la base de: l Attributs de Catégories l Une catégorie est un identificateur d’une entité qui peut avoir des attributs l Le choix des catégories dépend des caractéristiques du système l Pour nos exemples, nous supposerons l’utilisation des trois catégories : l Sujet, Ressource, Action l Cependant ABAC est très générique et peut être utilisé avec des catégories complètement différentes INF 6153 5

Attribute Based Access Control l Sujet Ressource et Action sont des catégories qui regroupent des attributs l P. ex. l l l attributs du Sujet pourraient être: Nom, Département, Rôle, Bureau etc … attributs de l’Action: Identification, Type Les attributs ont des valeurs, p. ex. : l l l Nom(Sujet)=Gervais, Département(Sujet)= DII, Role(Sujet)=Professeur, Bureau(Sujet)=B 1005, Identif(Action)=Emprunt. Livre, Type(Action)=Bibliotheque, Type(Ressource)=Reserve, Ident (Ressource)= QA. 75. 5. 2005, l La requête de contrôle d’accès est un ensemble d’éléments (attribut(catégorie)=valeur) – les paramètres de la requête l P. ex. Nom(Sujet)=Gervais et Identif(Action)=Emprunt. Livre et Identif(Ressource)=QA. 75. 5. 2005 l Les règles de contrôle d’accès sont basées sur des cibles exprimées par des expressions booléennes INF 6153 6

Exemples typiques de règles ABAC l Essentiellement, expressions booléennes comme: Permettre si (Role(Sujet)=Professeur ou Role(Sujet)=Personnel) et Identif(Action)=Emprunt. Livre et Type(Ressource)=Pas. Réserve) l Défendre si (Role(Sujet)=Étudiant et Identif(Action)=Emprunt. Livre et (Type(Ressource)=Revue ou Type(Ressource)=Reserve)) l Permettre si ((Inscrit(Sujet)=UQO et Role. UQO(Sujet)=Étudiant) ou Employeur(Sujet)=UQO) et INF 6153 Amendes. Payées(Sujet)=vrai l 7

Point intéressant, Independence des sujets l 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 d’usagers ou sujets: l l « aucun ne peut lire des fichiers réservés en dehors des heures de travail » « tous peuvent avoir accès aux politiques de l’organisation » INF 6153 8

Règles et politiques l Nous avons vu deux exemples de règles l Permettre, Défendre l Les politiques sont des ensembles de règles l Normalement les règles dans une politique sont reliées par une idée commune l P. ex. on pourrait avoir des politiques: v accès à la bibliothèque Brault § v v qui réunit toutes les règles qui déterminent l’accès à cette bibliothèque accès aux dossiers de comptabilité … INF 6153 9

Architecture ABAC l ABAC définit un modèle architecturel très intéressant qu’on pourrait appliquer à autres modèles, p. ex. RBAC INF 6153 10

Exemple intuitif l Une université a un gardien qui peut laisser entrer ou non des personnes l Policy Enforcement Point (PEP) l Quand une personne arrive, le gardien doit demander l’autorisation à la personne qui connaît les règles d’accès l Policy Decision Point (PDP) l Pour décider, le PDP demande des informations concernant la requête à des personnes informées l Policy Information Point (PIP) INF 6153 11

Le PDP comme moteur d’inférence l Si le PEP informe le PDP que: l (Jamel) demande (d’entrer) (à la bibliothèque) à (22 h), l Le PDP détermine que la règle applicable pourrait être: l Refuser (aux étudiants) (l’accès) (aux locaux de l’université) (après 20 h) l Mais il ne sait pas que Jamel est un étudiant, qu’il est après 20 h etc l Le PDP interroge le PIP, le PIP informe le PDP que, sur la base des attributs l l Jamel est un étudiant à temps partiel est un étudiant entrer est un accès la bibliothèque est un local de l’université l Le PIP informe aussi le PDP que, sur la base de l’état de l’environnement l nous sommes à 22 h>20 h. INF 6153 l Le PDP conclut que la demande d’accès doit être niée 12

Éléments architecturels de ABAC l PEP: Policy Enforcement Point: l Donne ou refuse un accès l PDP: Policy Decision Point: l l 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 l PAP: Policy Administration Point l Gère le Policy Store: ajout, enlèvement de politique l PIP: Policy Information Point - fournit les informations dont le PDP a besoin pour prendre ses décisions l l l Les modèle d’attributs et les ontologies, v. après L’état de l’environnement: L’environnement peut aussi être une catégorie avec ses attributs l l l P. ex. l’heure Localisation de l’usager ou de la ressource Etc. INF 6153 13

ABAC Schéma architecturel DP: Digital Policy INF 6153 Source: NIST Special Publication 800162 14

Implémentation l Différentes implémentations sont possibles l l Le PEP est associé à l’objet et les PDP-PIP sont à distance On peut avoir plusieurs PEPs pour différents objets Mais aussi, on peut avoir dans le PEP des politiques déjà actualisées sans avoir besoin d’accès continu au PDP Et aussi, toute l’implémentation peut être dans un seul programme INF 6153 15

Modèle d’attributs – dans le PIP l Un système ABAC doit être basé sur un modèle qui connaît tous les catégories et attributs qui peuvent être utilisés, dans des requêtes ou dans des règles l Dans le modèle, les valeurs peuvent être organisés en ontologies, p. ex. on peut savoir l l l 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: l à temps plein, à temps partiel, de 1 er cycle, de 2ème cycle etc. l Les hiérarchies de rôles, s’il y en a, sont donc stockées dans cette base de concepts l S’il est désiré d’implémenter MAC, la base de concepts inclura aussi les niveaux d’autorisation l Etc. INF 6153 16

Ontologies – dans le PIP l Une ontologie est un ensemble de concepts reliés par des relations l Un ensemble de connaissances formalisé est une ontologie l P. ex. le système métrique l Une structure organisationnelle, une hiérarchie de rôles est aussi une ontologie l Les ontologies sont importantes dans le cas d’entités qui doivent partager un ensemble de connaissances l Elles établissent les concepts sur lesquels les entités doivent être d’accord, concepts qui rendent la communication possible l P. ex. dans le cas du commerce électronique Un catalogue est une ontologie qui établit un ensemble de connaissances communes entre vendeur et acheteurs l Si vous voulez acheter un lecteur DVD sur Amazon, Amazon et vous INF 6153 devez partager la même vision de que c’est qu’un lecteur de DVD, les 17 différents types existants etc. l

Cohérence globale l 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 l p. ex. dans l’exemple précédent, le PDP, PIP et PAP doivent avoir la même compréhension de: l l l « Jamel » « étudiant » « bibliothèque » « local de l’Université » « 22 h » v Réfléchissez sur cet exemple et déterminer 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 § INF 6153 Ceci n’est pas facile à planifier et doit être cohérent avec la politique de l’organisation 18

+ et + D’un côté ABAC permet de représenter les politiques d’une organisation avec des critères beaucoup plus complexes et détaillés que MAC ou RBAC on peut utiliser un nombre illimité de catégories et 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 INF 6153 19 MAC ou RBAC

Cohérence des règles l Dans les systèmes où il y a des règles positives et négatives, on peut avoir des incohérences! l l Les docteurs peuvent lire seulement les dossiers de leur patients Dans une situation d’urgence, un docteur peut lire les dossiers de n’importe quel patient l Évidemment la 2ème règle est une exception à la 1ère, mais dans une situation d’urgence la 1ère règle peut empêcher l’utilisation de la 2ème INF 6153 20

Meta-règles de résolution de conflits l Si le PDP détecte des règles qui conduisent à des décisions opposés, il fait référence à des métarègles normalement fournies par l’auteur des politiques l Métarègles: règles pour déterminer l’exécution de règles l 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 l Permit overrides: s’il y a une règle qui permet l’accès, elle est appliquée malgré autres règles qui pourraient INF 6153 l’empêcher l 21

Domaine d’application des meta-règles l Les meta-règles ont un domaine d’application l P. ex. on peut dire que la meta-règle ‘deny overrides’ s’applique de manière générale pour toutes les politiques d’un hôpital l Mais dans l’ensemble de politiques ‘Urgences’ la règle qui s’applique est ‘permit overrides’ l V. exemple précédent INF 6153 22

Obligations l Les obligations spécifient des actions à exécuter après un ‘effet’ de permission ou non l P. ex. ‘Si une permission est octroyée dans le cadre de politiques d’urgence, alors un message est envoyé à l’administrateur du système pour l’avertir’ l Ce concept a plusieurs autres applications l C’est le PEP qui est responsable de contrôler leur exécution INF 6153 23

Collaboration entre organisations l Plusieurs organisations partagent une base de données l Chacune a des critères d’accès basés sur les informations qui l’intéressent l Exemple: l Citoyenneté Canada et Revenu Canada utilisent la même base de données, mais chacune selon ses propres critères: l l l 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 PEP 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 INF 6153 24

Différentes organisations concevables l Les organisations utilisent les mêmes politiques, mais diffèrent pour leur interprétation l P. ex. les deux organisations permettent l’accès aux ‘mineurs’ mais ont une interprétation différente qu’est ce qu’un ‘mineur’ l Les deux organisations utilisent donc les mêmes PEP-PDP et possiblement le même PIP, mais différents attribute stores INF 6153 25

Utilisation de ABAC pour plusieurs organisations INF 6153 Cas de différents Attribute Stores Source: NIST Special Publication 800 -162 26

Autres variations possibles l On pourrait penser aussi à des cas où les politiques sont vraiment différentes etc. l Donc, différents Policy Stores, différents PDPs? l Laissons tout ceci à la recherche INF 6153 27

« Trust Chain » ou Chaîne de confiance l 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 l S’il y a une faille, on cherche le responsable en parcourant cette chaîne l 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 INF 6153 28

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 ainsi que sur les mécanismes d’authentification et accès Source: NIST Special Publication 800 -162 INF 6153 29

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. Source: NIST Special Publication 800 -162 INF 6153 30

Contrôle de flux en ABAC l La logique de contrôle de flux que nous avons utilisée jusqu’à présent a été basée sur la connaissance des possibilités de lectures et écriture l En ABAC cette logique est encore valable, mais les possibilités de lectures-écritures peuvent dépendre de conditions booléennes complexes l Donc contrôler la validité d’un modèle ABAC est beaucoup plus complexe que contrôler un modèle RBAC INF 6153 31

Exemple A X=Y B V=W C Les données peuvent passer de A à B ssi X=Y de B à C ssi V=W de A à C ssi X=Y et V=W INF 6153 32

XACML: Extensible Access Control Markup Language Presque tous les dessins et codes suivants proviennent de: http: //docs. oasis-open. org/xacml/3. 0/xacml-3. 0 -core-spec-osen. html INF 6153 33

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

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

Architecture XACML (essentiellement, la même que pour ABAC) INF 6153 36

XACML Architecture INF 6153 37

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 INF 6153 38

PAP: Policy Administration Point Entretien de la base de données des politiques INF 6153 39

PDP: Policy Decision Point • Contient la base de données des politiques • Traite les requêtes d’accès • Recherche et évalue les politiques et règles pertinentes • Retourne la décision au PEP INF 6153 40

PIP: Policy Information Point Contient et distribue les informations nécessaires pour l’évaluation des règles. INF 6153 41

Resource content 9. Optionally, the context handler includes the resource in the context. In many applications, it is required to base an authorization decision on data contained in the information resource to which access is requested. For instance, a common component of privacy policy is that a person should be allowed to read records for which he or she is the subject. The corresponding policy must contain a reference to the subject identified in the information resource itself. INF 6153 42

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) INF 6153 43

Contexts Le ‘contexte’ XACML isole le PDP tandis que les entrées et sorties pourraient utiliser des langages différents INF 6153 44

Dans l’ensemble … Conversion de format XA INF 6153 45

Tel que décrit dans la norme OASIS 1. 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. 2. The access requester sends a request for access to the PEP. 3. 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. 4. The context handler constructs an XACML request context, optionally adds attributes, and sends it to the PDP. 5. The PDP requests any additional subject, resource, action, environment and other categories (not shown) attributes from the context handler. 6. The context handler requests the attributes from a PIP. 7. The PIP obtains the requested attributes. 8. The PIP returns the requested attributes to the context handler. 9. Optionally, the context handler includes the resource in the context. 10. The context handler sends the requested attributes and (optionally) the resource to the PDP. The PDP evaluates the policy. 11. The PDP returns the response context (including the authorization decision) to the context handler. 12. The context handler translates the response context to the native response format of the PEP. The context handler returns the response to the PEP. 13. The PEP fulfills the obligations. 14. (Not shown) If access is permitted, then the PEP permits access to the resource; otherwise, it denies access. INF 6153 46

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

Langage XACML INF 6153 48

Exemples du langage XACML l XACML est un langage complexe avec beaucoup d’options, voici une idée générale l Cette discussion est basée sur la version 3. 0 du langage (2013) l Tandis que beaucoup de documentation que vous pourriez trouver est basée sur la version 2 INF 6153 49

Requête initiale Name(subject-id (subject)) = bs@simpsons. com AND URI(resource-id(resource)) = file: //example/med/record/patient/Bart. Simpson AND String(action-id(action)) = read INF 6153 Bart Simpson, with e-mail name "bs@simpsons. com", wants to read his medical record at Medi Corp. 50

Requête (source: norme OASIS) Bart Simpson, with e-mail name "bs@simpsons. com", wants to read his medical <? xml version="1. 0" encoding="UTF-8"? > record at Medi Corp. <Request xmlns="urn: oasis: names: tc: xacml: 3. 0: core: schema: wd-17" xmlns: xsi="http: //www. w 3. org/2001/XMLSchema-instance" xsi: schema. Location="urn: oasis: names: tc: xacml: 3. 0: core: schema: wd-17 http: //docs. oasis-open. org/xacml/3. 0/xacml-core-v 3 -schema-wd-17. xsd" Return. Policy. Id. List="false"> <Attributes Category="urn: oasis: names: tc: xacml: 1. 0: subject-category: access-subject"> <Attribute Include. In. Result="false" Attribute. Id="urn: oasis: names: tc: xacml: 1. 0: subject-id"> <Attribute. Value Data. Type="urn: oasis: names: tc: xacml: 1. 0: data-type: rfc 822 Name" >bs@simpsons. com</Attribute. Value> </Attribute> </Attributes> <Attributes Category="urn: oasis: names: tc: xacml: 3. 0: attribute-category: resource"> <Attribute Include. In. Result="false" Attribute. Id="urn: oasis: names: tc: xacml: 1. 0: resource-id"> <Attribute. Value Data. Type="http: //www. w 3. org/2001/XMLSchema#any. URI" Attributs du sujet Attributs de la ressource >file: //example/med/record/patient/Bart. Simpson </Attribute. Value> </Attribute> </Attributes> <Attributes Category="urn: oasis: names: tc: xacml: 3. 0: attribute-category: action"> <Attribute Include. In. Result="false" Attribute. Id="urn: oasis: names: tc: xacml: 1. 0: action-id"> <Attribute. Value Data. Type="http: //www. w 3. org/2001/XMLSchema#string" >read</Attribute. Value> </Attribute> </Attributes> </Request> INF 6153 Attributs de l’action 51

Concept de catégorie et d’attributs l Les catégories peuvent avoir attributs l Dans XACML 2, il n’y avait que les catégories usuelles: l Sujet, Action, Ressource, Environnement l Dans XACML 3, on peut définir des nouvelles catégorie avec leurs propres attributs, ce qui augmente la flexibilité du langage l P. ex. Service l Ceci permet d’ajouter des conditions relatives aux nouvelles catégories: Nom(Sujet)=X et … et Ident(Service)=Réservation. Hotel INF 6153 l 52

Structure des requêtes l Essentiellement, une requête est une conjonction d’attributs de différentes catégories l Nous verrons que cette conjonction est mise en correspondance avec les cibles (targets) des règles l (match ou no-match) INF 6153 53

Policy Language Model (source: norme OASIS) INF 6153 54

Structure de Politiques et règles INF 6153 55

Cibles ou Targets l Les ensembles de politiques, politiques et règles contiennent des cibles qui identifient les cas où ils sont applicables l Conçues pour recherche rapide l Les cibles sont exprimées en termes de: l Conjonctions de disjonctions de conjonctions INF 6153 56

Cibles: structure: conjonction de disjonctions de conjonctions qui doivent obligatoirement être emboîtées de cette manière INF 6153 Schéma de Stepien, Felty, Matwin 57

Une cible en structure simplifiée Doctor read or write med records l Any of l All of l l l /All of l l Read Write /All of l /Any of l All of l l l Read ou write Pour tous les docteurs et medical records Doctor Medical Record /All of l /Any of INF 6153 58

Comme arbre All. Of Implicit Any. Of All. Of (Name(action)=read OR name(action)=write) AND Role(subject)=doctor AND Type(resource)=med_rec INF 6153 59

Target-Cible: doctors, read or write med records <xacml 3: Target> <xacml 3: Any. Of> <xacml 3: All. Of> <xacml 3: Match. Id="urn: oasis: names: tc: xacml: 1. 0: function: string-equal"> <xacml 3: Attribute. Value Data. Type="http: //www. w 3. org/2001/XMLSchema#string"> read</xacml 3: Attribute. Value> <xacml 3: Attribute. Designator Attribute. Id="urn: oasis: names: tc: xacml: 1. 0: action-id" Category="urn: oasis: names: tc: xacml: 3. 0: attribute-category: action" Data. Type="http: //www. w 3. org/2001/XMLSchema#string" Must. Be. Present="false"/> </xacml 3: Match> </xacml 3: All. Of> <xacml 3: All. Of> <xacml 3: Match. Id="urn: oasis: names: tc: xacml: 1. 0: function: string-equal"> <xacml 3: Attribute. Value Data. Type="http: //www. w 3. org/2001/XMLSchema#string"> write</xacml 3: Attribute. Value> <xacml 3: Attribute. Designator Attribute. Id="urn: oasis: names: tc: xacml: 1. 0: action-id" Category="urn: oasis: names: tc: xacml: 3. 0: attribute-category: action" Data. Type="http: //www. w 3. org/2001/XMLSchema#string" Must. Be. Present="false"/> </xacml 3: Match> </xacml 3: All. Of> </xacml 3: Any. Of> <xacml 3: Any. Of> <xacml 3: All. Of> <xacml 3: Match. Id="urn: oasis: names: tc: xacml: 1. 0: function: string-equal"> <xacml 3: Attribute. Value Data. Type="http: //www. w 3. org/2001/XMLSchema#string"> doctor</xacml 3: Attribute. Value> <xacml 3: Attribute. Designator Attribute. Id="role" Category="urn: oasis: names: tc: xacml: 1. 0: subject-category: access-subject" Data. Type="http: //www. w 3. org/2001/XMLSchema#string" Must. Be. Present="false"/> </xacml 3: Match> <xacml 3: Match. Id="urn: oasis: names: tc: xacml: 1. 0: function: string-equal"> <xacml 3: Attribute. Value Data. Type="http: //www. w 3. org/2001/XMLSchema#string"> medical record</xacml 3: Attribute. Value> <xacml 3: Attribute. Designator Attribute. Id="resource-type" Category="urn: oasis: names: tc: xacml: 3. 0: attribute-category: resource" Data. Type="http: //www. w 3. org/2001/XMLSchema#string" Must. Be. Present="false"/> </xacml 3: Match> </xacml 3: All. Of> </xacml 3: Any. Of> </xacml 3: Target> INF 6153 60

Cible dans les politiques et règles l Expression qui détermine les conditions essentielles pour l’application de la politique ou règle l Les cibles contiennent des Any. Of qui contiennent des And. Of – sans emboîtement ultérieur (v. diagr. UML) l Il y a une conjonction implicite au 1 er niveau l Exemple précédent en logique: l (Name(action)=read OR name(action)=write) AND Role(subject)=doctor AND Type(resource)=med_rec l Quand une requête arrive, le PDP cherche les INF 6153 61 policy sets, politique et règle qui correspondent à

Règles l Une règle XACML contient l l Cible(Target): condition and-or-and 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 Condition (optionnelle): condition booléenne qui peut être ajoutée pour spécifier des conditions plus complexes (p. ex. avec négation) l Il y a une syntaxe XACML pour ça l Effet: la décision: permit, deny (pas présent dans l’exemple précédent) l Obligations: choses à faire par le PEP après l’évaluation de la règle l l P. ex. : noter la décision prise dans un journal; mettre à jour des stats; informer l’administrateur, envoyer un courriel au sujet …. … 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 INF 6153 l Avis: comme les obligations mais peuvent être ignorées par le 62

Politiques, Ensembles de politiques l Les Policies et Policy sets contiennent: l l l Cible Algorithmes de combinaison de règles Obligations Advices Quelques autres choses reliées l Les Policies contiennent les règles INF 6153 63

Ensembles de cibles pour une politique: structure INF 6153 Schéma de Stepien, Felty, Matwin 64

Match entre requête et règle: un docteur demande de lire un dossier médical La requête Name(subject-id (subject)) = bs@simpsons. com Cible de la règle l Any of l l URI(resource-id(resource)) = file: //example/med/record/patient/Bart Simpson All of /All of l l Name(action)=write /All of l /Any of l All of l String(action-id(action)) = read Name(action)=read l l Role(subject)=doctor Type(resource)=med_rec /All of À l’aide de l’information obtenues l /Any of du PIP, le PDP décide que la politique de droite est applicable à la requête de gauche INF 6153 Transformation effectuée utilisant les infos du PIP 65

Effects l Le résultat (ou effet) de l’évaluation d’une requête XACML par rapport à une politique peut être l’un de: l l l Accept Deny Indeterminate l Il y a une erreur dans l’évaluation d’une règle v Cas prévus explicitement dans les méthodes d’évaluation des règles § l P. ex. la règle n’est pas écrite correctement, des éléments manquent, etc. Not. Applicable l Pas de règle applicable INF 6153 66

l Supposons qu’un ensemble de politiques contienne une seule règle: l Les abonnés à IEEE peuvent obtenir les articles dans IEEE Xplore l Supposons une requête comme suit: l Je suis abonné à ACM et je demande un article dans IEEE Xplore INF 6153 67

Not. Applicable l Supposons qu’un ensemble de politiques contienne une seule règle: l Les abonnés à IEEE peuvent obtenir les articles dans IEEE Xplore l Supposons une requête comme suit: l Je suis abonné à ACM et je demande un article dans IEEE Xplore l Effet: Not. Applicable l Car aucune règle ne correspond: No Match l On a le même effet si la règle ne correspond pas pour des conditions booléennes, supposons que la seule règle soit: l Les abonnés à IEEE qui ne sont pas étudiants peuvent obtenir les articles l Soit la requête suivante: l Conditions booléennes Je suis abonné à IEEE, je suis étudiant et je demande un article l Ou: Je suis abonné à IEEE et je demande un article l Effet: Not. Applicable l Donc XACML motive à être très complet dans la spécification des règles et requêtes l Il ne donne Deny que si explicitement spécifié INF 6153 68

Effet final l Normalement Not. Applicable ou Indeterminate deviennent des Deny mais ils peuvent être captés par des: l l Algorithmes de combinaison Obligations l D’envoyer des informations à l’usager ou à l’administrateur qui pourraient s’en servir pour changer leur requêtes ou leur politiques INF 6153 69

Exemple de politique définissable en XACML l A person may read any record for which he or she is the designated patient. l 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. l 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. l An administrator shall not be permitted to read or write to medical elements of a patient record. INF 6153 70

Politique pour la lecture-écriture des documents des patients l Permit: Role(subject)=patient AND Name(file)= patient AND Name(action)=read; l l Permit: (Role(subject)=parent OR Role(subject)=guardian) AND Age(patient) < 16 AND Name(action)=read; l l Le patient peut lire ses documents Les parents ou gardiens peuvent lire les documents des mineurs Permit: Role(subject)=primary_physician AND Name(action)=write; Obligation: send notification l l Les docteurs peuvent écrire sur les documents de leur patients, mais une notif doit être envoyée Deny: Role(subject)=administrator AND (Name(action)=read OR Name(action=write)); l Les administrateurs ne peuvent ni lire ni écrire sur les documents des patients 71 INF 6153

Précisions ultérieures l Quelques détails sont omis, p. ex. il faudrait préciser l l l Dans la 1ère règle, que le patient ne peut effectivement lire que du fichier dont il est propriétaire etc. Exercice: trouver toutes les conditions nécessaires INF 6153 72

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

Comparaison RBAC l Même si ceci est évident, réfléchissez un instant pour voir qu’aucune des politiques précédentes n’est spécifiable en RBAC INF 6153 74

Algorithmes de combinaison INF 6153 75

Politiques et algorithmes de combinaison l Nous avons vu que, dans une politique ou ensemble de politiques, il pourrait y avoir plusieurs effets pour une requête donnée l Différentes règles pourraient donner des effets différents l Les algorithmes de combinaison sont associés aux politiques (et ensembles de politiques) pour déterminer l’effet final dans ces cas l C’est le concepteur des politiques qui détermine l’algorithme de combinaison à utiliser dans chaque politique (ou ensemble de politiques) INF 6153 76

Pourquoi plusieurs effets l Le PIP pourrait retourner plusieurs valeurs pour certains attributs l Alice pourrait être programmeur, aussi représentante syndicale, etc. l On pourrait avoir des règles et des exceptions l l Seulement le médecin d’un patient peut lire le dossier du patient Dans un cas d’urgence, une infirmière peut aussi l On pourrait avoir des combinaisons de règles de différentes domaines d’applicabilité l Règles pour toute la division, règles pour un bureau particulier INF 6153 l On pourrait évidemment avoir des erreurs dans 77

Algorithmes de combinaison l Chaque règle dans une politique doit avoir comme effet un des suivants: l Permit, Deny, Indeterminate, Not. Applicable l Pour résoudre les cas où plusieurs effets sont retournés par des règles différentes, les algorithmes suivants sont prédéfinis: l l l l Deny overrides Permit overrides Deny unless permit Permit unless deny First applicable Only one applicable Etc. l l Aussi, l’usager peut définir ses propres algorithmes Cette flexibilité permet à XCML d’être appliqué au-delà du domaine de la sécurité l P. ex. pour définir des politiques de ‘renvoi’ ou ‘forwarding’ INF 6153 78

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

Exemple: deny overrides l If any decision is "Deny", the result is "Deny". l Otherwise, if any decision is "Indeterminate{DP}", the result is "Indeterminate{DP}". l Otherwise, if any decision is "Indeterminate{D}" and another decision is “Indeterminate{P} or Permit, the result is "Indeterminate{DP}". l Otherwise, if any decision is "Indeterminate{D}", the result is "Indeterminate{D}". l Otherwise, if any decision is "Permit", the result is "Permit". l Otherwise, if any decision is "Indeterminate{P}", the result is "Indeterminate{P}". l Otherwise, the result is "Not. Applicable". INF 6153 80

Exemple: only one applicable l 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. l If more than one policy is considered applicable by virtue of its target, then the result of the policycombination algorithm is "Indeterminate". l If no policy is considered applicable by virtue of its target, then the result of the policy-combination algorithm is "Not. Applicable". l 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}. INF 6153 81

Algorithmes de combinaison de règles et de politiques l Les algorithmes de combinaison peuvent être appliqués l l Entre règles Entre politiques l Ils peuvent donc exister aux deux niveaux INF 6153 82

Effet final l Si l’effet final est un ‘indeterminate’ ou ‘not applicable’, le PEP nie l’accès l Cependant comme effet d’une ‘obligation’ ce type de décision peut être enregistré dans un journal et peut être transmise à l’administrateur ou à l’usager, l Avec des informations contenant des détails comme spécifié dans les politiques l L’administrateur aura des informations pour changer les règles l Il pourrait découvrir que les règles sont contradictoires ou incomplètes l. INF 6153 L’usager aura des informations pour changer sa 83

Obligations et avis l Un effet peut impliquer des Obligations ou des Avis, qui sont des actions à exécuter par le PEP après la réponse l Si l’effet est résultat de plusieurs règles qui donnent le même effet, alors toutes les obligations ou avis spécifiés par chacune de ces règles sont applicables l Leur applicabilité peut être assujettie à des expressions conditionnelles l Les Obligations doivent être exécutées par le PEP, les Avis peuvent être ignorés l Exemples: Alice n’a pas réussi à accéder à un certain objet: son patron doit être averti l Envoyer un msg d’explications à Alice l Faire un enregistrement dans un fichier de journal INF 6153 l Etc. 84 l

Séparation de tâches l 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. Id="contractor: AND: employee: disallowed" La séparation de tâches dynamique est laissée comme exercice, mais voir: http: //docs. oasis-open. org/xacml/cd-xacml-rbac. INF 6153 profile-01. pdf 85

Discretionary Access Control dans XACML l Un des attributs d’une ressource pourrait être: propriétaire l Propriétaire(Fichier 1) = Alice l Il est alors possible d’écrire des règles qui s’appliquent au propriétaire l Pex. Le propriétaire d’un fichier peut le lire l Alice peut modifier ces règles si elle a rôle administrateur l Comme dans DAC elle peut s’attribuer ou nier certains privilèges Ou peut octroyer des privilèges à autres l INF 6153 86

Délégation l La délégation permet à un sujet de déléguer ses permissions, en tout ou en partie, à un autre sujet l normalement pour un temps déterminé et avec conditions l Les droits de délégation sont séparés des droits d’accès l l Ils sont considérés comme des politiques administratives donc les politiques d’accès ne changent pas l On peut avoir plusieurs niveaux de délégation l Au moment d’une requête, le PDP doit contrôler toute la chaîne de délégations jusqu’à la permission originale INF 6153 87

Exemple de délégation (https: //en. wikipedia. org/wiki/XACML, 2016/03/23) l Access control rule: l Allow access to resource with attribute Web. Service if subject is employee and action is read or write l Administration rule: l l Allow delegation of access control rule above to subject with attribute consultant Conditions l l Delegation must expire within 6 months Resource must not have attribute Strictly. Internal Delegatee cannot delegate again l INF 6153 88

Autre exemple en UML (Use Case Diagram) Alice, la propriétaire de la ressource délègue l’admin de la ressource à Bob Source: Gerry Gebel, XACML 3. 0 Enhancements INF 6153 89

Puissance de XACML-ABAC l Il peut être utilisé pour MAC car les niveaux de sécurité peuvent être des attributs des usagers et objets l Cependant XACML manque la capacité d’empêcher des exceptions à MAC, donc il n’est pas vraiment ‘mandatory’ l Il peut être utilisé pour DAC avec son modèle d’administration et propriété l v. discussion sur la délégation l Il peut être utilisé pour RBAC car le rôle est un attribut du sujet l l 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: l Quels sont les permissions d’un sujet spécifique, d’un rôle spécifique? l XACML a aussi des profils pour la protection de la propriété intellectuelle: l Copyright, Brévet etc. l L’implémentation de XACML est plus complexe que l’implémentation INF 6153 de RBAC 90

Exercice l Déterminer que XACML est en fait capable de représenter RBAC 0, 1, 2, et 3 l Il y a des articles sur ceci dans la litérature … l http: //docs. oasis-open. org/xacml/cd-xacml-rbacprofile-01. pdf v Cette proposition pourrait être trop compliquée INF 6153 91

Optimisation l En pratique, plusieurs raccourcis ou raffinements peuvent être utilisés pour améliorer la performance du système, ou l’adapter l Exemples: l l 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 composante v l Ou, les différentes unités fonctionnelles peuvent être scindées et réparties dans le système v l l Logiciel, ordinateur, nœud du réseau 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 l Pourrait n’avoir aucune relation avec une implantation INF 6153 92

Encore à faire l XACML est plus récent que RBAC et est moins bien établi l Il manque aussi de la théorie et outils qui sont bien établis pour RBAC INF 6153 93

Utilisation conjointe de RBAC et ABAC l Des organisations qui utilisent déjà RBAC peuvent aussi utiliser ABAC pour des règles basées sur les attributs l Normalement après RBAC car ABAC est plus ‘fin’ Requêt e INF 6153 RBAC ABAC Refus Accept 94

Article intéressant l D. R. Kuhn, E. J. Coyne, T. R. Weil: Adding attributes to Role-based access control. IEEE Computer, vol. 43, no. 6 (June, 2010) , pp. 79 -81 INF 6153 95

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

Adoption industrielle l Cherchez les mots clés ABAC et XACML dans le www, vous y trouverez toutes sortes d’histoires, expériences pratiques et discussions … l Quelques compagnies ont beaucoup investi dans XACML l l l 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 d’autres compagnies bien connues l Cependant l’impression est que l’application INF 6153 pratique est souvent limité aux fonctionnalités les 97

Considération finales sur ABAC-XACML l Très flexible, donne énormément de possibilités l Peut simuler et augmenter RBAC, et avec quelques artifices, MAC, DAC, bien d’autres l Modèle architecturel clair et utile bien au-delà de ABAC l Bien que les fonctionnalités des différentes composantes ne soient pas bien définie l Langage XACML et outils reliés l RBAC n’a pas un tel langage l Peut être utilisé au delà de la sécurité l P. ex. pour exprimer politiques de routage, de sélection, etc. l Sa puissance peut être difficile à maîtriser On peut facilement abuser de ce modèle et langage tellement complexes l Dans la sécurité, on a besoin de méthodes claires, avec des réponses sûres, l On pourrait vouloir plus la rigidité que la flexibilité INF 6153 98 l

Sources - Remerciements l 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 l 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 l Audumbar Chormale: Tutorial on XACML, présentation. ppt dans le site de l’UMBC: University of Maryland Baltimore Country. l 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! l l La version 3 date du: 2013 Faire une recherche sur: « XACML 3. 0 Gerry Gebel » pour des informations sur les développements en XACML l Remerciements particuliers à Bernard Stépien qui m’a aidé dans l’apprentissage de XACML l l Ses articles sur XACML que j’ai utilisés sont dans sa page web: l http: //www. site. uottawa. ca/~bernard/ INF 6153 99

La première délégation dans la Bible (livre de l’Exode) l 18. 14 Le beau-père de Moïse vit tout ce qu'il faisait pour le peuple, et il dit: Que faistu là avec ce peuple? Pourquoi sièges-tu seul, et tout le peuple se tient-il devant toi, depuis le matin jusqu'au soir? l 18. 15 Moïse répondit à son beau-père: C'est que le peuple vient à moi pour consulter Dieu. l 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. l 18. 17 Le beau-père de Moïse lui dit: Ce que tu fais n'est pas bien. l 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. l 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. l 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. l 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. l 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. INF 6153 l 18. 23 Si tu fais cela, et que Dieu te donne des ordres, tu pourras y suffire, et tout ce 100 peuple parviendra heureusement à sa destination.

Autre exemple de cible XACML Exercice: décoder ce cible. Physicians or (nurses and emergecy room) or (nurses and operating room) and (surgeries reports or diagnosis) and read La syntaxe XACML est simplifiée pour faciliter la lecture Exemple tiré de: B. Stepien, A. Felty, S. Matwin: A non-technical target editor for dynamic access control systems In: Collaboration Technologies and Systems (CTS), 2014, 150 – 157 (disponible dans IEEE Xplore) INF 6153 101