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

[Mike Rylander]

On Fri, Dec 4, 2009 at 7:13 PM, Joe Atzberger <jatzberger at esilibrary.com> wrote:
> "Depends on OU info" vs. "OU info not present".
>
> It's just namespace.  Say you have multiple LDAP backends.  In my
> institution, I login as "jsmith" w/ my password.  That works fine in that
> ecosystem.  But now EG has multple servers that have their own "jsmith"
> users.  Which one is EG supposed to fetch as me?  I'm not in the EG server
> yet, so it can't decide for me.
>
> So instead I have to login using a more fully qualified form like
> "jsmith at myinstitution.edu".  It's not a dealbreaker, but it isn't the same
> as when I'm inside the single-institution namespace.

For a login to be meaningful, a unique (meaning, any namespace is
opaque to Evergreen proper) user must exist in the Evergreen instance,
period.  How it gets in there, and when, is not within the scope of
what we're talking about right now.  What I've proposed is just a
pluggable, stackable auth[z] mechanism -- a way of allowing some
entity, other than the Evergreen actor.user table, to store the
authoritative password, and have it checked for validity.

--miker

>
> --joe
>
>
> On Fri, Dec 4, 2009 at 4:59 PM, Mike Rylander <mrylander at gmail.com> wrote:
>>
>> On Fri, Dec 4, 2009 at 3:20 PM, Joe Atzberger <jatzberger at esilibrary.com>
>> wrote:
>> > Multiple LDAP targets that depend on OU information will block the
>> > development of a feature to, say, add a new EG user on the fly when
>> > otherwise valid LDAP credentials are supplied.  Either that or the UI
>> > will
>> > have to prompt the user to self-identify their OU.
>>
>> Um ... why?  I see no such restriction.
>>
>> --miker
>>
>> >
>> > --joe
>> >
>> >
>> > On Fri, Dec 4, 2009 at 2:38 PM, Duimovich, George
>> > <George.Duimovich at nrcan-rncan.gc.ca> wrote:
>> >>
>> >> Dan/Mike,
>> >>
>> >> We'd have the same requirements here at NRCan Library, since we could
>> >> forsee being in a consortial environment somewhere down the road. And
>> >> as
>> >> noted in an earlier thread http://markmail.org/message/kkqmk6n4to7xj6ay
>> >> we
>> >> have users with and without LDAP access (but I think that seems covered
>> >> in
>> >> the 'napkin' sketch)..
>> >>
>> >> George Duimovich
>> >> NRCan Library / Bibliothèque de RNCan
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: open-ils-dev-bounces at list.georgialibraries.org
>> >> [mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of
>> >> Dan
>> >> Scott
>> >> Sent: December 4, 2009 14:01
>> >> To: Evergreen Development Discussion List
>> >> Subject: Re: [OPEN-ILS-DEV] ***SPAM*** Re: LDAP Authentication Ideas
>> >>
>> >> On Fri, 2009-12-04 at 11:56 -0500, Mike Rylander wrote:
>> >> <snip>
>> >> > 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?
>> >>
>> >> One more wish that I don't think is covered by your napkin - and
>> >> possibly
>> >> reflecting only Conifer's needs, although as more heterogeneous
>> >> consortia
>> >> enter the scene it will likely be desired by more than just Conifer -
>> >> it
>> >> would be nice to be able to associate a particular configuration of a
>> >> given
>> >> auth method, or set of auth methods, with a particular org_unit.
>> >>
>> >> Concrete example: Laurentian University and the University of Windsor
>> >> would both love to use LDAP authentication. But Laurentian needs to
>> >> point at
>> >> their own LDAP server, and Windsor needs to point at their own LDAP
>> >> server.
>> >>
>> >> Maybe open-ils.auth/app_settings grows a <default> element, with
>> >> optional
>> >> elements for org_unit shortnames that provide the auth method &
>> >> associated
>> >> configuration for users based on their home_ou?
>



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