RBAC signifie contrôle d'accès basé sur les rôles (Role Based Access Control). Celà signifie qu'on gère les autorisations d'accès aux applications en examinant le(s) rôle(s) de l'utilisateur et en fournissant ce(s) rôle(s) à l'application.
LemonLDAP::NG permet d'utiliser ce modèle. Il est préférable d'utiliser un schéma LDAP étendu (ou toute extension de base de données utilisateur), mais ça peut fonctionner avec les attributs standard.
On suppose que le schéma d'annuaire a été prévu pour stocker les rôles comme valeur de ssoRoles, un attribut utilisateur. C'est simple car on peut envoyer le rôle à l'application en créant un en-tête HTTP (par exemple Auth-Role) en concaténat les valeurs (avec ';' en séparateur) :
Auth-Roles => $ssoRoles
Si l'utilisateur dispose de ces valeurs dans son entrée :
ssoRoles: user ssoRoles: admin
On les obtient dans l'en-tête Auth-Roles :
user; admin
On suppose le schéma suivant :
Les rôles sont des entrées, les branches subordonnées représentant les applications. Chaque utilisateur a des attributs ssoRoles, dont les valeurs sont les DN des rôles correspondants. Avec cette organisation, on peut définir les rôles de l'utilisateur au sein de chaque application.
Dans le schéma ci-dessus, l'utilisateur dispose des entrées suivantes :
ssoRoles: ou=admin,ou=aaa,ou=roles,dc=acme,dc=com ssoRoles: ou=user,ou=bbb,ou=roles,dc=acme,dc=com
Ainsi, il est “user” sur l'application “BBB” et “admin” sur l'application “AAA”.
Il faut maintenant envoyer le bon rôle à la bonne application via LemonLDAP::NG.
Première étape : créer une règle pour autoriser l'accès seulement si l'utilisateur dispose d'un rôle dans l'application:
default => $ssoRoles =~ /ou=aaa,ou=roles/
default => $ssoRoles =~ /ou=bbb,ou=roles/
Seconde étape : obtenir le rôle dans cette application. On utilise les macros pour ça. Créer deux macros (dans Variables
» Macros
):
aaaRole => ((grep{/ou=aaa/} split(';',$ssoRoles))[0] =~ /ou=(.*),ou=aaa/)[0]
bbbRole => ((grep{/ou=bbb/} split(';',$ssoRoles))[0] =~ /ou=(.*),ou=bbb/)[0]
Ces expressions régulières lisent la valeur 'ou' du DN du rôle de l'application concernée. Ceci fonctionne si l'utilisateur a seulement un rôle par application.
Troisième étape : fournir le rôle à l'application. C'est fait en créant l'en-tête HTTP correct :
Auth-Roles => $aaaRoles
Auth-Roles => $bbbRoles
Maintenant, l'application protégée peut lire le rôle de l'utilisateur dans l'en-tête HTTP_AUTH_ROLES.
aaaRole => join(' || ', (map {/uid=(.*),ou=aaa.*/} (grep{/ou=aaa/} split(';',$ssoRoles)))