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

[Joe Atzberger]

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

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.

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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20091204/425eaa8c/attachment.htm