Aggregate Permissions and Principal Groups

Author

Problem

For a long time, we've struggled with the definition of permissions. We sometimes need fine-grained permissions (e.g. "Manage Foo", "Add Foo", "Manage Bar", "Add Bar", ...), but fine-grained permissions tend to yield permission systems that are unmanageable.

It seems desirable to aggregate permissions, allowing people to use the aggregate permissions, rather than individual permissions. To some degree, that's what we have with roles. We provided the separation of permissions and roles to separate the concerns of the site manager from the concerns of the programmer. Programmers defined and declared required permissions. Site managers decided which roles had which permissions and which users had which roles. A flaw with this approach is that we often want the programmer to help with the aggregation. But, if we allow the programmer to define roles, we lose the ability for the site manager to aggregate further.

Historically, another problem with Zope's role-permission system is that there were two ways to grant access:

Permissions can be granted to roles, and
Roles can be granted to principals

For a long time, it wasn't possible to grant roles to principals locally. Granting permissions to roles became the dominant way to grant access even though it was very cumbersome.

I've avoided any formal mechanism for aggregating permissions hierarchically, for fear that doing so would put an undue burden on the run-time authorization system. Recent work to employ caching during authorization makes more sophisticated models feasible, however.

Proposal

I propose, in some version of Zope higher than X3 3.0 to:

Introduce the idea of aggregate permissions. A permission can be aggregated into one or more aggregate permissions. An aggregate permission can be further aggregated. Cycles are not allowed.
Programmers and site managers can define both basic and aggregated permissions. Programmers can declare basic permissions required to access or modify attribute names. Only basic permissions can be used in these declarations.

When the security policy checks whether a principal has a permission on an object it will check to see if there is an "allow" grant for the permission:
- There is an allow grant for a permission if:
  - there is a direct allow grant or
  - there is not a direct deny grant and there is an indirect allow grant
- An object can't have both a direct allow grant and a direct deny grant.
- There is a direct allow grant if there is an allow grant on the object, including acquired grants. (Obviously, inner grants override outer grants, object-location-wise.)
- There is a direct deny grant if there is an deny grant on the object, including acquired grants.
- There is an indirect allow grant for a permission if there is an allow grant on any of the permission's parents.
Introduce the concept of principal groups
Principals can be arranged into groups. Groups will be treated much like principals. In particular, cycles are not allowed.

Principals (IPrincipal?) will get a new groups method. This method will return a principal's groups. There will be 2 standard pre-defined groups:

zope.Unauthenticated

Unauthenticated principals are in this group. It is up to an authentication service to decide whether an unauthenticated principal is in this group.

zope.Authenticated

Authenticated principals are in this group. It is up to an authentication service to decide whether an authenticated principal is in this group.

and a pseudo group:

zope.Everybody

All principals will be in this group implicitly. This group need not be included in the result of a principals groups method.
Provide a new security policy:
a. Do away with roles. With aggregated permissions, we don't need them.

b. For any permission, we can grant a permission and/or the authority to grant or deny a permission.
There will also be a permission for granting and denying all permissions.

It is only possible to grant or deny a permission if you have authority to grant or deny that permission or you have permission to grant or deny all permissions.

It is only possible to grant authority for a permission if you have authority for that permission or if you have the permission to grant or deny all permissions.

c. The granting UI will show only permissions for which a user has authority.

d. The granting UI will show available permissions hierarchically.
Provide a tool for converting current security-policy declarations to new-style declarations. In particular roles will be "converted" to aggregated permissions:
- There will be a tool for auditing the role-permission grants in the system. Generally, the permissions currently granted to a role will be aggregated to create the new permission.
- There will be a tool for converting principal-role grants to principal-permission grants.
Existing permission grants will still be usable. Coarse-grained permissions that we use today will become aggregated permissions.

Benefits

Allows greater control over aggregation of permissions
Simpler granting UI. Really only one kind of grant: permissions to principals (or groups)
I think this model will, ultimately be easier to understand.

comments:

sounds great --k_vertigo, 2004/07/25 06:45 EST reply
I'm a really big fan of this model, its much easier semantically to use, and to model real world organizations with, as well to reuse software with a different security model in mind (via permission aggregations). i outlined some more thoughts on a similar model in an email describing the openacs model

http://mail.zope.org/pipermail/zope3-dev/2003-December/009022.html

very nice ! --vds, 2004/08/03 04:44 EST reply
I like this approch very much!