Forum OpenACS Development: Re: RFC: External Authentication

Hi Lars,

Looking excellent. Thoughts and suggestions below. I apologize in advance for the length 😊

Terminology: I think Authority is much more descriptive than Domain. When a person logs in, they are saying, "I am Telly Monster". OpenACS asks them to prove it. When the driver forwards the username and password, they are forwarding it to a system that is authoritative about who is Telly Monster and who isn't.

Login screen: I see the benefits of the way you did it. Namely, everything is explicit and there's no need for guesswork. The user logs in with their username and, in theory, need not have an email address (some customers seem to care about this). Here's an alternative:

  What is your e-mail address? (text box)
  Have you logged in to Sesame Street Intranet before?
    No, I am a new user.
    Yes, my password is: (text box)
Submit

For new users, we link them to a form where they can specify their authority (using friendly prompts such as "I have an MIT login" instead of "kerberos.mit.edu") and input their username. Once they've authenticated, we can try to pull their profile information, ask them to verify it, and create the new local account. From then on, the user logs in with their email address, which gets translated to a username on the backend before calling the authenticator.

This should solve the problem that you mentioned about existing accounts with the same email address. The only real down side here is that the "username != email" adherents will be unhappy because we require an email address.

Account creation and password management: I wouldn't go too nutty with these in the early stages. It may actually be desirable, as a matter of policy, to forward the user on to a central system, just to be sure that they understand that their changes will propagate beyond the OpenACS instance they happen to be working in.

auth::authenticate -username -domain -password -secure:boolean

is that it assumes that you will always use a username and password. But we also know that other methods exist, such as the redirection-based systems (CAS and Passport) and client certificates. Hence the ad-hoc "login using CAS" button on your form. Still, this function is useful for password-based login and so should sit on any login page presented by the system.

To handle the more general case, in an ideal world we would replace the calls like this

set user_id [ad_conn user_id]

and this

ad_maybe_redirect_for_registration

with a single, service-contract-backed call that looks like this

set user_id [auth::get_user_id -require_valid_user:boolean]

Based on a configurable policy, this function could choose between using an OpenACS cookie, a client certificate, redirecting to a local sign-in page over HTTP or HTTPS, or redirecting to a central (e.g. CAS) sign-in page.

The down side, of course, is that making a change like this would require touching virtually every page in OpenACS. Ouch, probably not a weekend project. Still, this is my current thinking on the issue and I thought it was at least worth mentioning.

Security: There's something broken about having a middleman (e.g. OpenACS) between the user and the authority. Consider the Kerberos example, where we send our username and password over (hopefully) HTTPS and let OpenACS handle the actual Kerberos authentication. From a security pov, what we've done is to assert that a) HTTPS is an acceptable stand-in for Kerberos, and b) we trust the operators of the OpenACS instance to require HTTPS and implement it correctly.

I find this problematic but don't yet have the solution sketched out. I've written some code for another system that checks for HTTPS and tries to discourage the user from entering remotely-checked passwords if HTTPS is not present. What we probably need, long term, is a vocabulary for talking about trust levels, and a way for the various drivers to advertise their requirements (i.e. "I only accept passwords transmitted over 128-bit HTTPS or better").