archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenney Westerhof <ken...@apache.org>
Subject Re: plexus security components
Date Mon, 28 Aug 2006 12:31:49 GMT


Brett Porter wrote:
> This all sounds good. Here are my thoughts on potential roles we'll want:
> 
> * Administrator - the one that can change the managed repositories, 
> location of index, etc.
> * Repository maintainer - can perform quick fixes repository wide
> * Repository observer - can see the reports on the repository
> * Project maintainer - can perform quick fixes on their project, upload 
> new artifacts, delete artifacts, etc.
> * Project observer - can download artifacts from a given project
> 
> "Project" can be controlled by group ID hierachy. That means we could 
> potentially give out org.apache rights to some, and org.apache.maven 
> rights to others.
> 
> Is that enough for now? Default setup would be that the observer roles 
> are open to anyone.
> 

This initial/default role distribution is fine, but from my experience you'd want 
to use some permission system: each action checks if the current user can perform
that action (checking for instance a 'delete-user' permission). These permissions
can be assigned to roles or groups or whatever. That way you have maximum flexibility
in assigning separate permissions to different roles. If you have the role names
harcoded there'll always be somebody requiring a new role with a mixed set
of permissions that doesn't exist. 

I'm not sure if this is how it's going to be implemented, and it might be a little
bit of overkill for continuum, but if there's going to be a generic authentication/autorization
API this is definitely something I'd want.


> Are the roles to be hierachical or grouped in anyway? For example, I'd 
> like to say someone is an administrator so they have all the above 
> roles. I think we discussed doing that through groups before.
> 

I'd go for hierarchical groups too.

-- Kenney

> - Brett
> 
> On 26/08/2006, at 8:01 AM, Jesse McConnell wrote:
> 
>> 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