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

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

Paul and Mary,

I'm clear just about anytime next week after Monday morning (EDT). Why don't
you guys settle on a date and time, and I'll post in to ALF and take care of
the conference arrangements. There's another person here that I'd like to
have attend, but he can't make Friday at 12:30. We'll move our schedules
around to accommodate.

Cheers,
Joel 

-----Original Message-----
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx]On Behalf Of Paul Trevithick
Sent: Tuesday, September 20, 2005 5:20 PM
To: mary@xxxxxxxxxxxxxxxxx; Hawkins, Joel
Cc: 'Higgins (The Trust Framework) Project developer discussions'
Subject: RE: [higgins-dev] Possible Collaboration Point between Higgins
an dALF


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