Forum OpenACS Development: Re: RFC: External Authentication
here are some comments on the External Auth Specs.
a) Design Goals
The design schould be on the one hand open to add other
authentification mechanisms when needed and on the
other hand very modular to enable a start with minimal
requirements (implementations) as soon as possible.
b) Diagram
The Authentication Driver API can
1) either connect to PAM (portable authentication module)
of the underlying supported Unix-Systems (Linux,
Solaris) and then PAM can be configured to connect to
a RADIUS server or via LDAP to a Kerberos Server, an
Active Directory e.g. - an example of this is the
OpenSource SSH-Daemon.
2) or connect to "it´s own" RADIUS or LDAP driver for
authentication checking. The creation of these drivers
is subject to a service contract implementation.
For the 1st implementation I suggest to use the PAM
services of the Unix-System, thus using the existing
PAM-RADIUS or PAM-LDAP modules. We would like to start
with PAM-RADIUS and to migrate to PAM-LDAP against an
Active Directory later.
c) Configuration
The domain driver for the "local" domain (the existing
OpenACS registration using email address and password)
MUST be integral part of the implementation and NOT
subject to another service contract.
d) Synchronizing and Linking Users
An Email address belongs either to a remote domain or
to the "local" domain. Any conflict with an existing
Email address - and we can foresee some - should be
handled with an error message and administrative
intervention reuqired and NOT with program code.
e) Account creation
Out of our needs a batch job to run each night for
creation and/or update of the OpenACS/dotLRN accounts
would be sufficient to start with.
Dynamic creation needs much more thoughts and other
authentication services - a RADIUS or an Active Directory
Server does not handle Email addresses and can therefore
not return this information.
f) Login levels
I do not see or understand the needs for an "untrusted
login", can you please explain it´s purpose - what do we
need it for?
Secure login: Good idea, but what do you mean with secure
connection? The usage of VPN or other secure connections
is out of OpenACS and therefore we can not check it. Or do
you mean the whole OpenACS access is handled using https?
g) Options
Some options like
- the fallback-option (Single-Sign-On)
- email any password change (Email account owner on
password change)
- login without explicit domain
- who´s online
are fine with me and should be implemented in the 1st
service contract implementation
h) Password hash
For the "local" domain it is accepted to encrypt the
password and to keep the encrypted password. Once a
"local" user logs in, hes/her cleartext password is
again encrypted and the result will be compared with
the stored one.
For the remote domains this does not make any sense. The
different authentication services are using different
encryption methods (and we do not want to implement all
these methods) and the drivers (PAM-RADIUS or PAM-(S)LDAP)
are transmitting the cleartext password for validation
checking - over secured connections to the auth servers.
i) Implementation list
Suggestion: Can we create and add an implementation list
like a menu so the service contractors can select the
items they need and want to get implemented?
The list itself may look like:
1) Authentication driver
a) via Unix (Linux, Solaris) PAM drivers for RADIUS
and LDAP access
b) via new OpenACS RADIUS and LDAP drivers
2) Account creation and update
a) through a batch job at regular intervals
b) dynamic at login request
....
n) Options
a) fallback to OpenACS accounts
b) Email notification on password changes
c) login without explicit domain
d) who´s online
.....
Regards, Michael