| Re: SSO Discussion continued [message #936] |
Fri, 09 September 2005 22:05  |
 Mike Milinkovich
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
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@serena.com> wrote in message
news:dfpsec$lu7$1@news.eclipse.org...
> 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/eun is2004/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@cognizant.com
>
>
|
|
|
| Re: SSO Discussion continued [message #966 is a reply to message #936] |
Sun, 11 September 2005 18:51  |
Eclipse User |
|
|
|
Originally posted by: mary.socialphysics.org
Mike,
Thanks very much for the introduction. The Higgins team has received an
outreach from ALF and we are very interested in talking with them about we
can best coordinate.
|
|
|
|
Powered by
FUDForum. Page generated in 0.03391 seconds
] 
Search
Help
Register
Login
Home
