Presentation
LemonLDAP::NG is a modular WebSSO (Single Sign On) based on Apache::Session modules. It simplifies the build of a protected area with a few changes in the application.
It manages both authentication and authorization and provides headers for accounting. So you can have a full AAA protection for your web space as described below.
Architecture
Main components
Manager: used to manage LemonLDAP::NG configuration and to explore sessions. Dedicated to administrators
Portal: used to authenticate users, display applications list and provides identity provider service (SAML, OpenID, CAS). Futhermore, Portal affordes many other features (see portal for more)
Handler: used to protect applications which can read HTTP headers or environment variables to get user information
Databases
Attention
We call “database” a backend where we can read or write a data. This can be a file, an LDAP directory, etc.
We split databases in two categories:
External databases: not managed by LemonLDAP::NG, for example user database
Internal databases: only used by LemonLDAP::NG
Main external databases are:
Authentication: how authenticate users
User: where collect user data
Password: where change the password
Main internal databases are:
Configuration: where configuration is stored. This does not include web server configuration which is not managed by LemonLDAP::NG
Sessions: where sessions are stored.
Notifications: messages displayed to connected users
Cache: cache for configuration and sessions
Kinematics
Login
User tries to access protected application, his request is catched by Handler
SSO cookies is not detected, so Handler redirects user to Portal
User authenticates on Portal
Portal checks authentication
If authentication succeed, Portal collect user data
Portal creates a session to store user data
Portal gets the session key
Portal creates SSO cookies with session key as value
User is redirected on protected application, with his new cookie
Handler reads session key from cookie and retrieves user session datas
Handler stores user datas in its cache
Handler check access rule and send headers to protected application
Protected application sends response to Handler
Handler forwards the response to user
Then handler will check SSO cookies for each HTTP request.
Logout
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.
Session expiration
The session expires after 20 hours by default. This duration can be set in the manager’s Configuration tab (General Parameters > Sessions > Sessions Timeout).
Attention
Handlers have a session cache, with a default lifetime of 10 minutes. So for Handlers located on different physical servers than the Portal, a user with an expired session can still be authorized until the cache expires.
Sessions are deleted by a scheduled task. Don’t forget to install cron files !
Cross Domain Authentication (CDA)
Note
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 owns SSO cookies on the main domain (see Login kinematics)
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