LemonLDAP::NG is a modular WebSSO (Single Sign On) written in Perl.
It is highly customizable, and can be deployed in many different environments and for many different uses. It manages both authentication and authorization and provides customizable logging for accounting. So you can have a full AAA protection for your applications.
Manager: used to manage LemonLDAP::NG configuration and to explore sessions. Dedicated to administrators
Handler: used to protect applications which can read HTTP headers or environment variables to get user information
We use “database” as a generic term for backends that are not included with LemonLDAP::NG but that we need in order to provide the SSO service. They can be a LDAP directory, a SQL database server, or even a simple local file.
We split databases in two categories:
External databases: are not managed by LemonLDAP::NG. Data is externally provided and LemonLDAP::NG generally just needs to read it.
Internal databases: its data is controlled by LemonLDAP::NG
Main external databases are:
Authentication: how users are authentified (password, certificate, etc.)
User: where to find user attributes
Password: how user passwords are changed
Registration: where new users are created
Second factors: how second factors are validated
Main internal databases are:
User tries to access a protected application, his request is caught by Handler
SSO cookie is not detected, so Handler redirects user to Portal
User authenticates on Portal
Portal checks authentication
If authentication succeeds, Portal collects user data
Portal creates a session to store user data
Portal gets the session Id
Portal creates SSO cookie with the session Id as value
User is redirected on protected application, with a SSO cookie
Handler reads session Id from the cookie and retrieves user session data
Handler stores user data in its cache
Handler checks access rules and sends headers to the protected application
Protected application sends response to Handler
Handler forwards the response to the user
Then handler will check SSO cookies for each HTTP request.
Default use case:
User clicks on the logout link in Portal
Portal destroys session and redirects user on itself with an empty SSO cookies
User is redirected on portal and his SSO cookies is empty
LemonLDAP::NG is also able to catch logout request on protected applications, with different behavior:
SSO logout: the request is not forwarded to application, only the SSO session is closed
Application logout: the request is forwarded to application but SSO session is not closed
SSO and Application logout: the request is forwarded to application and SSO session is closed
After logout process, the user is redirected on portal, or on a configured URL.
The session expires after 20 hours by default. This duration can be set in the manager’s Configuration tab (General Parameters > Sessions > Sessions Timeout).
Handlers have a session cache, with a default lifetime of 10 minutes. So for Handlers embedded by different physical servers than the Portal, a user with an expired session can still be authorized until the cache expiration.
Sessions are deleted by a scheduled task. Do not forget to install cron files!
Cross Domain Authentication (CDA)¶
For security reason, a cookie provided for a domain cannot be sent to another domain. To extend SSO on several domains, a cross-domain mechanism is implemented in LemonLDAP::NG.
User tries to access a protected application in a different domain
Handler does not see SSO cookies (because it is not in main domain) and redirects user on Portal
Portal recognizes the user with its SSO cookies, and see he is coming from a different domain
Portal redirects user on protected application with a token as URL parameter. The token is linked to a session which contains the real session ID
Handler detects URL parameter, gets the real session ID, delete the token session and creates a SSO cookies on its domain, with session ID as value