LemonLDAP::NG: More than just SSO
Software version | 1.2.3 |
Operating System | Debian 7 |
Website | LemonLDAP::NG Website |
Others | Apache 2.2 |
Introduction
LemonLDAP::NG was created by Éric German for the French Ministry of Finance. Initially named LevonLDAP, in tribute to Novell, it was designed to be compatible with Novell’s single sign-on (SSO) authentication system. It is based on the book “Writing Apache Modules with Perl and C The Apache API and mod_perl” by Doug MacEachern and Lincoln Stein (O’Reilly).
It was later renamed LemonLDAP::NG. From 2004, the project was gradually taken over by the French National Gendarmerie to become LemonLDAP::NG in 2005. Both projects coexisted for some time before LemonLDAP support was definitively abandoned.
It’s an SSO system with a unique identifier/password pair. SSO does not handle access control.
SSO Modes
- SSO by agent: installed on the client machine. No notion of security
- SSO by delegation: The user only needs their web browser. The server application points to the authentication portal
- Reverse proxy: Authentication is handled through a reverse proxy
HTTP Requests
Before diving into LemonLDAP, we need to understand how the HTTP protocol works. Let’s try to retrieve a website:
|
|
|
|
The return code is 200, everything is fine. You can check the list of HTTP return codes here: http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
Cookies
The HTTP protocol is stateless. To maintain a persistent connection, we need to use HTTP 1.1 protocol. We also use cookies to store sessions. On the server side, the user session ID is stored. A cookie can be up to 4096 bytes maximum.
There are several types of cookies:
- Session cookies: The cookie will remain active for a defined time or until the browser is closed
- Persistent cookies: They remain active permanently
A cookie exchange works like this:
- A simple request
- Server response with a “Set-cookie” header field
- Client request with a “Cookie” header field
As a reminder, cookies are only valid on a single DNS domain.
LemonLDAP
The Components
LemonLDAP::NG uses 3 components:
- The portal: authentication interface, application menu, password change
- The Handler: Apache module that controls access to web applications
- The Manager: the graphical part for configuring LemonLDAP
Communication
The advantage compared to CAS is that the client does not need to go back through LemonLDAP::NG with each web service change.
Authentication Phases
- When a user tries to access a protected application, their request is intercepted by the Handler
- If the SSO cookies are not detected, the Handler redirects the user to the portal
- The user authenticates on the portal
- The portal verifies their authentication
- If validated, the portal retrieves the user information
- The portal creates a session where it stores the user information
- The portal retrieves a session key
- The portal creates SSO cookies with session key/value
- The user is redirected to a protected application with their new cookie
- The Handler retrieves the cookie and session
- The Handler records user data in its cache
- The Handler checks access rights and sends headers to protected applications
- Protected applications send a response to the Handler
- The Handler sends a response to the user
The Different Databases
Several databases are used:
- Authentication: how to validate authentication data
- Users: user data
- Password: where to change the user password
- Provider: how to provide identity to an external service
For example, you can use Kerberos with LDAP.
Internal databases:
- Sessions: server-side session storage
- Configuration: configuration storage (versioned)
- Notifications
Authentication Methods
- LDAP
- Database
- SSL X509
- Apache modules (Kerberos, OTP…)
- SAML 2.0
- OpenID
- CAS
- Yubikey
- Radius
Session Storage
LemonLDAP::NG uses 3 levels of cache:
- Apache::Session::*: final storage of sessions
- Cache:Cache*: allows the Handler to share data between Apache threads and processes
- Internal variables to LemonLDAP::NG::Handler: if the same user uses the same thread or process again.
Installation
Now for the practical part! You can either use the version available through the official repositories, or add the LemonLDAP::NG repository, which is what we’ll do here:
|
|
Then update:
|
|
Let’s change the default configuration which is example.com:
|
|
After this, you should not modify these configuration files manually!
Let’s enable the sites and the Perl module for Apache:
|
|
Then restart Apache:
|
|
Configuration
Manager
For the manager to work:
|
|
DNS Configuration
For DNS resolution to work correctly:
|
|
Test Application
There are test1.example.com and test2.example.com to test your sites with username and password ‘dwho’: http://test1.example.com
Other admin accounts that exist are:
- rtyler/rtyler
- msmith/msmith
- dwho/dwho
This page will allow you to see important information that will be exchanged with LemonLDAP::NG. It’s useful for debugging in addition to Apache logs.
Protection
In the file /etc/lemonldap-ng/lemonldap-ng.ini
we can configure who has access to the manager!
|
|
By default, the protection is set to Manager, which is good. Only authorized people can connect to it (VirtualHost). It’s possible to use rules to specify something specific (a uid for example).
Authenticate allows any user who connects to have access to the manager. And the last option, none, is strongly discouraged as it allows anyone to access it.
Macros
Macros allow you to create variables in LemonLDAP. For example:
$fullname => $givenname . '' . $surname
You can then reuse $fullname.
Sessions
By default, every 10 minutes (via cron) there is a check for sessions that need to be purged: /etc/cron.d/liblemonldap-ng-portal-perl
.
HTTP Headers
Script Parameters
You can modify GET requests to POST, for example.
Notifications
They allow information to be validated by users and are stored in persistent sessions.
For example, you can create a disclaimer.
CAS
LemonLDAP::NG can handle CAS as either a client or server. CAS only performs URL redirections, with the possibility of proxy tickets.
Server
When acting as a CAS server, you need to enable rewrite rules:
|
|
Client
|
|
SAML
Here are some terms to understand:
- IDP: Identity Provider
- CoT: Circle of Trust
- InterCoT: Circle of Trust between IDPs
- AA: Attribute Authority
- Proxy IDP: proxy for IDP to transfer identity requests
- SP: Service Provider
To install LASSO (SAML), you need to install this:
|
|
References
Last updated 16 Mar 2013, 08:33 +0200.