[alf-dev] SSO Discussion continued

["Kelly Shaw" <kshaw@xxxxxxxxxx>]

 All,

We received this on alf-dev, but I've had a request to post discussions like
this on the newsgroup as well. (Casual visitors to the ALF site may only
browse the newsgroup.) This posting comes from Govind Seshadri in response
to an action item he accepted to publish the results of his SSO findings.

Take a look and discuss.

shaw



Last week, we had discussed some potential SSO implementations that could be
included within ALF.

One promising contender that also happens to be in popular use currently is
the Central Authentication Service (CAS) from Yale
University(http://www.yale.edu/tp/auth/cas10.html). CAS provides SSO
(authentication) capability, it does not deal with authorization per se,
although it may be possible to extend CAS to send along role information for
authenticated principals.

The following whitepaper provides a clear explanation of how CAS implements
SSO and what applications have to do to enable SSO:
http://www.esup-portail.org/consortium/espace/SSO_1B/cas/eunis2004/cas-eunis2004-article.pdf

Both CAS and JOSSO allow for the storage of user information and credentials
within a central LDAP server or database.

However, if we are to provide SSO capabilities for ALF using CAS or JOSSO,
the architecture will be subject to the following constraints:

-All authentication for tools integrating within ALF will have to be handled
by the SSO server. The proprietary authentication mechanisms present within
the individual tools will have to be somehow disabled when they integrate
within ALF.

-The nature of SSO implies that there will be only one central repository
for user information and credentials, prefereably within an LDAP server. So,
any additions, modifications, etc. of user information and credentials will
have to be performed within this central store. The tools participating
within ALF will not maintain this information anymore.

-We may also have to look at maintaining the role mappings within the
central LDAP server and ensure that the SSO implementation propagates this
information accordingly.

-Each of the tools participating within the ALF will have to be modified in
some way to enable them to participate within the SSO framework. We will of
course have to ensure that any modification is minimally invasive.

While I think most of the above issues would apply in the implementation of
almost any ticket-based SSO system, it may be useful to focus the discussion
on whether any or all of the above mentioned constraints could be potential
show-stoppers. It they are, we may want to examine the feasability of
implementing a full fledged SSO system within ALF and examine alternative
approaches for user authentication.

Please share your thoughts on the matter.

Thanks,

Govind Seshadri
Cognizant Technology Solutions
govind.seshadri@xxxxxxxxxxxxx