Permission Model based on data

[Jean Barmash <je...@gmail.com>]

Hello,

I am building an app with a relatively complicated authorization
requirements.To give a basic summary of requirements - I am building
an app to manage renovation projects on sets of buildings (i.e.
rebranding efforts on bank branches, energy retrofits, etc).

When a user logs in, he or she will have access to projects they are a
part of, and when they go to building list page, they will see all the
buildings related to projects they are a part of.  Other users may
need to have access to individual buildings only (i.e. property
managers, supers, architects).  Also, I want to designate some users
as administrators for their particular project, so they can manage
user access to the buildings.

On top of that, there are other pieces of functionality that I will
want to enable / disable in the future (i.e. whether a user has
workflow privileges, upload files, etc), or access to while areas of
the site on per user basis.

I am trying to figure out how to lay out my permissions.  I am still
getting familiar with SHIRO, but am thinking of modeling my
permissions as WildCardPermission with:

"Project ID or Name:DomainObjectName(Building, Program)
:Operation(edit, create, workflow, etc):DomainInstanceID"

I think by adding project name / id into my wildcard, that would allow
me to authorize somebody to have, say, read access to all buildings in
a specific project.   Any time I create a new project, I could then
create several roles for each project so they could be assigned to
users, i.e. ProjectX_ADMIN, ProjectX_Viewer, ProjectX_Editor, etc.
The admin would have permissions "ProectX:*:*:*" - all permissions for
project X.

Does the above make sense?   Any feedback is welcome - I've seen a
bunch of examples of restricting actions of a user based on their
role, but it seems like I have another layer of complexity here.

Thanks,


Jean

Re: Permission Model based on data

[Les Hazlewood <lh...@apache.org>]

I agree with Peter - it will also probably reduce the total number of
saved permissions in the system, and this is a good thing - the fewer
assigned permissions there are, the fewer there to consult each time a
permission check occurs at runtime.

But to be clear - coding your application to use permission checks is
almost always better than using role or group checks - if you can
dynamically add or delete roles or groups at runtime, you must use
permission checks.  Plus because permissions describe raw
functionality, they are self-documenting and only need to change when
your application's functionality changes.  And there is little to no
interpretation as to what is required when programming to permission
checks.

HTH,

Les

On Wed, Oct 28, 2009 at 6:09 AM, Peter Ledbrook <pe...@cacoethes.co.uk> wrote:
>> "Project ID or Name:DomainObjectName(Building, Program)
>> :Operation(edit, create, workflow, etc):DomainInstanceID"
>
> Sure, that works.
>
>> I think by adding project name / id into my wildcard, that would allow
>> me to authorize somebody to have, say, read access to all buildings in
>> a specific project.   Any time I create a new project, I could then
>> create several roles for each project so they could be assigned to
>> users, i.e. ProjectX_ADMIN, ProjectX_Viewer, ProjectX_Editor, etc.
>> The admin would have permissions "ProectX:*:*:*" - all permissions for
>> project X.
>
> Consider modifying your realm so that some roles have an associated
> project ID or name. The original DB realm for the Grails JSecurity
> plugin was modelled in this way, with a relation table between users
> and roles that contained the project ID (or anything else you wanted).
> I think that would be safer in the long run than embedding the project
> ID in the role name.
>
> Cheers,
>
> Peter
>

Re: Permission Model based on data

[Peter Ledbrook <pe...@cacoethes.co.uk>]

> "Project ID or Name:DomainObjectName(Building, Program)
> :Operation(edit, create, workflow, etc):DomainInstanceID"

Sure, that works.

> I think by adding project name / id into my wildcard, that would allow
> me to authorize somebody to have, say, read access to all buildings in
> a specific project.   Any time I create a new project, I could then
> create several roles for each project so they could be assigned to
> users, i.e. ProjectX_ADMIN, ProjectX_Viewer, ProjectX_Editor, etc.
> The admin would have permissions "ProectX:*:*:*" - all permissions for
> project X.

Consider modifying your realm so that some roles have an associated
project ID or name. The original DB realm for the Grails JSecurity
plugin was modelled in this way, with a relation table between users
and roles that contained the project ID (or anything else you wanted).
I think that would be safer in the long run than embedding the project
ID in the role name.

Cheers,

Peter