[OPEN-ILS-DEV] LDAP Authentication Ideas

[Mike Rylander]

On Sat, Dec 5, 2009 at 6:32 AM, Nathanael Schilling
<nathanaelschilling at gmx.net> wrote:
> On Friday 04 December 2009 10:42:57 pm Mike Rylander wrote:
>> descriptive
>>
> so how do we handle create update and delete methods on users in a) ldap
> b)evergreen? i.e. what happens if user x is deleted in ldap, but not in
> evergreen,

There are various ways to handle that, requiring various levels of
coordination with and by the designated authoritative source.  I can
imagine at least three ways to handle this.  This will be very policy
driven, though, and very implementation specific, and my goal right
now is to settle on a framework upon which specific implementations
and policy models can be built.

To my that a little less hand-wavy, 3 ways:

1) Don't delete, but deacitvate, in the LDAP server
2) Nightly deletion from Evergreen of deleted users
3) Have the alternate auth[z] service record and use a user stat-cat
value stating that an ldap user MUST exist for such users, intern the
native process into the alternate service and remove "native" from the
protocol order, and don't use "native" if the users' record is a "must
have ldap account" one.

> or if user y is added to the ldap database, meaning the user can
> somehow log in, but doesn't really "exist" yet.

Again, this is implementation and local policy specific, but you can
certainly see, from the above, what I'll suggest -- the alternate auth
service learns how to add users, under the right conditions.
Configuration of that service to tell it what data to move is left as
an exercise for the reader. :)

> How about if user with
> username "bob" exists in ldap, but is a different user to the "bob" which
> exists in evergreen as ldap capability was added with a non-new evergreen db
> and non-new ldap db?

Well, first, there needs to be some external process that maps users
-- there's really no way around that, and it will be
instance-specific.

A "good" OTTOMH plan:

First, we need to add a trigger to both actor.card and actor.usr that
maintain a UNIQUE constraint that encompasses cards and non-deleted
users.  Then, all auth services can including the native one can just
check both for the string passed by the user -- no more segregating
card and usrname by regex!  (Note: I think this would be a good think
in any case.)

That will allow us to absorb, as a secondary active card, a unique
identifier (perhaps namespaced as Joe suggests, but that's opaque to
Evergreen) from an alternate auth service at the begining of the
.complete call.  That's the on-the-fly addition of users.  It's also
what the external mapping process would do (create cards) to sync the
databases and prime the pump.

-------

Or, the user can just wait until a nightly batch process adds their
account, using a unique identifier from the remote system as the
usrname.  This, in combination with locking down usrname editing, is
in use today in at least one Evergreen instance.

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