documentation:2.1:rbac

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

documentation:2.1:rbac [2019/01/15 15:55] (current)
Line 1: Line 1:
 +====== RBAC model ======
 +
 +===== Presentation =====
 +
 +[[ http://en.wikipedia.org/wiki/Role-based_access_control|RBAC]] stands for Role Based Access Control. It means that you manage authorizations to access applications by checking the role(s) of the user, and provide this role to the application.
 +
 +As the definition of access rules is free in LemonLDAP::NG, you can implement an RBAC model if you need.
 +
 +
 +===== Configuration =====
 + 
 +==== Roles as simple values of a user attribute ====
 +
 +Imagine you've set your directory schema to store roles as values of an attribute of the user, for example "description". This is simple because you can send the role to the application by creating a HTTP header (for example Auth-Role) with the concatenated values (';' is the concatenation string):
 +<code>
 +Auth-Roles => $description
 +</code>
 +
 +If the user has these values inside its entry:
 +<file>
 +description: user
 +description: admin
 +</file>
 +
 +Then you got this value inside the Auth-Roles header:
 +<code>
 +user; admin
 +</code>
 +
 +==== Roles as entries in the directory ====
 +
 +Now imagine the following DIT:
 +  * dc=example,dc=com
 +    * ou=users
 +      * uid=coudot
 +    * ou=roles
 +      * ou=aaa
 +        * cn=admin
 +        * cn=user
 +      * ou=bbb
 +        * cn=admin
 +        * cn=user
 +
 +
 +Roles are entries, below branches representing applications. We can use the standard LDAP objectClass ''organizationalRole'' to maintain roles, for example:
 +<file ldif>
 +dn: cn=admin,ou=aaa,ou=roles,dc=example,dc=com
 +objectClass: organizationalRole
 +objectClass: top
 +cn: admin
 +ou: aaa
 +roleOccupant: uid=coudot,ou=users,dc=example,dc=com
 +</file>
 +
 +A user is attached to a role if its DN is in ''roleOccupant'' attribute. We add the attribute ''ou'' to allow LL::NG to know which application is concerned by this role.
 +
 +So imagine the user coudot is "user" on application "BBB" and "admin" on application "AAA".
 +
 +=== Gather roles in session ===
 +
 +Use the [[authldap#groups|LDAP group]] configuration to store roles as groups in the user session:
 +  * Base: ou=roles,dc=example,dc=com
 +  * Object class: organizationalRole
 +  * Target attribute: roleOccupant
 +  * Searched attributes: cn ou
 +
 +=== Restrict access to application ===
 +
 +We configure LL::NG to authorize people on an application only if they have a role on it. For this, we use the ''$hGroups'' variable.
 +
 +  * For application AAA:
 +<code>
 +default => groupMatch($hGroups, 'ou', 'aaa')
 +</code>
 +  * For application BBB:
 +<code>
 +default => groupMatch($hGroups, 'ou', 'bbb')
 +</code>
 +
 +=== Send role to application ===
 +
 +It is done by creating the correct HTTP header:
 +  * For application AAA:
 +<code>
 +Auth-Roles => ((grep{/aaa/} split(';',$groups))[0] =~ /([a-zA-Z]+?)/)[0]
 +</code>
 +  * For application BBB:
 +<code>
 +Auth-Roles => ((grep{/bbb/} split(';',$groups))[0] =~ /([a-zA-Z]+?)/)[0]
 +</code>
 +