archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse McConnell" <je...@codehaus.org>
Subject plexus security components
Date Fri, 25 Aug 2006 22:01:55 GMT
The following was prompted by this jira issue.

http://jira.codehaus.org/browse/MRM-137

Jason, Joakim and I had a couple of irc chats on or around #plexus and
this mail is hopefully going to serve as a summary for what we came up
with for this issue.  Trygve and I also kicked around parts of this in
the past as well.

First off we are going to flesh out a plexus-security component on
plexus that will address the lionshare of the work needed for this.
This will ensure that the solution is general enough to be easily
applied to any number of other applications.

A couple of our goals are:

* general component api that is useful for webapps, webservices, swing apps, etc
* seperation of concerns, authentication, authorization, user details,
all seperate components
* pluggable and extensible user management

The idea here being that authentication is strictly a 'Yes' or 'No'
activity, authorization is a completely different 'Yes' or 'No'
activity and user management is a third intimately related part of the
puzzle.  These are mostly linked together through the use of some
principle id, commonly a username or userId.  The authorization and
authentication api's can further be influenced by the data pertaining
to a user, which jason coined the example of 'its your birthday, you
can't work today so you can't login' which illustrates that nicely I
think.

For this first pass through the problem we figure we'll hammer out the
module layout in plexus-security in the plexus sandbox and implement
the top lvl api's for the authentication, authorization and user
management bits.  Jason volunteered to do this to show how he was
thinking of doing the 'it's your birthday' dealio.  Joakim is going to
start bringing some of his maven-user bits and pieces that can be
generalized over into the suitable slots in plexus-security as well.
Once we have the basic api's on how all these things will work
together we can start in on the implementations with archiva being a
good first test subject. :)

At least initially we are thinking that we can use acegi as an
authentication store since they have a whole variety of different
solutions implemented that we can wrap up pretty easily.  Ideally
we'll have these different authentication solutions available in bean
form that we can wrap up into seperate small modules at a later date,
but for the time being we can easily use acegi for authentication
stores, I did that already to a certain degree with some previous work
I did in plexus.

Authorization will be an rbac implementation backed by a data model
that we can pull from some academic papers on the topic.  We have
poked around a little and haven't found many implementations of rbac
that we can really grab and wrap, but the fundamental concepts of it
are pretty straight forward and we can get a working rbac
implementation in a matter of days.  With a model we can easily
populate it from a variety of places, xml, jdo, etc.

User management is a big component of this, and we enivisioned it
covering all manner of things including editing user information,
recovering passwords, even assigning roles to users if that is the
case.  All of these things will be encapsulated into the api for the
user management modules and then we'll implement a couple of different
ui's to massage this data, most likely including a set of webwork
actions and basic jsp's suitable for embedding into a users
application.

The various components for these different concerns will be able to be
wired into any components needed, into jsp tags, application
components required to do security checks, etc.  They will be usable
as any other plexus component.

So with all these bits and pieces in play the story for the user of
these components would go some thing like this.

* choose your authentication store, authorization store and user
management implementation
* for rbac authorization usage, decide on the permissions that you
want, the roles that permissions are assigned to and get this data
loaded into the model.  perhaps through some small webapp we provide
or something, or just an xml file to start out with
* incorporate the user management functionality into whatever webapp
implementation you are using, for webwork like with archiva I can see
this being done easily with something like the following which would
provide easily embedded views as these actions can declare a default
jsp to render just that action with, or be overridden by the user.

<ww:action name="user" id="summary" namespace="security" executeResult="true">
   <ww:param name="userId" value="%{user.id}" />
 </ww:action>

* wire the relevent security components into their applications
wherever they may need them, the authentication component into their
authenticator action, authorization into lower lvl objects etc.

The important thing here that we liked when talking this over was that
authentication, authorization, and user details type activities were
discrete and seperate components in the picture, able to be picked and
chosen easily by the user yet still work for things like the birthday
login case.  Anyway, jason, joakim and myself put this together and I
am sure they'll add to this summary...

jesse

-- 
jesse mcconnell
jesse.mcconnell@gmail.com

Mime
View raw message