Présentations
Meibo Role Management

Informations

Années 2011 - 2014
Catégorie Projet professionnel
Société Ilex international
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 : 

  1. L’organisation est l’entité centrale du modèle 
  2. 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é)
  3. Les contraintes sur les droits peuvent être d’exprimées sour forme :
    • De permissions
    • D'interdictions
    • D'obligations 
  4. 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 :

mrm interaction

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
Copyright © 2011 - 2017 ROLLAND Cyrille Tous droits réservés