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:

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: Save and reload Apache and Handler to get the configuration updated.

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:

DIA_DIT_Roles.png

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

So he is "user" on application "BBB" and "admin" on application "AAA".

Now we have to send to right role to the right application trough LemonLDAP::NG.

First step: create a rule to grant access only if the user has a role in the application: 
default => $ssoRoles =~ /ou=aaa,ou=roles/

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): 
aaaRole => ((grep{/ou=aaa/} split(';',$ssoRoles))[0] =~ /ou=(.*),ou=aaa/)[0]

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: 
Auth-Roles => $aaaRoles

Auth-Roles => $bbbRoles


Now the protected application can read in the header HTTP_AUTH_ROLES the role of the user.