You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by Jesse McConnell <je...@gmail.com> on 2006/09/02 04:29:15 UTC
rbac role/operation/permission example allocation
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
Re: rbac role/operation/permission example allocation
Posted by Jesse McConnell <je...@gmail.com>.
> 1) You can remove the index roles for a repo maintainer, since the
> index is global to the installation.
aye aye capt.
> 2) I'd rename "generate checksums" to regenerate or fix (probably fix)
thats cool, nothing in stone atm for them
> 3) what's toggle service?
I figured it might be handy to be able to take the site active or not
from a click of a button, sort of like 'This site is down for
maintanace redirect interceptor that an admin could have the
permission to set, just brainstorming a bit :)
> 4) what's download|add-metadata? Why is it different from the
> artifact? I'm thinking this might be more of an "edit POM" role,
> which I'd call just that.
no reason, just some examples really to help illustrate the operation concept
--
jesse mcconnell
jesse.mcconnell@gmail.com
Re: rbac role/operation/permission example allocation
Posted by Brett Porter <br...@apache.org>.
heres my thoughts, point form:
1) You can remove the index roles for a repo maintainer, since the
index is global to the installation.
2) I'd rename "generate checksums" to regenerate or fix (probably fix)
3) what's toggle service?
4) what's download|add-metadata? Why is it different from the
artifact? I'm thinking this might be more of an "edit POM" role,
which I'd call just that.
The rest sounds fine to me
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
Re: rbac role/operation/permission example allocation
Posted by Jesse McConnell <je...@gmail.com>.
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 <br...@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
Re: rbac role/operation/permission example allocation
Posted by Brett Porter <br...@apache.org>.
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