archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse McConnell" <jesse.mcconn...@gmail.com>
Subject rbac role/operation/permission example allocation
Date Sat, 02 Sep 2006 02:29:15 GMT
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
jesse.mcconnell@gmail.com

Mime
View raw message