LDAP Schema for advanced access rules
Topic
LemonLDAP::NG is powerfull WebSSO engine who manage access trough user's attributes stored in an LDAP directory. We can use standards attributes like uid, cn or mail to describe access rules to protected web applications. But sometimes we need more information! For example:- An application name (to allow access by applications and not by group of users)
- A start date and an end date (to open or close the service even the entry already exists)
- A time profile (allowed hours and day of the week)
- One or more roles (to send to the protected applications)
LDAP Schema
OID prefix
We plan to use this prefix: 1.3.6.1.4.1.10943.10.2. The prefix 1.3.6.1.4.1.10943 is owned by LINAGORA (See http://www.iana.org/assignments/enterprise-numbers).OpenLDAP schema
Just add this file to OpenLDAP schemas:#======================================= # Schema for advanced SSO access rules # # Designed for OpenLDAP software # http://www.openldap.org # # Part of LemonLDAP::NG project # http://lemonldap.ow2.org # # Author: Clement OUDOT #=======================================
#======================================= # OID Prefix # Registered in IANA database #======================================= objectIdentifier SSOOID 1.3.6.1.4.1.10943.10.2
#======================================= # Attributes #=======================================
# Application Name attributetype ( SSOOID:1:1 NAME 'ssoName' DESC 'An application name' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# Roles attributetype ( SSOOID:1:2 NAME 'ssoRoles' DESC 'One or more roles' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# Time profile attributetype ( SSOOID:1:3 NAME 'ssoTimeProfile' DESC 'A time profile' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# Start date attributetype ( SSOOID:1:4 NAME 'ssoStartDate' DESC 'Start date' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# End date attributetype ( SSOOID:1:5 NAME 'ssoEndDate' DESC 'End date' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
#======================================= # ObjectClasses #=======================================
# SSO user objectClass ( SSOOID:2:1 NAME 'ssoUser' DESC 'SSO extended informations for a user' SUP top AUXILIARY MAY ( ssoName $ ssoRoles $ ssoTimeProfile $ ssoStartDate $ ssoEndDate ) )
How to use it in LemonLDAP::NG
Specify new attributes in exported variables
In LemonLDAP::NG Manager, go to General Parameters > Exported Variables and add new variables:- ssoName => $ssoName
- ssoRoles => $ssoRoles
- ssoTimeProfile => $ssoTimeProfile
- ssoStartDate => $ssoStartDate
- ssoEndDate => $ssoEndDate
Habilitation based on an application name
If a user has got the ssoName attribute, with each value being the name of a protected application, you can configure the rules of virtualhosts by checking the application name.
Go in LemonLDAP::NG Manager, choose your virtualhost (for example test.acme.com), and set the default rule to accept users if they have "acme" has one of the value of their attribute "ssoName":
default => $ssoName =~ /\bacme\b/
Save and reload.
Now you can decide who access this application just by adding or removing a value inside the entry of the users.
Habilitation based on a date
If the user has got ssoStartDate and/or ssoEndDate, you can configure rules to compare the current date to the start/end dates.
Habilitation based on a period
If the user has got ssoTimeProfile, you can configure rules to compare the current time and compare it to the time profile.
Send a role to a protected application
Roles as simple values of a user attribute
Imagine you've set your directory schema to store roles as values of ssoRoles, an attribute of the user. This is simple because you can send the role to the application by creating a HTTP header (for example Auth-Role) with the concatened values (';' is the concatenation string):
Auth-Roles => $ssoRoles
If the user has these values inside its entry:
ssoRoles: user ssoRoles: admin
Then you got this value inside the Auth-Roles header:
user;admin
Roles as entries in the directory
Now imagine the following DIT:

Roles are entries, below branchs representing applications. Each user has a ssoRoles attributes, which values are the DN of the corresponding roles. With this oragnization, you can set roles to user within specific application.
In the schema above, the user has the following values:
ssoRoles: ou=admin,ou=aaa,ou=roles,dc=acme,dc=com ssoRoles: ou=user,ou=bbb,ou=roles,dc=acme,dc=com
- For application AAA:
default => $ssoRoles =~ /ou=aaa,ou=roles/
- For application BBB:
default => $ssoRoles =~ /ou=bbb,ou=roles/
Second step: get the role name for the application. We will use the macros to do that. Create two macros (inside General Parameters > Macros):
- For application AAA:
aaaRole => ((grep{/ou=aaa/} split(';',$ssoRoles))[0] =~ /ou=(.*),ou=aaa/)[0]
- For application BBB:
bbbRole => ((grep{/ou=bbb/} split(';',$ssoRoles))[0] =~ /ou=(.*),ou=bbb/)[0]
These regular expressions read the 'ou' value of the DN of the role of the concerned application. This work if the user has only one role per application.
Third step: provide the role to the application. It is done by creating the correct HTTP header:
- For application AAA:
Auth-Roles => $aaaRoles
- For application BBB:
Auth-Roles => $bbbRoles
Now the protected application can read in the header HTTP_AUTH_ROLES the role of the user.