Index: openacs-4/packages/acs-core-docs/www/permissions-design.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/permissions-design.html,v diff -u -r1.36 -r1.36.2.1 --- openacs-4/packages/acs-core-docs/www/permissions-design.html 8 Nov 2017 09:42:11 -0000 1.36 +++ openacs-4/packages/acs-core-docs/www/permissions-design.html 2 Mar 2019 19:30:05 -0000 1.36.2.1 @@ -1,27 +1,11 @@ -Permissions Design

Permissions Design

- - -<authorblurb> -

By John Prevost and Rafael H. Schloming

-</authorblurb>
- -

Essentials

- - - -

Introduction

The goal of the Permissions system is to provide generic means to both programmers and site administrators to designate operations (methods) as requiring permissions, and then to check, grant, or revoke permissions via a consistent interface. For example, we might decide that the transaction that @@ -30,75 +14,35 @@ that viewing a certain set of pages within the application is an operation to be individually granted or revoked from a user. It's expected that the Permissions system will be seeing a lot of use - almost every page will make -at least one permissions API call, and some will make several.

- -

For programmers, the Permissions API provides a means to work with access +at least one permissions API call, and some will make several.

For programmers, the Permissions API provides a means to work with access control in a consistent manner. If a programmer's OpenACS package defines new methods for itself, the Permissions API must provide simple calls to determine whether the current user is authorized to perform the given method. In addition, using the Permissions API, queries should easily select only -those package objects on which a user has certain permissions.

- -

For site administrators and other authorized users, the Permissions UI +those package objects on which a user has certain permissions.

For site administrators and other authorized users, the Permissions UI provides a means to aggregate the primitive operations (methods) made available by the programmer into logical privileges (like read, write, and -admin) that can be granted and revoked.

- -
- -

Historical Considerations

- - - -

In earlier versions of the OpenACS, permissions and access control was handled +admin) that can be granted and revoked.

Historical Considerations

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.

- -
- -

Competitive Analysis

- - - -

None available as of 10/2000.

- -
- -

Design Tradeoffs

- - - -

The core of the permissions data model is quite simple. Unfortunately, the +readily use.

Competitive Analysis

None available as of 10/2000.

Design Tradeoffs

The core of the permissions data model is quite simple. Unfortunately, the hierarchical nature of default permissions entails quite a number of tree queries which could slow the system down. Since every page will have at least one permissions check, a number of views and auxiliary tables (de-normalizations of the data model) have been created to speed up access queries. As a consequence, speed of updates are decreased and requirements -for additional storage space increase.

- -
- -

Data Model Discussion

- - - -

As described in section V., the core of the permissions data model is +for additional storage space increase.

Data Model Discussion

As described in section V., the core of the permissions data model is simple, though a number of views and auxiliary tables exist to ensure -adequate performance. The core model consists of five tables:

+adequate performance. The core model consists of five tables:

acs_methods -
acs_methods -

The set of all defined methods.

acs_privileges

The set of all defined privileges.

acs_privilege_method_rules @@ -113,20 +57,14 @@ row for every privilege directly granted on any object in the system - this is a denormalization of acs_privilege_method_rules and -acs_privilege_hierarchy

- -

There are also a number of views to make it easier to ask specific +acs_privilege_hierarchy

There are also a number of views to make it easier to ask specific questions about permissions. For example, a number of the above tables describe "direct" or explicit permissions. Inheritance and default values can, however, introduce permissions which are not directly specified. (For example, read access on a forum allows read access on all the messages -in the forum.)

+in the forum.)

The following views provide flattened versions of inherited +information:

acs_privilege_method_map -

The following views provide flattened versions of inherited -information:

- -
acs_privilege_method_map -

Map of privileges to the methods they contain either directly or because of another privilege which is included (at any depth).

acs_object_grantee_priv_map @@ -139,243 +77,110 @@ a party is a member of a group (at any depth).

acs_object_party_method_map

Relation with every (object, party, method) -tuple implied by the above trees.

- -

In general, only acs_object_party_method_map +tuple implied by the above trees.

In general, only acs_object_party_method_map should be used for queries from other modules. The other views are -intermediate steps in building that query.

- -

The data model also includes two simple PL/SQL procedures +intermediate steps in building that query.

The data model also includes two simple PL/SQL procedures (acs_permission.grant_permission and acs_permission.revoke_permission) for granting and revoking a -specific privilege for a specific user on a specific object.

- -

To sum up, the PL/SQL procedures are meant to be used to grant or revoke +specific privilege for a specific user on a specific object.

To sum up, the PL/SQL procedures are meant to be used to grant or revoke permissions. The five base tables represent the basic data model of the system, with a set of views provided to convert them into a format suitable for joining to answer specific questions. The exact means by which this transformation takes place should not be depended on, since they may change -for efficiency reasons.

- -

The transformations done create a set of default permissions, in -which:

- -
  • parties get the privileges of any groups they are directly or indirectly +for efficiency reasons.

    The transformations done create a set of default permissions, in +which:

    • parties get the privileges of any groups they are directly or indirectly a member of

    • privileges get associated with the methods of any other privileges they have taken methods from (at any level) (see acs_privilege_hierarchy)

    • objects get access control from direct grants, or inherit permissions from their context (unless the "don't inherit" flag is -set)

    - -
- -

Legal Transactions

- - - -

There are three essential areas in which all transactions in the -permissions system fall:

- -
  • Modification of methods and privileges

  • Modification of permissions

  • Queries on permissions

- -

"Modification of methods and privileges." This +set)

Legal Transactions

There are three essential areas in which all transactions in the +permissions system fall:

  • Modification of methods and privileges

  • Modification of permissions

  • Queries on permissions

"Modification of methods and privileges." This refers to actions that happen mainly at package installation time - a package will create a number of methods for its own use, then associate them with the system's standard privileges, or new privileges which the package has created. The association step might also happen later, if the site-wide -administrator chooses to change permissions policy.

- -

These steps involve directly manipulating the acs_methods, +administrator chooses to change permissions policy.

These steps involve directly manipulating the acs_methods, acs_privileges, and acs_privilege_method_rules tables. A web page for manipulating these features should be limited to site-wide -administrators.

- -

"Modification of permissions" - involves fairly +administrators.

"Modification of permissions" - involves fairly common operations. Users are typically able to administer permissions for objects they themselves create. The two basic operations here are "grant" and "revoke". Granting permissions is done via acs_permissions.grant_permission, and revocation via acs_permissions.revoke_permission. These directly manipulate the -acs_permissions table.

- -

Web pages for making these changes are available to all users, so they +acs_permissions table.

Web pages for making these changes are available to all users, so they should not be in an admin area. In order to grant and revoke permissions on an object, the user must have the administer_privileges method -permission on that object.

- -

"Queries on permissions" - by far the most +permission on that object.

"Queries on permissions" - by far the most common operation is querying the permissions database. Several kinds of questions are commonly asked: First, and most commonly, "Can this party perform this method on this object?" Two Tcl functions are provided to answer this - one which returns a boolean, the other of which results in an error page. These Tcl functions directly access the -acs_object_party_method_map.

- -

The second most commonly asked question occurs when a list of objects is +acs_object_party_method_map.

The second most commonly asked question occurs when a list of objects is being displayed, often in order to provide appropriate UI functionality: "For this party, what methods are available on these objects?" Here, the SQL query needs to filter based on whether the party/user can perform some operation on the object. This is done via a join or sub-select against acs_object_party_method_map, or by calling the Tcl functions -for appropriate methods.

- -

Finally, when administering the permissions for an object, a web page +for appropriate methods.

Finally, when administering the permissions for an object, a web page needs to know all permissions directly granted on that object. This is done -by querying against acs_permissions.

- -
- -

API

- - - -

The API to the permissions system consists of a few well-known tables, -plus a pair of PL/SQL procedures and a pair of Tcl functions.

- -

Tables

- -

acs_methods, acs_privileges, and +by querying against acs_permissions.

API

The API to the permissions system consists of a few well-known tables, +plus a pair of PL/SQL procedures and a pair of Tcl functions.

Tables

acs_methods, acs_privileges, and acs_privilege_method_rules manage the set of permissions in the system. At installation time, a package will add to these three tables to -introduce new permissions into the system.

- -

The main table for queries is acs_object_party_method_map, which +introduce new permissions into the system.

The main table for queries is acs_object_party_method_map, which contains (object, party, method) triples for all -allowed operations in the system.

- -

Also of interest for queries is acs_permissions, which lists +allowed operations in the system.

Also of interest for queries is acs_permissions, which lists directly granted privileges. Neither acs_object_party_method_map (which is a view) nor acs_permissions should be updated -directly.

- -

PL/SQL Procedures

- -

acs_permissions.grant_permission introduces new permissions for +directly.

PL/SQL Procedures

acs_permissions.grant_permission introduces new permissions for an object. It should be given an (object, party, privilege) triple, and will always succeed. If the permission is already in the system, no change occurs. The interface for this procedure -is:

- -
+is:

 procedure grant_permission (
   object_id    acs_permissions.object_id%TYPE,
   grantee_id   acs_permissions.grantee_id%TYPE,
   privilege    acs_permissions.privilege%TYPE
 );
-
- -

acs_permissions.revoke_permission removes a permission entry +

acs_permissions.revoke_permission removes a permission entry given a triple. It always succeeds--if a permission does not exist, nothing -changes. The interface for this procedure is:

- -
+changes. The interface for this procedure is:

 procedure revoke_permission (
   object_id    acs_permissions.object_id%TYPE,
   grantee_id   acs_permissions.grantee_id%TYPE,
   privilege    acs_permissions.privilege%TYPE
 );
-
- -

These procedures are defined in -permissions-create.sql

- -

Tcl Procedures

- -

Two Tcl procedures provide a simple call for the query, "Can this +

These procedures are defined in +permissions-create.sql

Tcl Procedures

Two Tcl procedures provide a simple call for the query, "Can this user perform this method on this object?" One returns true or false, the -other presents an error page.

- -

To receive a true or false value, Tcl code should call:

- -
+other presents an error page.

To receive a true or false value, Tcl code should call:

 permission::permission_p -object_id $object_id -party_id $user_id -privilege $method
-
- -

If the user_id argument is left out, then the currently logged in -user is checked. To create an error page, Tcl code should call:

- -
+

If the user_id argument is left out, then the currently logged in +user is checked. To create an error page, Tcl code should call:

 permission::require_permission -object_id $object_id -privilege $method
-
- -

These procedures are defined in acs-permissions-procs.tcl.

- -
- -

User Interface

- - - -

All users of the permissions system are the same at the user-interface +

These procedures are defined in acs-permissions-procs.tcl.

User Interface

All users of the permissions system are the same at the user-interface level. If you have the administer_privileges method permission on an -object, then you may edit privileges for that object with the UI.

- -

The UI currently provides a list of all granted permissions on the object. +object, then you may edit privileges for that object with the UI.

The UI currently provides a list of all granted permissions on the object. If the user wishes to revoke privileges, she may select a set of grants, choose revoke, confirm their deletion, and be returned to the same page after -those privileges have been revoked.

- -

Granting permissions currently (as of 10/2000) works by providing a list +those privileges have been revoked.

Granting permissions currently (as of 10/2000) works by providing a list of all possible permissions and a list of all parties in the system. (For large sites, some future search mechanism will be necessary.) After choosing privileges to grant, the user is returned to the "edit privileges for -one object" screen.

- -

If it makes sense, the system will also display a checkbox which the user +one object" screen.

If it makes sense, the system will also display a checkbox which the user may select to toggle whether permissions are inherited from the object's -context.

- -

There are a number of potential future enhancements for the permissions -UI, outlined below.

- -
- -

Configuration/Parameters

- - - -

There are no configuration options for the permissions system.

- -
- -

Future Improvements/Areas of Likely Change

- - - -

The most important future changes to the Permissions system are likely to -be in the UI:

- -
  • There should be a page displaying a list of all objects for which the +context.

    There are a number of potential future enhancements for the permissions +UI, outlined below.

Configuration/Parameters

There are no configuration options for the permissions system.

Future Improvements/Areas of Likely Change

The most important future changes to the Permissions system are likely to +be in the UI:

  • There should be a page displaying a list of all objects for which the current user is allowed to administer privileges.

  • Users should be able to view the permissions on any object, or perhaps on objects which they have the "read_permissions" method. This would allow them to see what grants are affecting their objects through -inheritance.

+inheritance.

Authors

System creator -
- -

Authors

- - - -
System creator -

Rafael H. Schloming

System owner

Rafael H. Schloming

Documentation author -

John Prevost

- -
- -

Revision History

- - - - -
-
Document Revision #Action Taken, NotesWhen?By Whom?
0.1Creation9/11/2000John Prevost
0.2Edited for ACS 4 Beta release10/04/2000Kai Wu
- - -
- -
+

John Prevost

Revision History

Document Revision #Action Taken, NotesWhen?By Whom?
0.1Creation9/11/2000John Prevost
0.2Edited for ACS 4 Beta release10/04/2000Kai Wu