RE: [higgins-dev] Possible Collaboration Point between Higgins an d ALF

["Hawkins, Joel" <Joel.Hawkins@xxxxxxxxxxxxx>]

Mary,

My apologies for not getting back to you last week. Could we possibly
schedule some time this week to discuss how Higgins and ALF could work
together? Wednesday or Friday afternoons (EDT) work best for me. 

Cheers,
Joel Hawkins

-----Original Message-----
From: Mary Ruddy [mailto:mary@xxxxxxxxxxxxxxxxx]
Sent: Friday, September 09, 2005 4:49 PM
To: Hawkins, Joel
Cc: higgins-dev@xxxxxxxxxxx
Subject: RE: [higgins-dev] Possible Collaboration Point between Higgins
and ALF


Hello ALF!

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
you.   

>From 

Cheers,

Mary Ruddy
SocialPhysics.org
mary@xxxxxxxxxxxxxxxxx

-----Original Message-----
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Hawkins, Joel
Sent: Friday, September 09, 2005 8:49 AM
To: 'higgins-dev@xxxxxxxxxxx'
Subject: [higgins-dev] Possible Collaboration Point between Higgins and
ALF

Hello Higgins! 

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.
I've
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
by
disparate tools. The security facet concept appears to be tailor-made,
and
Higgins by all rights should emerge as the solution for dealing with
security within Eclipse. From the Higgins side, I think ALF would
provide a
ready-made delivery vehicle for driving adoption within the Eclipse
community. Would you guys be interested in working aligning our efforts?

Cheer,
Joel Hawkins
Compuware Corporation
joel.hawkins@xxxxxxxxxxxxx

From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On
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
ourselves
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
out
there has its own model for storing user information and permissions,
beyond
simple name/password auth using LDAP or some other system.  That's
insanity
that makes it difficult to integrate multiple apps into a suite of
cooperating tools.

I'm not entirely caught up on the history of this issue within this
project
yet, so apologies if this is ground already covered, but this triggered
a
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
have
different protocols - some will use SOAP apis, some will be web-based
tools
that use HTTP auth, others will be web-based tools that use cookies,
some
will have their own protocols (CVS and Subversion I assume are part of
the
picture), etc.  LDAP might be just one of many different protocols such
a
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
a
Kerberos-style auth token or the name/password combination itself.
Authn is
an attribute of the network connection and thus must be embedded within
the
protocol; authz is an attribute of the user's profile once identified by
the
authn process.

* It seems like many SSO systems lack any sense of authz, which is
critical
to any multi-user productivity tool.  To be useful, authz needs to talk
about more than just a particular capability an individual might have -
it
needs to talk about that capability within some context.  In CollabNet's
environment, that means a project-by-project granularity to the
permissions,
and in some cases going further - such as the ability to modify .c files
but
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
expensive
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
to
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
authn/z
business and we'd much rather see this kind of thing be defined as an
open
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
and
APIs that either don't come close (JAAS and JACC) or are way too
complicated
(WS*).  I personally could see this ALF effort being a means to arrive
at a
standard and implementation for this, at least in the context of
developer
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
the
whole integrated environment.  The SSO server might relay all auth-n
requests behind-the-scenes to another system, such as an LDAP server,
but
should itself manage the authz information, and optionally group
membership
information.

* 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
handle
different auth-n back-ends based on a regex - so that users whose
usernames
end with "@domain.com" are auth-n'd against the domain.com LDAP server,
while others have their password information maintained locally within
the
SSO server.

I can't participate on Monday's call (prior commitments) but I am
following
this list/newsgroup.  I am not yet committing CN resources to Eclipse
ALF,
but I'm starting to see how and where we might.

 	Brian

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:
> 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
>
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev





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. 

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev



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.