Informations

Année	2011
Catégorie	Stage de fin d'étude
Société
Langages	Java, XML
Compatibilité	Linux, Windows

Présentation du projet

Ce projet consiste en la réalisation d’une architecture de contrôle d’accès respectant la norme XACML drécrite ci-dessous. Il s’inscrit dans le cadre du projet Role-ID.

XACML

Définition

XACML (eXtensible Access Control Markup Language) est un langage standardisé par OASIS basé sur XML et dédié au contrôle d’accès. Dans ce langage, toute entité concernée par le contrôle d’accès (i.e. sujets, ressources, actions et environnement) est spécifiée par un ensemble d’attributs.
Dans une communication XACML on distingue trois éléments :

• La politique XACML qui permet d’autoriser (ou interdire) à un sujet d’exercer une ou plusieurs actions sur une ou plusieurs ressources dans un environnement donné.
• La requête XACML qui correspond à une question du type : "Le/les sujets S peuvent-ils exercer la/les actions A sur la/les ressources R ?"
• La réponse XACML qui peut être :
  • Permit : si la réponse est positive
  • Deny : si la réponse est négative
  • NotApplicable : si aucune des politiques ne s’applique
  • Indeterminate : en cas d’erreur ou de conflit entre plusieurs politiques.

Architecture

Extrait de http://www.cse.wustl.edu/~jain/cse571-09/ftp/soa/

Fonctionnement

Le principe de fonctionnement de l'architecture est le suivant ;

1. L’administrateur détermine les politiques de sécurité
2. Les politiques sont envoyées au PDP (Policy Decision Point) via le PAP (Policy Administration Point qui sert d’interface d’administration du PDP)
3. Un utilisateur effectue une demande d’accès sur une ressource pour une action donnée auprès du PEP (Policy Enforcement Point)
4. Le PEP va traduire la requête de l’utilisateur au format XACML et la transmettre au "Context Handler" (gestionnaire de contexte)
5. Le "Context Handler" transmet la demande d’autorisation vers le PDP qui va tenter de l’évaluer
   1. Le PDP, pour rendre une autorisation/interdiction d’accès, peut avoir besoin de certains attributs supplémentaires. Il avertit alors le "Context Handler" dans le but de recevoir ces attributs
   2. Le "Context Handler", après avoir reçu la demande d’attributs, contacte le point de gestion des attributs PIP (Policy Information Point) en vue d’obtenir les informations utiles pour la prise de décision
   3. Le PIP est relié avec différents gestionnaires d’attributs. Chaque gestionnaire permet d’obtenir des informations sur : 
      1. Les sujets (identités)
      2. L’environnement/le contexte
      3. Les ressources
   4. Après avoir obtenu les différents attributs demandés par le "Context Handler", le PIP,  les transmet à ce dernier
   5. Le "Context Handler" peut également accéder aux ressources afin d’en récupérer certaines informations
   6. Le "Context Handler" transfère les attributs qu’il a reçus au PDP en vue d’une prise de décision
6. Le PDP exécute des algorithmes de prise de décision avec toutes les informations qu’il possède : 
   • Les requêtes d’accès qu’il doit vérifier dans le but de donner une autorisation, un refus ou une indétermination
   • Les ensembles de politiques de sécurité (PolicySet, Policy) comportant des règles (Rule) d’attribution d’autorisation
   • Les attributs permettant d’identifier si les conditions d’une politique sont satisfaites ou non
7. Le PDP rend alors sa décision, toujours au format XACML, au "Context Handler"
8. Le "Context Handler", après avoir récupéré la décision auprès du PDP, la transmet au point d’application de la politique PEP. Ce dernier, selon la décision rendue, peut donc soit donner au demandeur d’accès l’autorisation d’accéder à la ressource pour y effectuer l’action prévue, soit l’en empêcher