continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlos Sanchez" <car...@apache.org>
Subject Re: Continuum Security design
Date Wed, 26 Jul 2006 22:05:18 GMT
I think is more important now come with a good representation of
users, groups, roles,... that can be used across all apps (Continuum,
MRM,...)

Acegi doesn't mess with your code, so the need of another api on top
of it for me has no much sense.

I like the aop approach better than implementing interfaces for the
same reason, it doesn't get in your way. You can secure anything
pretty easily. I have made some progress on this but other things
needed my attention, I'll have the integration bits ready soon.

On 7/26/06, Jesse McConnell <jesse.mcconnell@gmail.com> wrote:
> 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
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

Mime
View raw message