| Prev | Chapter�15.�Kernel Documentation | Next |
|---|
By John McClary Prevost
+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 @@ -24,14 +24,14 @@ 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 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 @@ -48,14 +48,14 @@ that operation.
Examples of the essential question addressed by the Permissions system: 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?
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 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 forum, where many users are contributing @@ -86,5 +86,5 @@ 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
+current user has access to should not add more than one line to a query.
|