From centralized to single sign on

Transcription

1 The LemonLDAP::NG project Abstract LemonLDAP::NG is a modular WebSSO (Web Single Sign On) software 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, which made of LemonLDAP::NG a complete AAA (authentication, authorization and accounting) product. This paper will focus on the LDAP support, which is the historical authentication protocol used for SSO session opening. LDAP is now widely used in the product, from configuration store to password management. From centralized to single sign on Using LDAP directories for authentication in web application has been a real progress for users, as they could use a single credential to log in several services. We can call this centralized sign on, as the user password is stored and check in a single place. You should be aware that even if this method seems obvious, a lot of web applications today still do not propose such feature and force users to have a local password on their service. Centralized sign on is a first step (and a high step for legacy products), and the next one is the single sign on: this time, the user will use his credential to log in the first time to a service, and will then be logged on every service relying on te single sign on system. History of the project LemonLDAP was created in French administrations to have a free alternative for proprietary WebSSO products, like SiteMinder or Novell ichain (the lemon word comes from the mirror word of novell: novell llevon lemon). Of course the LDAP part of the product name means that originally the only supported authentication protocol was LDAP. The creator of the project is Eric GERMAN, who built in 2003 the Handler (Apache agent used for cookie validation and access control) and the Portal (authentication form). The project was then re-factored in 2006 by Xavier GUIMARD, who added a Manager (configuration management interface) and named the new software LemonLDAP::NG (new generation). The old branch is now dead and the NG version is the only one in activity. In 2011, the project leadership was given to Clément OUDOT, and Thomas CHEMINEAU complete the development team. LemonLDAP::NG is no more a French administration project, it is used by a lot of private helds, in Europe and in other countries.

2 Fundamentals Architecture LemonLDAP::NG is built around three 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). Portal provides also many other features, like password reset service. Handler: Apache modules used to protect applications Illustration 1: LemonLDAP::NG architecture Wen can distinguish two kinds of database, or back-ends: Internal databases, used only to manage LemonLDAP::NG specific data: Configuration Sessions Notifications (recent feature allowing messages to be displayed to users) External databases, managed outside LemonLDAP::NG: Authentication: how authenticate users User: where collect user data

3 Password: where change the password Kinematics The single sign on process is the following: 1. User tries to access protected application, his request is catched by Handler 2. SSO cookies is not detected, so Handler redirects user to Portal 3. User authenticates on Portal 4. Portal checks authentication 5. If authentication succeed, Portal collect user data 6. Portal creates a session to store user data 7. Portal gets the session key 8. Portal creates SSO cookies with session key as value 9. User is redirected on protected application, with his new cookie 10. Handler gets session get from cookie and gets session 11. Handler stores user data in its cache 12. Handler check access rule and send headers to protected applications 13. Protected application sends response to Handler 14. Handler sends the response to user Illustration 2: Single sign on process Authentication process main steps are: Authentication mechanism Control asked URL: prevent XSS attacks and bad redirections Control existing session: detect SSO session, apply configured constraints (1 session per user, 1 session per IP, ) Extract form info: get login/password, certificate, environment variable (depending on authentication

4 module) Get user info: contact user database to collect attributes Set macros: compute configured macros Set groups: request user database to find groups Set local groups: compute configured groups Authenticate: contact authentication database to check credentials Grant session: check rights to open SSO session Store: store user info in session database Build cookie: build SSO cookies with session ID Redirect: redirect user on protected application or on Portal (applications menu) LemonLDAP::NG supports a lot of authentication schemes: LDAP Database SSL X509 Apache built-in modules (Kerberos, NTLM, OTP, ) SAML 2.0 / Shibboleth OpenID Twitter CAS Yubikey Multiple and Choice (modules stacking) Authorization mechanism Authorization is controlled only by Handlers. An authorization is defined by: An URL pattern (or default to match other URLs) An access rule This is a very powerful system, as regular expressions can be used to match the area to protect: directories, file extensions, etc. You can choose to unprotected some part of the application, and also catch logout URLs to disconnect the user form the single sign on system. LDAP power LemonLDAP::NG loves LDAP still the beginning of its life. This love still remains, even if other authentication methods are now supported. The Perl Net::LDAP library is used to communicate with LDAP servers. Standard use LemonLDAP::NG uses LDAP as many other application: authenticate user and get some information on him. A search is done with a custom filter based on the login, then the DN of the found entry is used in a bind operation

5 containing also the password submitted by the user. LemonLDAP::NG collects some attributes of the entry to store them in session. They will then be used for access control and headers provisioning. Group membership Local groups can be configured in LemonLDAP::NG trough rules: if the user respect a group rule, he is added to the group for the SSO session. But LemonLDAP::NG can also be configured to browse LDAP directory to find group membership: a search is done on the groups branch, and names of the groups containing the user are collected to be added to user's local groups. A special feature allows to browse groups recursively: if a user belongs to group1 which belongs to group2, group1 and group2 will be stored as user's groups for the SSO session. Password policy It is one of the main interest of the LDAP support in LemonLDAP::NG. The password policy is server-side feature allowing an LDAP directory to manage authentication protection (locking account after several bad authentications) and password change (checking password quality, history, renewal, etc.). We find this feature for example in OpenLDAP with the ppolicy overlay, or with SUN-like directories like OpenDS, OpenDJ or RedHat DS. First, LemonLDAP::NG use the password policy control when a password change is done. If the password is not accepted, a correct message is shown to the user, by using the response control flag (for example: password too short, password in history). It works also in the password reset by mail feature, which allows a user to get a mail challenge to reset its password. The user can then set a new password, or ask LemonLDAP::NG to generate one. If the password generation is chosen, the user will need to change it at the next connection. Then, the authentication process also uses the password policy control: if the account is locked or expired, the message is shown to the user (instead of just: bad authentication). If the password policy response control want to advertise user about soon password expiration, or grace uses, the corresponding information is displayed. The need to reset the password at the next connection is also managed: in this case, the user must change its password before opening SSO session. Configuration and sessions The last but not the least, LemonLDAP::NG can store configuration and sessions in an LDAP directory. This is particularly interesting in high availability infrastructure: a multi-master LDAP back-end is easier to deploy than an mutli-master SQL back-end, and so, you can have a lot a LemonLDAP::NG instance sharing configuration and session over a scalable LDAP infrastructure.