Forum OpenACS Development: Pluggable authentication for OACS: moving towards a concrete plan

Collapse
1: Pluggable authentication for OACS: moving towards a concrete plan
Posted by Andrew Grumet on 09/13/02 08:44 PM
I think we're pretty familiar now with the request that OACS be able to authenticate users against external databases. Here are a few relevant bboard threads: https://openacs.org/search/search?q=kerberos.

A number of players in the dotLRN space are interested in making this happen. A general solution will require changes to OACS core, so I'd like to start a discussion on how to move forward. Don, Ben, Gatekeepers and Community: assuming that we can come up with a mutually agreeable approach, are you open to this in principle?

I'll go out on a limb here and anticipate one kind of response: "By all means, knock yourselves out. But we're too swamped to work on it. But we WILL want to code-review and we reserve the right to reject ugly solutions." This is fine and reasonable. Sloan is willing to invest some time spec'ing the work, shopping the specs around, and managing available developer resources.

Collapse
2: Response to Pluggable authentication for OACS: moving towards a concrete plan (response to 1)
Posted by Ben Adida on 09/13/02 11:54 PM
more than interested, I can provide some actual input on this stuff for having
seen many single sign-on systems.

The first question to ask is: what is the exact goal? Are we trying to have
OpenACS users authenticate against an external system? Are we trying to
have the OpenACS system *be* the authoritative user database against
which other systems can authenticate?

In addition, are we looking at mostly username/password schemes, or are we
looking at more intricate cryptographic systems (certificates, etc...)? To some
degree, this matters less, since this can be somewhat abstracted out (but not
completely - you need to define your baseline security assumptions about
what credentials exist out there).

So let's set a simple initial goal. I would vote for looking at username/
password authentication against external systems as a first step.

Collapse
3: Response to Pluggable authentication for OACS: moving towards a concrete plan (response to 1)
Posted by Andrew Grumet on 09/14/02 01:22 AM
So let's set a simple initial goal. I would vote for looking at username/ password authentication against external systems as a first step.
I second your vote. The immediate request I have before me is: to be able to authenticate against an LDAP or Radius or Kerberos server. All are instances of username/password authentication.
Collapse
4: Response to Pluggable authentication for OACS: moving towards a concrete plan (response to 1)
Posted by Don Baccus on 09/14/02 02:57 AM
Yes, I think this sounds right, too.  A simple service contract approach would make it easy to do authentication plugins.

One problem comes to mind.  We allow for a variety of new registration policies - open, admin must approve, e-mail verification etc.  These are by their nature dependent on the authentication system being used.  In fact in many cases the policy will be transparent to OpenACS (i.e. the foreign authenticator sets the policy for new registrants).

So ... this alone isn't really a problem but leads to my thinking (out loud, as I type this) that some care needs to be taken in defining exactly the contract that ties together our end to the authentication package (one of which would be a refactored version of the current authentication code).

The old acs-ldap package shadows externally-authenticated users in the local database.  We need a party object id for perm checking and all that.  So that's another area that needs to be thought out ...

Collapse
5: Response to Pluggable authentication for OACS: moving towards a concrete plan (response to 1)
Posted by Andrew Grumet on 09/14/02 05:14 PM
Good points.  A variant of this problem is deciding who can modify User X's password.  I don't know offhand what the various protocols allow.  Some research is in order.  I'm thinking to give this thread a few more days to simmer, and then putting together a design document and posting it somewhere for us to collaborate on.
Collapse
6: Response to Pluggable authentication for OACS: moving towards a concrete plan (response to 1)
Posted by Andrew Grumet on 09/14/02 05:19 PM
Just a clarification about the previous post.  Mainly we need to figure out the conditions under which User X can modify User X's password locally vs sending them somewhere else to do it.  I didn't mean to imply that we try to deal with remote authorization databases in this round (bleah).
Collapse
8: Response to Pluggable authentication for OACS: moving towards a concrete plan (response to 1)
Posted by Andrew Grumet on 09/19/02 04:02 PM
One point of clarification.  These APIs would most definitely NOT replace "ad_conn user_id".  The last thing we want is to have to modify every single tcl file in the system.  They would be consumed mostly by the pages under packages/acs-subsite/register/.
Collapse
9: Response to Pluggable authentication for OACS: moving towards a concrete plan (response to 1)
Posted by Andrew Grumet on 10/11/02 09:13 PM
I've taken another cut at this: https://openacs.org/new-file-storage/download/oacs-pam.html?version_id=687.

Many of us are busy with releases and other tasks, so there may not be much progress here in the near future. But I wanted to get the ideas up just the same in case anybody wants to run with it.