a follow-up to something from the ox-user list:

* Juergen Ulbts <j.ulbts at uni-oldenburg.de> [2007-02-28 14:54]:
> I'm not sure what is stored in LDAP beside the login information. This
> might require more work...I would move the login stuff to the existing
> Central Authentication Service (CAS), which was already on my TODO list
> for OX 0.8.2-x. I pushed that back because of the project task problem
> mentioned above.

integrating OX with Web Single Sign-On (SSO) oder ISO (initial sign
on) systems is an excellant idea. for people who are unfamiliar with
the concepts try googleing for CAS SSO, cosign weblogin, pubcookie or
shibboleth or start at http://middleware.internet2.edu/webiso/

the whole idea is that authentication is removed from the application
and delegated to the webserver (apache mostly, sometimes IIS or
servlet containers such as tomcat) which checks (via browser cookies,
usually) if the accessing user is already authenticated. if this is
the case, access to the application is permitted, passing the username
via apache's REMOTE_USER environment (no password will be passed to
the application). if not, a http redirect to the central weblogin
server is sent, and again back to the application one came from, after
successful authentication.

behind the scenes several cookies are set and checked, sometimes out
of band communication between the appplication and the weblogin server
take place, etc. (this varies with the implementation).
this is very secure and greatly reduces the number of services that
need to accept the user's password via some web form. this also
reduces the need to enter your username + password for every web
application you're using, providing for a better user experience.

a few notes on how this relates to OX:

- the login.pm will simply get $uid from $ENV{'REMOVE_USER'}, other
stuff just gets removed/commented out.

- the session daemon get's the user's name and password from login.pm
(base64 encoded) and uses it to authenticate the user to the directory
(or rather the database, in Hyperion, I suppose).  this would need to
be changed so that no passwd (or some replacement string) is passed to
the sessiond and the sessiond would need to be changed to *not*
authenticate to the direcory (or database), instead always returning
success (or just checking for the existance of the user record, not
actually authenticating).

- if the directory (ldap) or database requires authentication prior to
lookup of users attributes some proxy/service account (e.g. mailadmin)
should be used for binding and lookup, not the user trying to login
(since we don't have her password).
(I don't know how this is handled currently in OX.)

- I'm not sure about the rest of OX expecting username+password
(instead of only the username), but since there is the sessiond for
adding/checking/dropping sessions, this should be ok?

- a different logout URL would need to be generated, depending on the
WebSSO system used

- the webmail will be a problem (like any "n-tier" authentication)
because the OX server is just another IMAP client, passing username +
password through to the imapd). there are several ways to accomplish
this, none of them being easily and securly implemented and portable
to many different imap daemons (and their authentication modules;
saslauthd, pam, etc.).

ignoring the webmail problem for the moment: would anyone else see
problems with or gains in this approach?
provided authentication is still done via the sessiond in hyperion
chances are that changes for OX would also work with the new design?

is netline interested in shibboleth-enabling their application like
many others are doing currently?
https://wiki.internet2.edu/confluence/display/seas/Home
with the upcomming convergence of the SAML standards (shibboleth[1],
liberty[2] and others) this might become part of many companies' core
middleware and authentication infrastucure.

regards,
-p.schober

[1] http://shibboleth.internet2.edu/ or maybe http://switch.ch/aai/demo/
[2] http://www.projectliberty.org/
    http://www.projectliberty.org/index.php/liberty/strategic_initiatives/federation


-- 
peter.schober at univie.ac.at - vienna university computer center
Universitaetsstrasse 7, A-1010 Wien, Austria/Europe
Tel. +43-1-4277-14155, Fax. +43-1-4277-9140