[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
