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

[Mike Rylander]

On Fri, Dec 4, 2009 at 8:48 PM, Joe Atzberger <jatzberger at esilibrary.com> wrote:
> Right, that's why I was talking about this in terms of a potential feature
> (presumably desirable, inasmuch as I was commissioned to implement it for a
> different platform) that is problematic with multiple back ends.
>
>> user must exist in the Evergreen instance, period.
>

To clarify, the user must exist for authentication to complete, and to
do anything within the system.  It doesn't mean that the user has to
exist when the init call is made.

> Then I think we indeed agree on the restriction I described.  That
> requirement specifically blocks the add-on-the-fly feature, and satisfies
> the question from a technical perspective.

I think that's still an open question.

ISTM that it's a matter of the alternate auth service having the
ability to create users under the right circumstances.  That in itself
is a fairly simple matter.  The more complicated matter is dealing
with the security implications of allowing users to add themselves to
the Evergreen instance.  At the least, it will require some amount of
coordination on the remote system's end ...  And /that/ is something
that will take a good bit more thought, IMO.

We can certainly discuss adding users on the fly, but I don't think
the current proposal (still unfleshed, and under discussion, of
course) disallows it, and I think it's a big enough chunk of
functionality that we can put it off until later

--miker

>
> That said, I think the your authz approach is the right one.
> --joe
>
> On Fri, Dec 4, 2009 at 7:33 PM, Mike Rylander <mrylander at gmail.com> wrote:
>>
>> 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