XACML (eXtensible Access Control Markup Language) est un langage basé sur XML dédié au contrôle d’accès. Il a été standardisé par OASIS en 2005
[Oas05]. Ce langage a été proposé pour l’implémentation du modèle ABAC et l’expression de ses politiques en se basant sur les attributs. XACML définit trois niveaux de politiques : ensemble de politiques (PolicySet), politique ( Po-licy) et règle (Rule). La Figure2.3représente la structure des politiques dans XACML. Un PolicySet est une agrégation de plusieurs politiques (Policy) et éventuellement d’autres PolicySet. Une politique se compose d’un ensemble de règles de contrôle d’accès. Chaque règle est composée d’un effet (Effect) et d’une cible (Target). Un effet indique le résultat de l’évaluation d’une règle. Il peut avoir comme valeur Permit (autorisé) ou Deny (non autorisé). Une cible est un ensemble de propriétés associées aux sujets, aux ressources, aux actions et à l’environnement qui permettent d’identifier les règles et les poli-tiques appropriées pour l’évaluation d’une requête donnée. Cette notion de cible de XACML a été introduite afin de facilité la recherche des règles qui doivent s’appliquer à une requête donnée. En plus de l’effet et de la cible, une règle peut contenir optionnellement une condition qui représente une expression booléenne qui permet de définir des restrictions plus complexes sur les attributs.
Figure 2.3–Schémas des politiques XACML
Puisqu’un PolicySet peut contenir plusieurs politiques et qu’une poli-tique peut contenir plusieurs règles, différentes décisions peuvent être prises dans un même PolicySet et dans une même politique. Afin de résoudre les incohérences des différentes décisions, XACML définit des algorithmes de combinaison. Les PolicySet utilisent des algorithmes de combinaison de po-litiques (policy-combining algorithm) afin de combiner les décisions des dif-férentes politiques et générer une seule décision. Tandis que les politiques (Policy) utilisent des algorithmes de combinaison de règles (rule-combining
algorithm) afin de générer une seule décision à partir des décisions des diffé-rentes règles.
La décision retournée peut être :
– Permis (Permit) : Cette décision indique que l’accès est autorisé ; – Interdit (Deny) : Cette décision indique que l’accès est refusé ;
– Indéterminé (Indeterminate) : Cette décision indique qu’il y a une erreur et/ou qu’un attribut manque ou est inconnu ;
– Non applicable (NotApplicable) : Cette décision indique qu’il n’y a au-cune règle qui peut s’appliquer à la requête.
Quatre algorithmes de combinaison ont été définis dans la spécification
2.0du standard XACML :
– Permit-overrides : s’il existe au moins une règle/politique applicable et évaluée avec un effet "Permit" alors la décision de combinaison est "Permit".
– Deny-overrides: s’il y a au moins une règle/politique applicable et éva-luée avec un effet "Deny" alors la décision de combinaison est "Deny".
– First-applicable : la décision de combinaison est la décision de
la première règle/politique applicable dans la liste. L’ordre des règles/politiques est important dans cet algorithme.
– Only-one-applicable : le résultat de combinaison assure qu’il existe une seule règle/politique applicable dans la liste. S’il n y a aucune règle/politique applicable alors le résultat de combinaison est " NotAp-plicable", si plusieurs règles/politiques sont applicables alors le résultat de combinaison est "Indeterminate" ; si une seule règle/politique est ap-plicable alors la décision retournée est celle de cette règle/politique. La spécification de la version3.0du standard ajoute une extension de ces algorithmes comme suit :
– Ordered-permit-overrides : cet algorithme utilise le même principe que "Permit-overrides", sauf que les règles/politiques sont évaluées dans l’ordre dans lequel elles sont définies.
– Ordered-deny-overrides: la même chose pour cet algorithme.
– Deny-unless-permit: Cet algorithme est destiné à être utilisé dans les cas où la décision "Permit" est prioritaire à la décision "Deny". L’utilisation de cet algorithme garantie d’avoir toujours une décision "Permit" ou une décision "Deny". Les décisions "Indeterminate" et "NotApplicable" ne sont jamais retournées.
– Permit-unless-deny: Le même principe pour cet algorithme qui est des-tiné à être utilisé dans les cas où la décision "Deny" est prioritaire à la décision "Permit".
– Legacy Deny-overrides: Cet algorithme est un peu plus complexe que les autres et il est utilisé dans les cas où la décision "Deny" a une priorité par rapport à la décision "Permit"
– Legacy Permit-overrides : Cet algorithme est destiné à être utilisé dans les cas où la décision "Permit" a une priorité par rapport à la décision "Deny".
Les principales entités de l’architecture XACML sont les suivants : – Le point de décision de politiques (PDP -Policy Decision Point) : C’est
ren-voie une décision d’autorisation. Ce terme a été défini par l’IETF et le DMTF dans le RFC31984 .
– Le point d’application de politiques (PEP - Policy Enforcement Point) : C’est l’entité qui intercepte la requête et l’envoie pour l’évaluer au ni-veau PDP. Elle contrôle l’accès en appliquant la décision retournée par le PDP. Cette entité est aussi définie dans le RFC3198. Elle peut être incorporée dans l’application ou placé comme intercepteur en dehors de l’application.
– Le point d’information de politiques (PIP - Policy Information Point) : C’est l’entité qui extrait des informations supplémentaires pour le PDP avant de prendre la décision.
– Le point d’administration de politiques (PAP - Policy Administration Point) : C’est l’entité du système qui définit les politiques et les rend disponibles au PDP.
La spécification2.0a définit une architecture de XACML sous forme d’un diagramme de flots de données. La Figure 2.4 présente une vue simplifiée de ce diagramme.
Figure 2.4–Diagramme de flots de données XACML [Oas05]
Les différentes étapes du diagramme sont décrites comme suit :
1. Le PAP définit les politiques ou l’ensemble de politiques et les rend disponibles au PDP.
2. Le demandeur d’accès (Access Requester) envoie une requête d’accès au PEP.
3. Le PEP envoie la requête au format natif au gestionnaire de contexte (Context Handler).
4. Le gestionnaire de contexte traduit la requête au format standard et l’envoie au PDP.
5. Le PDP peut demander au gestionnaire de contexte des attributs sup-plémentaires.
6. Le gestionnaire de contexte demande à son tour ces attributs au PIP.
7. Le PIP obtient les attributs demandés.
8. Le PIP retourne les attributs au gestionnaire de contexte.
9. Le gestionnaire de contexte envoie les attributs au PDP qui évalue la politique.
10. Le PDP retourne la décision au format standard au gestionnaire de contexte.
11. Le gestionnaire de contexte traduit la réponse au format natif utilisé par le PEP et l’envoie à ce dernier.
Comme nous l’avons mentionné, le standard XACML a été proposé comme un standard pour l’utilisation du modèle ABAC. Afin de répondre aux besoins des applications qui utilisent le modèle RBAC, OASIS a défini un profil pour RBAC [And05] qui répond aux exigences de la norme ANSI RBAC.
Ce profil propose des politiques (Policy) et des ensembles de politiques (PolicySet) spécifiques pour l’expression des politiques du modèle RBAC avec le langage XACML comme suit :
– Permission <PolicySet> ou PPS : définit les permissions associées à un rôle. Un PPS peut faire référence à un autre PPS et donc il hérite toutes les permissions définies dans le PPS référencé.
– Role <PolicySet>ou RPS : associe un rôle à un PPS. De ce fait, le rôle aura toutes les permissions définies dans le PPS. Si un rôler1 est as-socié à un PPS p1 et un autre rôler2 est associé à un PPS p2 et p1 fait référence à p2, alors le rôler1 aura les permissions déjà définies dans
p1 et hérite les permissions du rôler2 qui sont définies dans p2. – Role Assignment <Policy> ou<PolicySet> : spécifie quels rôles peuvent
être attribués à quels sujets. L’utilisation de ces politiques est option-nelle.
– HasPrivilegesOfRole <Policy>: C’est une politique dans un PPS qui per-met de savoir si un sujet a les permissions associées à un rôle donné. Le modèle RBAC doit être implémenté en utilisant les PPSs et les RPSs. Pour chaque rôle, un RPS et un PPS doivent être définis. La hiérarchie des rôles est réalisée à travers le mécanisme de référencement entre les PPSs.