plexus security components

[Jesse McConnell <je...@codehaus.org>]

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

Re: plexus security components

[Jesse McConnell <je...@gmail.com>]

Well RBAC pretty much takes care of this, being a general
authorization system.  Let me see if I can do it justice here..

A user is pretty easy, its the biological or computational machine
that is using the system.

A role can be assigned to a user, multiple users can be assigned to a
role, and a role can be the parent to one or more roles.  Those child
roles gain all the permissions their parent have, the hierarchical
groups you were mentioning above.

An operation is something that can be performed on an object, reading
a file object, writing a file object, deploying an artifact to a
repository, etc.

A permission is assigned to a role and is what is required to
authorize the operation on some object.

So, an example of this working in archiva would be similar to:

* Brett is an authenticated user of archiva.
* Brett is assigned the role of Project Maintainer for the
'org.apache.maven' project
* Operations for project objects may include things like 'deploying,
removing, updating'.
* The Object that brett will be performing operations on is 'org.apache.maven'
* The Project Maintainer role for 'org.apache.maven' has permission to
perform the deploy and update operations.

Brett decided he wants to deploy a new snapshot for the
'org.apache.maven' project so when authorization is checked for this
activity the check for permission is made for the DEPLOY operation on
the 'org.apache.maven' OBJECT.  The Project Maintainer role gives the
P(DEPLOY, 'org.apache.maven') permission so this activity is
authorized.

Now multiple permissions might be required to actually complete this
activity, I could easily see that the Project Maintainer role might
need to exist for each repository being managed, and permissions would
be allocated such that that role has the ability to deploy something
to the repository in question.  These would be other permission checks
that would be made to authorize the particular behavior.  RBAC has a
concept for this as well called constraints, a constraint for the
deploy operation above might be that the user has permission to deploy
to the repository in question.

This is why we think rbac is a good solution for this, with a bit of
intelligence we can layout a role hierarchy that will make maintaince
a breeze, just click through some UI and grant the roles for
particular 'org.apache.maven' type projects to the relevant people.

Now this is an example of how it could work, its by no means the hard
and fast way it will be/should be implemented.

jesse

Re: plexus security components

[Kenney Westerhof <ke...@apache.org>]

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

Re: plexus security components

[Brett Porter <br...@apache.org>]

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.

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.

- 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