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.
- 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
We call “database” a backend where we can read or write a data. This can be a file, an LDAP directory, …
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:
- 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.
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.
- Handlers have a session cache, with a default lifetime of 10 minutes. So for Handlers on different physical servers than the Portal, a user with an expired session can still be authorized till the cache expires.
- Sessions are deleted by a scheduled task. Don’t 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 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