Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: continuum-dev@maven.apache.org
Received-SPF: pass (asf.osuosl.org: domain of jesse.mcconnell@gmail.com
 designates 64.233.182.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=CTvbjxNox9XCh2Ro1yyMJnGyeMmuGH0VAiiHTH5nO5FWWQBeukJvXzhtslREFgMx20f4yKvBRxAAZcR3RtPiMgZx/oN+lviwIUem3CbjTdnXYHtddSAG0D57z9vMB+RfiPZlf08A9SRHMPfsPD8ZaWIDvbmTnjNeETd6RH4UvBs=
Message-ID: <a43524d00607261425p500d3f7ap70f06885ea04bf73@mail.gmail.com>
Date: Wed, 26 Jul 2006 16:25:17 -0500
From: "Jesse McConnell" <jesse.mcconnell@gmail.com>
To: continuum-dev@maven.apache.org
Subject: Re: Continuum Security design
In-Reply-To: <a43524d00607191306o130db382wdbbe0c8a8f670353@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1a5b6c410607101541h7cf24c9di2d436672f4398593@mail.gmail.com>
	 <44BDAF67.2040109@apache.org>
	 <a43524d00607191306o130db382wdbbe0c8a8f670353@mail.gmail.com>

I have been working on a little security api in the plexus sandbox
that I wanted to describe to the continuum dev list that would work
for the implementation of the authentication and authorization parts
of continuum.

I like it since it is pretty easy to use and should extend to support
the zones ideas we have been describing in some of these discussions
on irc and on this mailing list.

Basically its an object called a PlexusSecurityRealm that is
configured in the components.xml to have an AuthenticationStore and an
AuthorizationStore.  These stores have one method each called
authenticate( tokenMap ) and authorize( session, tokenMap ).  The PSR
has some convience methods for working with these so you can call
things like isAuthentic( tokens ) or isAuthorized( session, tokens ).

I made a simple implementation of both stores and then an acegi
authentication store as well so far.  The acegi authentication store
is nice in that it is also all configured in the components.xml file
and can link up to whatever acegi can for authentication purposes.

Now the authorization side of the fence is a little more murky.  I am
really trying to seperate out the authentication process,
authorization process and the gathering if user details and stuff.
Acegi implementation really binds the authentication and authorization
concepts together which makes it difficult to wrap them up as distinct
seperate components.  I have an Object in that AuthenticationResult
object that is returned from the authentication store where we can
shove the acegi authentication object and the authorization store can
make use of that.

I think the real big decision that needs to be made in regards to
continuum and authentication/authorization is how implementation
specific do we want to go?

Acegi has a whole host of fun little bells and whistles but they are
peppered all through your code or are injected in the flow of things
through web filters and the like.  This lets you do fun little things
like secure all the user management code behind a particular url, say
**/users/*, with a particular role or something.  It provides some
taglibs for optionally rendering page content based on roles.  It also
has a pretty strong aop integration that lets you manage security of
objects in your codebase without actually modifying any of your code.

My thinking on the matter was more along the lines of letting whatever
object in the system, be it webwork rendering, data objects, or flow
control to be able to have one object that they could ask isAuthentic(
X ) and/or isAuthorized( X ) and react accordingly and let all the
howto mumbo jumbo be configured in other components.  Plexus would
basically manage all the nuts and bolts of what to authenticate to and
authorize on and the application code would just ask the questions
itself.  This has the benefit of readability but probably isn't as
nimble an idea as the aop bits of acegi.

does anyone have any feelings one way or the other on this?

jesse


On 7/19/06, Jesse McConnell <jesse.mcconnell@gmail.com> wrote:
> There was some discussion on irc about the security model so I wrote
> up this description for review by everyone.
>
> http://docs.codehaus.org/display/CONTINUUM/Straight+Role+Based+Access+Control
>
> It doesn't have implementation details in it, it is just an attempt at
> drawing together the different concepts we have been talking about
> together so we can agree on 'what we want' and then we can focus on
> 'how to do it'.
>
> personally, I think this basic idea could go into plexus (if it isn't
> already there with jason's rbac stuff) pretty smoothly and then have
> different implementations like carlo's acegi stuff...
>
> but anyway, please review the above and comment
>
> cheers!
>
> jesse
>
> On 7/18/06, Brett Porter <brett@apache.org> wrote:
> > I've added my comments.
> >
> > I don't think we need domain ACLs - it's an interesting concept but it
> > also worries me a little to have security as an afterthought - it's
> > intrinsic to the design of the code in some ways (surely if you only
> > want to give one person access to a subset of the data you also want to
> > avoid going ahead and retrieving the data in the first place). Perhaps I
> > misunderstand it's intent.
> >
> > So, where are we at with this? I don't think its healthy to keep a
> > branch for too long on something so fundamental as it'll become hard to
> > merge back in, but is Acegi proving to be both non-intrusive and capable
> > of doing what we need? What state is it in?
> >
> > - Brett
> >
> > On 11/07/2006 8:41 AM, Carlos Sanchez wrote:
> > > http://docs.codehaus.org/display/CONTINUUM/Security
> > >
> > > Please take a look and provide feedback on the semantics of what to
> > > secure and to what level.
> > >
> >
> >
> > --
> > Apache Maven - http://maven.apache.org/
> > Better Builds with Maven - http://library.mergere.com/
> >
>
>
> --
> jesse mcconnell
> jesse.mcconnell@gmail.com
>


-- 
jesse mcconnell
jesse.mcconnell@gmail.com