[OPEN-ILS-DEV] LDAP Authentication Ideas

Sat Oct 24 03:45:37 EDT 2009

Hi Dan, this is great news.  We have LDAP in our institution.
Academic libraries would benefit from this.
David.

2009/10/23 Dan Wells <dbw2 at calvin.edu>:
> 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
>>>
>

-- 
David Kane
Systems Librarian
Waterford Institute of Technology
Ireland
http://library.wit.ie/
T: ++353.51302838
M: ++353.876693212