[OPEN-ILS-DEV] ***SPAM*** Re: ***SPAM*** Re: LDAP Authentication Ideas

[Mike Rylander]

On Fri, Dec 4, 2009 at 11:56 AM, Mike Rylander <mrylander at gmail.com> wrote:
> On Wed, Dec 2, 2009 at 5:21 PM, Dan Scott <dan at coffeecode.net> wrote:
>> A question about LDAP authentication just came up on IRC again, and I
>> dug up this thread.
>>
>> This deserves a code review; there's certainly a demand for the feature.
>
> As the code stands right now, there's one logical error, I believe,
> but otherwise it looks sound.  On line 149 of LDAP_Auth.pm, I think
> you want ||= instead of |= for logical vs binary or-equals.
>
>> And I'd like to be able to tell people something other than "your best
>> bet at the moment for an open source ILS with LDAP integration is
>> probably Koha", as I did to the inquirer on IRC.
>>
>
> Agreed.  This seems like as good a time as any to discuss overall
> design of a plugable auth system.  So ... I'll do that.  I'm going to
> ignore details about things like transports (HTTP vs HTTPS, native
> LDAP, etc) which, while critical to do it right, can probably wait
> until we work out the scaffolding.
>
> By way of rough napkin scribbling, how about the following:
>
> open-ils.auth does what it does now, but learns a new trick: backend
> authz protocol mediation.  We add a new parameter to the
> authenticate.init call, call it "protocol", and if it is not set then
> the current dance is performed.  However, if this protocol parameter
> is set to some known value (more on how to define those later) then we
> in addition to passing back the random value that is used for password
> salting in the native authz protocol, we pass back the name of a
> service that can handle the authentication.complete call.
>
> So, why do we continue passing back the salt value?  Because we can
> use it as a one-time memcache scratchpad key for communication between
> open-ils.auth and the service that publishes the implementation of
> open-ils.auth.authenticate.complete that we want to use.  As a start,
> to "prime the pump" as it were, we can push the username supplied to
> .init into an object and toss that object at memcache using the salt
> as the key.

Actually, I realize after more consideration that if we're putting the
onus on the client to discover and use the correct protocols, part of
this is not needed.  We don't need to pass back the protocol to use
with the seed, the client will figure that part out and the return
signature of open-ils.auth.authenticate.init does not need to change.

--miker

>
> Now, how to we tell open-ils.auth about other services, and which
> protocols they serve?  Config file settings.  Under the <app_settings>
> section for open-ils.auth, we add:
>
> ...
> <protocols>
>  <ldap>joes.random.ldap.authz.opensrf.application</ldap>
>  <pam>mikers.pam.authz.app</pam>
> </protocols>
> <protocol_order>native,joes.random.ldap.authz.opensrf.application,mikers.pam.authz.app</protocol_order>
> ...
>
> And then we write joes.random.opensrf.application and
> mikers.pam.authz.app, which each publish a method called
> open-ils.auth.authenticate.complete (different services can publish
> methods with the same name all day long) that handles ldap junk.
>
> Now ... how do we make clients do the right thing, since we're telling
> them now that they must request a specific protocol?  We give
> open-ils.auth a new method, open-ils.auth.supported-protocols, which
> returns the JSON version of the above data structure.  The openils
> dojo module that handles user login will use the list of protocols and
> the protocol order to try logging in the user.  The protocol name
> "native" would be a marker saying "do the original auth dance".  If no
> protocols or protocol order are specified, native is assumed.
>
> A dojo module with the name matching the application would be supplied
> along with the backend service and would define the semantics of the
> call to open-ils.auth.authenticate.complete that it implements.  So,
> the openils dojo module would look at the protocol order, and for each
> not spelled "native" it would require that module.  For example:
> dojo.require('joes.random.ldap.authz.opensrf.application'); ... it
> would then loop over each, in the order specified, attempting to log
> the user in using the service-specific dojo plugin, which would supply
> the correct params to its matching implementation of
> open-ils.auth.authenticate.complete.
>
> Thoughts?
>
>> Dan
>>
>> On Fri, 2009-10-23 at 16:10 -0400, Dan Wells wrote:
>>> 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
>>> >>
>>
>>
>>
>
>
>
> --
> Mike Rylander
>  | VP, Research and Design
>  | Equinox Software, Inc. / The Evergreen Experts
>  | phone:  1-877-OPEN-ILS (673-6457)
>  | email:  miker at esilibrary.com
>  | web:  http://www.esilibrary.com
>



-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com