[OPEN-ILS-DEV] LDAP Authentication Ideas

Fri Oct 23 16:10:23 EDT 2009

Hello all,

Attached is my first stab at an LDAP authentication service.  It works in the way I described as "internal" in my initial email.  To use it, you will need to copy LDAP_Auth.pm into your 'lib/OpenILS/Application/' directory, apply the two patches to the appropriate files, edit opensrf.xml as needed for your config, then start the service.

The configuration options are mostly straightforward, but a few may need some explanation.  You need to set a 'salt' variable, one or more unique attribute names from your LDAP server as 'pass_gen_attrs', then make sure your internal Evergreen passwords are set (probably through a sync script) to md5_hex( $salt . md5_hex($ldap_string) ) where $ldap_string is a concatenation of any attribute values for the attribute names you put in 'pass_gen_attrs'.  I think it is much easier than it sounds :)  Because anyone with $salt and $ldap_string can potentially authenticate to any user's Evergreen account, make sure to protect those values appropriately.

If you put in more than one <server_config>, the service will cycle through multiple LDAP servers until it authenticates successfully.  This makes it possible, for instance, to use an organization level LDAP server and a local LDAP server at the same time.

Finally, if you set <fallback> equal to true, any credentials which fail to authenticate to LDAP will try to authenticate normally using the built-in authentication scheme.  In this way you can still authenticate users who are not in LDAP at all.

So far, it seems to be working for us, and I hope it has enough clarity and flexibility to be of use to others.  I probably left out some critical detail, so please do not hesitate to ask!

Cheers,
Dan

>>> On 10/16/2009 at 9:24 AM, David Fiander <david at fiander.info> wrote:
> Innovative has an LDAP authentication module, which we use at UWO.
> We're in a similar situation to George in that we have users with LDAP
> credentials and users without. It seems that Innovative can select the
> authentication method to use based on the patron type: faculty, staff,
> students use the LDAP method, alumni and guest borrowers use the
> internal "name & barcode" authentication method.
> 
> Something like that, having the authentication method be dispatched
> through the patron types table, would probably be fantastic.
> 
> - David
> 
> On Fri, Oct 16, 2009 at 9:16 AM, Duimovich, George
> <George.Duimovich at nrcan-rncan.gc.ca> wrote:
>>
>> 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 
>>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: opensrf.xml.patch
Url: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20091023/732655f3/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: opac_utils.js.patch
Url: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20091023/732655f3/attachment-0001.txt 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LDAP_Auth.pm
Type: application/octet-stream
Size: 5944 bytes
Desc: not available
Url : http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20091023/732655f3/attachment.obj 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: DCO.txt
Url: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20091023/732655f3/attachment-0002.txt 