archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse McConnell" <jesse.mcconn...@gmail.com>
Subject Re: plexus security components
Date Mon, 28 Aug 2006 14:39:13 GMT
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

Mime
View raw message