Jesse,
I've got some other things to do so I'll review this properly
tomorrow, but I was wondering if you could explain the structure of
the information at the start?
- Brett
On 02/09/2006, at 12:29 PM, Jesse McConnell wrote:
Archiva
Administration Roles:
Administrator
* add-index
* regenerate-index
* remove-index
* modify-index
* toggle-service
Repository Roles (per repo):
Repository Observer
* view-reports
Repository Maintainer
* Repository Observer +
* generate-reports
* add-index
* remove-index
* modify-index
* regenerate-index
* generate-checksums
Project Roles (per project):
Project Observer
* download-artifact
* download-metadata
Project Maintainer
* Project Observer +
* add-artifact
* add-metadata
* remove-artifact
* remove-metadata
* modify-artifact
* modify-metadata
* generate-checksums
Operations:
add-index
regenerate-index
remove-index
modify-index
toggle-service [turn off service to the site for maintaince, etc]
view-reports
generate-reports
add-artifact
remove-artifact
modify-artifact
download-artifact
add-metadata
remove-metadata
modify-metadata
download-metadata
generate-checksums
REPOSITORY/PROJECTS:
RBAC does permission checks based on an object that a particular
operation is trying to be invoked for or on. To maintain obtain
common object
that is fine grained enough for use with archiva the idea is to use
a tuple of
repository and project to describe a particular object that an
operation is
being associated with. Note, the binding of an operation and an
object is a
permission and that permission is in turn associated with one or
more roles.
The use of a wildcard or keyword can be used to denote that a
particular
operation applies to all items that match the wildcard pattern.
The notation
for a permission is P(OPERATION, OBJECT). For example:
P( download-artifact, *-jpox );
This permission would grant the role the ability to download jpox
artifacts
from all repositories being managed.
P( generate-checksum, central-* );
This permission would grant the role the ability to generate
checksums for all
projects in the repository known as central.
P( generate-checksums, central-org.maven.apache.* );
This permission would grant the role the ability to generate
checksums for all
projects with a group id of at least org.maven.apache on the
central repository.
RBAC Administration:
While it is certainly possible to dynamically generate roles and
assoicate those
roles with permissions it is probably best at this point to attempt
to work out
a feasible list of jobs and link up the permissions appropriately.
We can
easily generate the project maintainer and project obverser roles
automatically
on the creation of a given project and the same goes for linking up
another
repository. It is simply a matter of knowing what the permission
assignments
are configured like for a given role and replicating the role as
needed and
tweaking the name accordingly.
When the time comes to dynamically modify permissions and roles the
interface
can be made quite simple, for example with the assigning of the
generate-checksums operation it could be two drop down boxes, the
first
containing [central, snapshots, all] and the second containing the
projects
[org, org.apache, org.apache.maven, jpox, jdo, junit, all]
Ultimately the point is that with RBAC great care is taken in
working out
structure of roles, permissions, and operations. The objects part
of the puzzle
is largely up the implementation and user of the system.
--
jesse mcconnell
[EMAIL PROTECTED]
