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: rbac role/operation/permission example allocation
Date Mon, 04 Sep 2006 00:08:33 GMT
basically that first bit are the roles that can be assigned to user on
a per repository or per project basis as indicated by the (per repo)
and (per project) tags.

below that are the operations that are inclosed in corresponding
permissions for that repo/project.

The roles were based off your previous mail on the topic, and the
operations I pulled out of your comments on potential roles.

So there are three core entities that can have permissions wrapped
around them, the administration of the application, each repository,
and each project.

jesse

On 9/3/06, Brett Porter <brett@apache.org> wrote:
> 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
> > jesse.mcconnell@gmail.com
>


-- 
jesse mcconnell
jesse.mcconnell@gmail.com

Mime
View raw message