Forum OpenACS Development: Pluggable authentication for OACS: moving towards a concrete plan
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.
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.
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.
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 ...
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.