Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[alf-dev] Re: SSO Discussion continued

If you folks are talking about SSO, security and identity why are you not 
talking to the Eclipse trust project? This post is intended to introduce the 
ALF team to the Higgins team in the hope that some re-use can occur across 
the two projects.

/mike

"Kelly Shaw" <kshaw@xxxxxxxxxx> wrote in message 
news:dfpsec$lu7$1@xxxxxxxxxxxxxxxx...
> 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
>
> 




Back to the top