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
