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]
