[OPEN-ILS-DEV] LDAP Authentication Ideas

[Victoria Bush]

I don't know how feasible this is, but in our environment the ability  
to authenticate against LDAP itself would be wonderful. I would prefer  
it if there isn't a separate password in Open-ILS, as we have a lot of  
centralized services that authenticate against LDAP and it would be so  
nice to allow Evergreen to do the same.

-Vicki

On Oct 12, 2009, at 3:56 PM, Dan Wells wrote:

> 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
>
>

--
Victoria Bush
Opscan Evaluation Manager
Center for Teaching, Learning & Technology
vbush at ilstu.edu