|Re: SSO Discussion continued [message #936]
||Fri, 09 September 2005 22:05
| Mike Milinkovich
Registered: July 2009
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.
"Kelly Shaw" <email@example.com> wrote in message
> We received this on alf-dev, but I've had a request to post discussions
> 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.
> Last week, we had discussed some potential SSO implementations that could
> included within ALF.
> One promising contender that also happens to be in popular use currently
> 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
> authenticated principals.
> The following whitepaper provides a clear explanation of how CAS
> SSO and what applications have to do to enable SSO:
> http://www.esup-portail.org/consortium/espace/SSO_1B/cas/eun is2004/cas-eunis2004-article.pdf
> Both CAS and JOSSO allow for the storage of user information and
> 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
> by the SSO server. The proprietary authentication mechanisms present
> 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.
> any additions, modifications, etc. of user information and credentials
> 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
> some way to enable them to participate within the SSO framework. We will
> course have to ensure that any modification is minimally invasive.
> While I think most of the above issues would apply in the implementation
> almost any ticket-based SSO system, it may be useful to focus the
> on whether any or all of the above mentioned constraints could be
> 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.
> Govind Seshadri
> Cognizant Technology Solutions
Powered by FUDForum
. Page generated in 0.06381 seconds