[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[alf-dev] FW: [higgins-dev] Possible Collaboration Point between Higgins an d ALF
I've taken the liberty of contacting Higgins on our behalf to see if we can
find some common ground wrt SSO (see thread below). They're response looks
favorable. I'd be happy to set up a conference for either of their two
dates. It'd be great if all concerned parties around SSO would join in. Does
anybody have a preference for dates?
From: Mary Ruddy [mailto:mary@xxxxxxxxxxxxxxxxx]
Sent: Friday, September 09, 2005 4:49 PM
To: Hawkins, Joel
Subject: RE: [higgins-dev] Possible Collaboration Point between Higgins
Thank you for making the outreach. We do believe that the work we are
doing with Higgins could be used as a basis for delivering SSO across
multiple tools (or contexts) as we call them. It sounds like our two
groups should be talking to determine what might make sense. After
taking a quick look at your schedule for architectural planning, would
it work for you to have an introductory conference call sometime on
Wednesday the 14th or Friday the 16th? Let us know what could work for
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Hawkins, Joel
Sent: Friday, September 09, 2005 8:49 AM
Subject: [higgins-dev] Possible Collaboration Point between Higgins and
My company is looking at contributing to the ALF project, and one of the
areas we're interested in is a single sign-on/authorization capability.
attached the following thread from the ALF-dev list in hopes of sparking
some collaboration between the two teams. From the ALF side, I believe
Higgins is the right way to deliver a SSO/Authorization solution for use
disparate tools. The security facet concept appears to be tailor-made,
Higgins by all rights should emerge as the solution for dealing with
security within Eclipse. From the Higgins side, I think ALF would
ready-made delivery vehicle for driving adoption within the Eclipse
community. Would you guys be interested in working aligning our efforts?
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
Behalf Of Brian Behlendorf
Sent: Thursday, September 08, 2005 10:56 PM
To: ALF Developer Mailing List
Subject: Re: [alf-dev] Re: Requirements for ALF SSON
This is a very interesting conversation for me. CollabNet found
implementing a ton of auth-n and auth-z logic to build a collaboration
platform that we were astonished wasn't done well enough by others - and
we're clearly not alone, as it seems like every multi-user application
there has its own model for storing user information and permissions,
simple name/password auth using LDAP or some other system. That's
that makes it difficult to integrate multiple apps into a suite of
I'm not entirely caught up on the history of this issue within this
yet, so apologies if this is ground already covered, but this triggered
few thoughts I'd share:
* SSO doesn't necessarily mean that there is only one protocol for doing
authentication (authn) or authorization (authz). Different tools will
different protocols - some will use SOAP apis, some will be web-based
will have their own protocols (CVS and Subversion I assume are part of
picture), etc. LDAP might be just one of many different protocols such
tool could use, but it can not be the only one. If my client-side
AJAX-based project management tool is making some sort of SOAP call to a
server somewhere, it's got to carry something that validates it - either
Kerberos-style auth token or the name/password combination itself.
an attribute of the network connection and thus must be embedded within
protocol; authz is an attribute of the user's profile once identified by
* It seems like many SSO systems lack any sense of authz, which is
to any multi-user productivity tool. To be useful, authz needs to talk
about more than just a particular capability an individual might have -
needs to talk about that capability within some context. In CollabNet's
environment, that means a project-by-project granularity to the
and in some cases going further - such as the ability to modify .c files
not the .h prototype definitions in a given project.
The authz system needs to be able to answer the question: "is the user
allowed to perform this action on this resource in this project?". The
answer can be binary. For performance (since perm checks can be
on big lists of things), it has to also be able to ask "What actions are
allowed by this user in this project?" and "What resources within this
project can this user perform this action on?"
* The ability to provide this level of granularity, and then being able
summarize these functions up into roles that can be granted to groups of
users across projects (or categories of projects, or projects with
subprojects, etc) has been cited by CollabNet's customers as a key
differentiator with competitors. However, CollabNet is not in the
business and we'd much rather see this kind of thing be defined as an
standard and implemented as an open source library. I've got to believe
we're not the first to have done this, but keep coming across protocols
APIs that either don't come close (JAAS and JACC) or are way too
(WS*). I personally could see this ALF effort being a means to arrive
standard and implementation for this, at least in the context of
tools, which is our real business. At the very least I hope to tap into
others here who have explored this space and perhaps found an authz
protocol/model that actually works.
* Tools need to be able to register new permissions with the SSO server.
That way you can have one UI to configuring roles and permissions across
whole integrated environment. The SSO server might relay all auth-n
requests behind-the-scenes to another system, such as an LDAP server,
should itself manage the authz information, and optionally group
* Developer communities in enterprise environments often include
stakeholders who are not employees of the main sponsoring organization.
The design for the SSO server might want to anticipate being able to
different auth-n back-ends based on a regex - so that users whose
end with "@domain.com" are auth-n'd against the domain.com LDAP server,
while others have their password information maintained locally within
I can't participate on Monday's call (prior commitments) but I am
this list/newsgroup. I am not yet committing CN resources to Eclipse
but I'm starting to see how and where we might.
On Wed, 7 Sep 2005, Mini Govind wrote:
> 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:
> 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.
> Govind Seshadri
> Cognizant Technology Solutions
alf-dev mailing list
The contents of this e-mail are intended for the named addressee only.
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or
it to anyone else. If you received it in error please notify us
and then destroy it.
higgins-dev mailing list
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.