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

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

Mary and Joel,

On Friday afternoon EST I could do between 12:30-1:30 pm or after 5pm. I
usually am more flexible, but I have some errands/driving that afternoon.
Next Mon afternoon PST I could be available too (I'll be in the SanFran area
then).

-Paul
my cell: 617 513 7924

> -----Original Message-----
> From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Mary Ruddy
> Sent: Tuesday, September 20, 2005 9:53 AM
> To: 'Hawkins, Joel'
> Cc: higgins-dev@xxxxxxxxxxx
> Subject: RE: [higgins-dev] Possible Collaboration Point between Higgins an
> dALF
> 
> 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.
> 
> 
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev