| -Prev | -Chapter 7. Kernel Documentation | -Next - | -
|---|
-
This document records requirements for the OpenACS 4 Permissions system, a +
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.
-Any multi-user software system must address the general problem of +centralize the handling of access and control on a given OpenACS 4 system.
Any multi-user software system must address the general problem of permissions, or "who can do what, on what." On web services, which typically involve large numbers of users belonging to different groups, permissions handling is a critical need: access to content, services, and @@ -47,231 +15,80 @@ manner reduces both cost and risk: cost, in that less code has to be written and maintained for dealing with recurring permissions situations; risk, in that we need not rely on any single programmer's diligence to ensure -access control is implemented and enforced correctly.
-Historical Motivations
-In earlier versions of the OpenACS, permissions and access control was handled +access control is implemented and enforced correctly.
Historical Motivations
In earlier versions of the OpenACS, permissions and access control was handled on a module-by-module basis, often even on a page-by-page basis. For example, a typical module might allow any registered user to access its pages read-only, but only allow members of a certain group to make changes. The way this group was determined also varied greatly between modules. Some modules used "roles", while others did not. Other modules did all access control based simply on coded rules regarding who can act on a given database -row based on the information in that row.
-Problems resulting from this piecemeal approach to permissions and access +row based on the information in that row.
Problems resulting from this piecemeal approach to permissions and access control were many, the two major ones being inconsistency, and repeated/redundant code. Thus the drive in OpenACS 4 to provide a unified, consistent permissions system that both programmers and administrators can -readily use.
-The OpenACS 4 Permissions system has two main pieces: first, an API for +readily use.
The OpenACS 4 Permissions system has two main pieces: first, an API for developers to readily handle access control in their applications. The second piece of the system is a UI meant primarily for (subsite) administrators to -grant and revoke permissions to system entities under their control.
-Consistency is a key characteristic of the Permissions system - both for a +grant and revoke permissions to system entities under their control.
Consistency is a key characteristic of the Permissions system - both for a common administrative interface, and easily deployed and maintained access control. The system must be flexible enough to support every access model required in OpenACS applications, but not so flexible that pieces will go unused -or fall outside the common administrative interfaces.
-Terminology
-The primary question an access control system must answer is a three-way +or fall outside the common administrative interfaces.
Terminology
The primary question an access control system must answer is a three-way relation, like that between the parts of most simple sentences. A simple sentence generally has three parts, a subject, an object, and a verb - in the context of OpenACS Permissions, our simple sentence is, "Can this party -perform this operation on this target?" Definitions:
-The subject of the sentence is "party" - a +perform this operation on this target?" Definitions:
The subject of the sentence is "party" - a distinguishable actor whose access may be controlled, this special word is used because one person may be represented by several parties, and one party -may represent many users (or no users at all).
-The object of the sentence is "target" - this +may represent many users (or no users at all).
The object of the sentence is "target" - this is an entity, or object, that the party wishes to perform some action on. An -entity/object here is anything that can be put under access control.
-The verb of the sentence is "operation" - a behavior on the OpenACS +entity/object here is anything that can be put under access control.
The verb of the sentence is "operation" - a behavior on the OpenACS system subject to control, this word is used to represent the fact that a single operation may be part of many larger actions the system wants to 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: +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 (a party) within the VirtuaCorp intranet/website create its own news -instance?
-10.0 Granularity
-The system must support access control down to the level of a single +instance?
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 -model).
-20.0 Operations
-The system itself must be able to answer the essential permissions -question as well as several derived questions.
---20.10 Basic Access Check
-The system must be able to answer the question, "May party P perform -operation O on target T?"
-
--20.20 Allowed Parties Check
-The system must be able to answer the question, "Which parties may -perform operation O on target T?"
-
--20.30 Allowed Operations Check
-The system must be able to answer the question, "Which operations may -party P perform on target T?"
-
--20.40 Allowed Targets Check
-The system must be able to answer the question, "Upon which targets -may party P perform operation O?"
-
40.0 Scale of Privileges
-Privileges must be designed with appropriate scope for a given OpenACS +model).
20.0 Operations
The system itself must be able to answer the essential permissions +question as well as several derived questions.
20.10 Basic Access Check
The system must be able to answer the question, "May party P perform +operation O on target T?"
20.20 Allowed Parties Check
The system must be able to answer the question, "Which parties may +perform operation O on target T?"
20.30 Allowed Operations Check
The system must be able to answer the question, "Which operations may +party P perform on target T?"
20.40 Allowed Targets Check
The system must be able to answer the question, "Upon which targets +may party P perform operation O?"
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 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 +"read" to mean too many things.
50.0 Aggregation of Operations (Privileges)
For user interface purposes, it can be appropriate to group certain privileges under others. For example, anyone with the "admin" privilege may also automatically receive "read", "write", -"delete", etc. privileges.
-60.0 Aggregation of Parties (Groups)
-The system must allow aggregation of parties. The exact method used for +"delete", etc. privileges.
60.0 Aggregation of Parties (Groups)
The system must allow aggregation of parties. The exact method used for aggregation will probably be addressed by the OpenACS 4 "Groups" 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 +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 -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 +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 +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 -their own messages.)
--70.20.20 Negative Overriding
-It must be possible to deny a party access to some target that their +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 -be possible, however, to make a subdirectory private to some group.)
-100.0 Efficiency
-At least the basic access check (20.10) and the allowed targets check +be possible, however, to make a subdirectory private to some group.)
100.0 Efficiency
At least the basic access check (20.10) and the allowed targets check (20.40) must be efficient enough for general use, i.e. scalable under fairly heavy website traffic. It can be expected that almost every page will contain at least one basic access check, and most pages will contain an allowed -targets check (20.40).
-In particular, constraining a SELECT to return only rows the +targets check (20.40).
In particular, constraining a SELECT to return only rows the current user has access to should not be much slower than the SELECT -on its own.
-120.0 Ease of Use
-Since most SQL queries will contain an allowed target check in the where +on its own.
120.0 Ease of Use
Since most SQL queries will contain an allowed target check in the where clause, whatever mechanism is used to make checks in SQL should be fairly -small and simple.
-In particular, constraining a SELECT to return only rows the -current user has access to should not add more than one line to a query.
-| Document Revision # | -Action Taken, Notes | -When? | -By Whom? | -
| 0.1 | -Creation | -8/17/2000 | -John Prevost | -
| 0.2 | -Revised, updated with new terminology | -8/25/2000 | -John Prevost | -
| 0.3 | -Edited, reformatted to conform to requirements template, pending -freeze. | -8/26/2000 | -Kai Wu | -
| 0.4 | -Edited for ACS 4 Beta release. | -10/03/2000 | -Kai Wu | -
| Document Revision # | Action Taken, Notes | When? | By Whom? |
| 0.1 | Creation | 8/17/2000 | John Prevost |
| 0.2 | Revised, updated with new terminology | 8/25/2000 | John Prevost |
| 0.3 | Edited, reformatted to conform to requirements template, pending +freeze. | 8/26/2000 | Kai Wu |
| 0.4 | Edited for ACS 4 Beta release. | 10/03/2000 | Kai Wu |