[OPEN-ILS-DEV] LDAP Authentication Ideas

[Duimovich, George]

We haven't looked at LDAP but are interested. We have both internal
clients with LDAP accounts and external users (no LDAP accounts) so
we'll eventually need something that allows their My Account login to
either figure out which 'domain' to authenticate against, or let the
user chose EG vs. Departmental authentication.

In the interim - for active users - we use a variation of option b) by
setting Username to their login id so that when they first login they
could optionally sync their EG password for something more familiar to
the user (like their LDAP pwd). We also will likely populate username
field with LDAP login when we eventually begin to sync parts of our
patron database with our ldap directory. 

George D.


-----Original Message-----
From: open-ils-dev-bounces at list.georgialibraries.org
[mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of
Nathanael Schilling
Sent: October 16, 2009 06:05
To: Evergreen Development Discussion List
Subject: Re: [OPEN-ILS-DEV] LDAP Authentication Ideas

Interresting...
I was looking into LDAP (specifically AD) authentication a week or so
ago, but couldn't come up with a solution that
a) Was secure (i.e. didn't involve storing cleartext passwords)
b) Had password uniformity (i.e. both eg and ldap had the same
passwords)
c) Synced passwords between ldap and eg one way.

If I understood correctly, your solution exports all LDAP users and then
loads them into eg, right?

I like your method, but the only drawback I can see is that passwords
are submitted cleartext over the web, though that might not be a too big
problem for some people. 

Another question would be how many places code would need to be modified
for this to work? staff client,OPAC, anything else?

Otherwise, this looks quite promising, keep us posted on the mailing
list!
Nathanael Schilling


On Wednesday 14 October 2009 10:27:34 pm Victoria Bush wrote:
> 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