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