mercredi 30 avril 2008

Explications sur le modèle RBAC

Absent quelques semaines pour cause de paternité, je reviens maintenant sur quelques éléments de l'IAM.

RBAC (Role Based Access Control) définit un modèle d'autorisation pour accéder à des ressources. Ce modèle a été mis en oeuvre par le NIST (National Institute of Standard and Technology). Le schéma ci-dessous représente ce modèle avec les dénominations du NIST (traduction littérale des termes employés).



On appelle "Permissions" l'ensemble des opérations qui peuvent être réalisé sur un ensemble de ressources appartenant à une même application ou infrastructure. Des exemples de "Permission" peuvent être des groupes Unix ou Oracle, un profil dans une application web permettant d'accéder à des menus spécifiques...

Le rôle est un élément de factorisation permettant de donner un ensemble de Permissions à des utilisateurs en une seule opération ("j'ai ce rôle donc j'ai ces Permissions"). Le modèle permet aussi de créer des rôle imbriqué ou héritage de rôle. Il est intéressant de noter qu'il n'existe pas de sémantique spécifique sur la notion de rôle. Certains essaieront d'y associer la notion de métier ou fonction mais rien n'y oblige.

Il est possible de mettre des contraintes sur la notion de rôle :
  • une date de début d'activation,
  • une date de fin d'activation,
  • un périmètre permettant de contraindre le rôle (périmètre sur les données via un recoupement géographique, organisationnel, valeur chiffrée permettant à un acheteur de na pas passer de demande d'achat supérieur à ce montant...)
Un rôle devra pouvoir être donné de deux manières :
- statique (il est donné manuellement par quelqu'un).
- dynamiquement (il est donné de manière automatique par le module de gestion des habilitations selon certaines valeurs des attributs des identités répondant à des règles implémentées).

Il est à noter qu'un rôle peut être soumis à workflow mais que les Permissions associées ne devraient jamais être soumise à workflow sous peine de rendre le modèle incohérent. Imaginons qu'un rôle X donne les permissions A et B. Le rôle X est validé, la permission A est validé mais la permission B est refusée. Que doit-on faire? Refuser aussi X et A : cela rendrait inconsistant la notion même du rôle. Donner X et A mais ne pas donner B : il serait difficile de comprendre cet état de fait sur la fiche de la personne en question à postériori à moins de tracer ces éléments dans la fiche ce qui devient très complexe.

Si on veut soumettre une Permission à workflow, cela est possible mais cette Permission ne doit pas être incluse dans un rôle.

La notion de rôle n'a de sens que pour le module de gestion des habilitations. Elle n'a aucun sens pour les applications provisionnées ou protégées par un web SSO.
Par contre afin que le module de gestion des habilitations puissent propager les droits dans les systèmes cibles ou puissent protéger ces systèmes cibles, il est nécessaire de modéliser le nom de chaque Permission dans le module de gestion des habilitations. L'erreur à ne pas commettre est de modéliser la définition des Permissions dans le module de gestion des habilitations (quelles opérations sur quelles ressources). Ces couples Opérations-Ressources doivent rester la propriété des applications sous peine de mettre en oeuvre un système non maintenable.

La mise en oeuvre de rôle impliquera une gestion de ces rôles :
- les définir et les faire vivre (modification, suppression),
- les faire prendre en compte les réorganisations,
- définir les propriétaires, les administrateurs.

Cette gestion de rôle (role management) s'avère souvent complexe et sera abordée dans un prochain billet.