OpenACS 4 Permissions Requirements

-by John McClary Prevost
+OpenACS 4 Permissions Requirements

Prev	Chapter�10.�Kernel Documentation	Next

OpenACS 4 Permissions Requirements

By John McClary Prevost

OpenACS docs are written by the named authors, and may be edited by OpenACS documentation staff. -

Introduction

This document records requirements for the OpenACS 4 Permissions system, a +

Introduction

This document records requirements for the OpenACS 4 Permissions system, a component of the OpenACS 4 Kernel. The Permissions system is meant to unify and centralize the handling of access and control on a given OpenACS 4 system.

Vision Statement

Any multi-user software system must address the general problem of permissions, or "who can do what, on what." On web services, which @@ -47,7 +46,7 @@ perform. If "foo" is an operation, than we sometimes refer to the foo "privilege" to mean that a user has the privilege to perform that operation.

Examples of the essential question addressed by the Permissions system: -Can jane@attacker.com delete the web security bboard? Can the Boston office +Can jane@attacker.com delete the web security forum? Can the Boston office (a party) within the VirtuaCorp intranet/website create its own news instance?

Functional Requirements

10.0 Granularity

The system must support access control down to the level of a single entity (this would imply down to the level of a row in the OpenACS Objects data @@ -59,7 +58,7 @@ may party P perform operation O?"

Behavioral Requirements

40.0 Scale of Privileges

Privileges must be designed with appropriate scope for a given OpenACS package. Some privileges are of general utility (e.g. "read" and "write"). Others are of more limited use (e.g. "moderate" -- applies mainly to a package like bboard, where many users are contributing +- applies mainly to a package like forum, where many users are contributing content simultaneously). A package defining its own privileges should do so with moderation, being careful not to overload a privilege like "read" to mean too many things.

50.0 Aggregation of Operations (Privileges)

For user interface purposes, it can be appropriate to group certain @@ -70,11 +69,11 @@ system. Regardless of the exact behavior of aggregate parties, if an aggregate party exists, then access which is granted to the aggregate party should be available to all members of that aggregate.

70.0 Scope of Access Control

70.10 Context
There must be a method for objects to receive default access control from -some context. For example, if you do not have read access to a bboard, you -should not have read access to a message in that bboard.

70.20 Overriding
It must be possible to override defaults provided by the context of an +some context. For example, if you do not have read access to a forum, you +should not have read access to a message in that forum.

70.20 Overriding
It must be possible to override defaults provided by the context of an object (as in 70.10), in both a positive and negative manner.

70.20.10 Positive Overriding
It must be possible to allow a party more access to some target than they would get by default. (For example, a user does not have the right to edit -any message on a bboard. But a user does possibly have the right to edit +any message on a forum. But a user does possibly have the right to edit their own messages.)

70.20.20 Negative Overriding
It must be possible to deny a party access to some target that their inherited privileges would have allowed. (For example, a subdirectory in the file-storage might normally have its parent directory as context. It should