[OPEN-ILS-DEV] LDAP Authentication Ideas

[Dan Wells]

Hello all,

I am in the process of implementing a basic LDAP authentication layer for my library for the catalog 'My Account' features.  I currently have two working proof-of-concepts and am seeking input about further development of one or the other.

The overall approach is common to both and is as follows.  The users are exported from LDAP and batch loaded into the Open-ILS system, but the password in Open-ILS is not their LDAP password, but instead is a salted/hashed version of their LDAP ID.  The Open-ILS LDAP authetication layer receives the username and password from a web form, binds with LDAP using these as credentials to receive the LDAP ID and verify the password, salts and hashes the ID and uses the this ID and hash to authenticate to Open-ILS.

So far I have gotten this to work using both an external and an internal form.  For the external version, a separate (mock) login page is created, the user submits their credentials, the script behind the form performs the LDAP bind and subsequent authenticate_init and authenticate_complete steps, then sets the 'ses' cookie variable and redirects to the My Account page.  The primary advantages of this approach are needing only to alter the login/logout button behavior in the OPAC and also perhaps not needing an SSL certificate for the catalog server (as the external script can run from a different, already secure server).

For the internal version, I created a simple OpenSRF service which replaces/wraps both authenticate_init and authenticate_complete into a single step (since we can simply send the password along) and which is accessed by a slightly modified doLogin script.  This approach allows one to use the My Account login page more or less as-is, but does require a bit more customization on the server end.

I am not really sure what best practices are for customizations to the OPAC, but I am wondering if a standard way to override doLogin needs some consideration.  While it seems I can override the authentication behavior in 'config.js', since neither the 'init' nor the 'complete' step actually sends the password, the current doLogin has limited applicability to any completely 3rd-party authentication scheme.

Please let me know if you feel the overall approach is sensible or if something else would be better, and also if one implementation or the other would have unforeseen problems.

Thank you all,
Dan

-- 

*********************************************************************************
Daniel Wells, Library Programmer Analyst dbw2 at calvin.edu
Hekman Library at Calvin College
616.526.7133