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

["Mary Ruddy" <mary@xxxxxxxxxxxxxxxxx>]

Joel,

Good to hear from you.  I'm traveling this Wednesday (Eclipse marketing
meeting), but Friday early afternoon should work for me and Paul
Trevithick. 

Paul,

What time on Friday afternoon would work for you?


Cheers,

Mary Ruddy  

-----Original Message-----
From: Hawkins, Joel [mailto:Joel.Hawkins@xxxxxxxxxxxxx] 
Sent: Tuesday, September 20, 2005 9:05 AM
To: 'mary@xxxxxxxxxxxxxxxxx'
Cc: higgins-dev@xxxxxxxxxxx
Subject: RE: [higgins-dev] Possible Collaboration Point between Higgins
an d ALF


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.