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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
-- jesse mcconnell [EMAIL PROTECTED]
