The current DEF LDAP authentication system works well, but some partners have come to consider it is a security risk that users disclose their ID and password to servers that are not controlled by themselves. This proposal builds on and extends the current DEF LDAP infrastructure in a way that this potential risk is removed as user IDs and passwords are only disclosed to the local (trusted) server of the user's own organisation.
Furthermore, the implementation of LDAP on top of proprietary user databases can be non-trivial thus slowing down the addition of small organisations to the DEF authentication infrastructure. This proposal, by using a simple authentication mechanism, reduces the complexity of interfacing heterogeneous user databases.
Technically, the proposal extends the existing DEF LDAP infrastructure by adding CAS, the Open Source Central Authentication Service of Yale University - see web-site http://www.yale.edu/tp/auth/ and CAS-Dispatcher, the Open Source DEF Login Service, which is a relatively simple login and validation dispatcher to be developed in order to make CAS work in multi-organisational settings. Both CAS and CAS-Dispatcher seem simple to add to the existing LDAP infrastructure and likewise the demands on the service providers is quite manageable.
| 1. | User contacts an arbitrary service provider requiring authentication and is redirected to the CAS-Dispatcher. If the service provider does not require up-front authentication, it may offer a link to the CAS-Dispatcher for users wanting to login. In both cases, the URL contains the service ID (the service web server URL). |
| 2. | CAS-Dispatcher prompts the user to choose the relevant local user database (CAS server) for login. CAS-Dispatcher returns a cookie (C1) specifying the CAS server of choice to avoid repeated prompting. CAS-Dispatcher redirects the user to the appropriate CAS server with a service ID, which integrates its own URL as well as the original service ID. |
| 3. | The CAS server prompts the user for ID/password and validates this, either using the local LDAP server through its LDAP backend (standard DEF scenario) or by accessing any other local user database. If successful, the CAS server returns a cookie (C2) to avoid repeated logins during the browser session. CAS redirects the user to the CAS-Dispatcher integrating the original service ID as well as a CAS ticket (a large random number) in the URL. |
| 4-5. | CAS-Dispatcher adds the CAS server ID to the CAS ticket which now becomes the CAS-Dispatcher ticket, unique across CAS servers. CAS-Dispatcher redirects the user to the service provider web server with the CAS-Dispatcher ticket integrated in the URL. |
| 6-7. | The service provider requests a CAS-Dispatcher ticket validation from the CAS-Dispatcher which in turn validates the CAS ticket with the appropriate CAS server. |
In the model described above, the CAS-Dispatcher is only visible to end-user, during the selection of authentication organisation (CAS server). To the service providers, it appears like a regular CAS server and to the CAS servers, it appears like a regular service provider.
The current design plans for an optional extension of the CAS validation request to allow the transfer of non-sensitive user information (i.e. name, email) so the service provider may personalise its user interface. This extension will be added to the CAS-Dispatcher validation service but will require a simple service running parallel to the user's CAS server. This service will use either LDAP or the local user database to return the value of non-sensitive user fields. Because this service will not be available for all CAS servers, failure to access that service will not result in a validation failure but rather to a fallback to the standard CAS validation reply.