
Informations
Années | 2011 - 2014 |
---|---|
Catégorie | Projet professionnel |
Société | ![]() |
Langages | CSS3, HTML 5, Java, JavaScript, LDAP, Perl, Prolog, SQL |
Présentation du projet
Le projet MRM (Meibo Role Management) a été initié dans le cadre du projet Role-ID. Il consiste en la réalisation d'une solution de "role management" basé sur le modèle OrBAC (Organization Based Access Control) décrit ci-dessous. Par conséquent, cette solution est dédiée à la gestion du cycle de vie des rôles et des droits des utilisateurs au seins d'un système d'information.
OrBAC
Définition
Le modèle OrBAC (Organization Based Access Control) permet la modélisation de politiques de sécurité. Il est basé sur les rôles des utilisateurs et est centré sur le contexte de l’organisation.
Afin de réduire la complexité de gestion des droits, ce modèle respecte quatre principes fondamentaux :
- L’organisation est l’entité centrale du modèle
- Il y a deux niveaux d’abstractions :
- Le niveau concret :
- Sujet (/Utilisateur)
- Action
- Objet
- Le niveau abstrait :
- rôle (= ensemble de sujets avec les même règles de sécurité)
- activité (= ensemble d’actions avec les même règles de sécurité)
- vue (= ensemble d’objet avec les même règles de sécurité)
- Le niveau concret :
- Les contraintes sur les droits peuvent être d’exprimées sour forme :
- De permissions
- D'interdictions
- D'obligations
- Il est possible d’exprimer des contextes dans lesquels s'appliquent les contraintes sur les droits
Ainsi les politiques de sécurités (permissions, interdictions et obligations) seront exprimées sur le niveau abstrait et s’appliquera sur tous les éléments concernés du niveau concret.
Par exemple, si l’organisation Ilex autorise au niveau abstrait le rôle « Manager » à consulter l’application de gestion du personnel, alors, au niveau concret tous les sujets (/utilisateurs) liés au rôle « Manager » (dans l’organisation Ilex) pourront consulter cette application.
Intéractions
Les principales interactions sont :
- Habilite : Permet à une organisation de lier un sujet à un rôle
- Considère : Permet à une organisation de lier une action à une activité
- Utilise : Permet à une organisation de lier un objet à une vue
Le schéma suivant présente les interactions prévues par le model OrBAC :
La notion de contexte
Un contexte est défini pour une organisation, un sujet, une action et des objets. Le contexte va permettre de simuler les différentes circonstances. Ainsi les permissions peuvent varier en fonction de l’heure, du lieu, de conditions spéciales. Par exemple : un médecin qui aurait accès à un fichier médical dans le cadre d’une urgence auquel il n’a normalement pas de droit d’accès.
La notion de hierarchie
Il est possible d’organiser les rôles de façon hiérarchique. Ainsi, les rôles héritent des autorisations des rôles qui leurs sont hiérarchiquement inférieurs. On dit que :
- Le rôle R1 est senior du rôle R2 si R1 est hiérarchiquement supérieur au rôle R2
- Le rôle R1 est junior du rôle R2 si R1 est hiérarchiquement inferieur au rôle R2
Il en va de même pour les Organisations où l’on peut considérer qu’une organisation sénior hérite des affectations (habilitation, considérations et utilisation) et politiques (permissions, interdictions et obligations) de ses organisation junior.
La délégation
La délégation permet à un utilisateur de donner un des privilèges auquel il a accès à un autre utilisateur. Ainsi le deuxième utilisateur pourra effectuer une tâche à la place du premier.
Cependant la délégation pose deux problèmes :
- Le risque de déléguer des droits d’administration (cela pourrait permettre au deuxième utilisateur de supprimer les droits du premier)
- Le risque d’oublier de révoquer les droits temporaires
Pour cela le modèle ORBAC propose deux types de permissions :
- Les permissions déléguables
- Les permissions non déléguables
La gestion des conflits
Le modèle ORBAC permet de mettre en place des permissions, des interdictions ainsi que des obligations. Cependant cela peut générer des conflits. En effet, une personne qui hérite de plusieurs rôles dont l’un donne une permission interdite par un autre comment doit-on choisir ?
Pour répondre à cette question ORBAC prévoit la mise en place d’un système de priorité sur les permissions. Ainsi, si l’on se retrouve dans une situation de conflit, c’est la permission la plus prioritaire qui sera prise en compte. Dans le cas ou deux permissions seraient de priorité identique alors il faut avertir le concepteur des politiques pour qu’il les adapte.
Travail réalisé
- Recherche et développement
- Conception du modèle de base de données (MySQL, PostgreSQL)
- Conception et développement Java du modèle OrBAC (Utilisation de Hibernate)
- Conception et développement de l'affectation automatique des utilisateurs à leur(s) rôle(s)
- Conception et développement des provisionings amont et aval
- Conception et développement des simulateurs :
- Du niveau abstrait
- Du niveau concret
- D'affectations des utilisateurs aux rôles
- Conception et développement d'un module d'audit (utilisation de Jasper-report)
- Conception et développement d'un générateur de politiques aléatoires pour les tests
- Implémentation des interfaces utilisateur via la solution Meibo
- Implémentation Prolog du modèle OrBAC
- Optimisation des performances
- Support
- Qualification
- Référent technique
- Formateur