# dotProject :: Access Control System |
dotProject Development Team | $Date: 2007-02-27 08:04:48 +1100 (Tue, 27 Feb 2007) $
Request for Comment 001.00 | $Revision: 4791 $
Status | Draft

## Definitions

Actions
  An action or operation (depending on the context) is a operation that can be perform that is either allowed or not.
Policies
  Policies are collections of actions that can be conducted on a type of record or within a module.
Roles
  A role is a collection of on or more policies.
Users
  A user.
User Groups
  A collection of users.
Scope
  Scope is an indication of the extent that something covers.
Context
  Context is where a particular control is applied.

## 1.0 Introduction

## 2.0 Concepts

### 2.1 Policies

## 3.0 Implementation

### 3.1 Actions

An action is a single operation, defined by a boolean value, for an operation that can be conducted within the context of its use.

The system will require system defined actions, that is, those that the core code expects to be avaialable, and user defined actions, that is, those that can be used programmatically for customisation.

The system defined policies will mirror the appropriate SQL commands in their naming convention.

### 3.2 Policies

A policy is assigned a 32-bit mask. The lower word (the first 16 bits) will be system defined policies, this is, dotProject relies on these being certain values. The upper word (the last 16 bits) will be able to be defined by the use, for programatic use in customisation.

The system defined policies will mirror the appropriate SQL commands in their naming convention.

Masks for System Defined Polices:

    		SELECT    0x0001
    		INSERT    0x0002
    		UPDATE    0x0004
    		DELETE    0x0008
    		GRANT     0x0016

A policy will have a context (where is applied), a scope (how far is it applied) and an item (which 'thing' is it applied to

Context is either for a module or a record.

Scope can be private (only applies to single user), protected (applies to users with the same or other role, or in the same or other group, etc) or public.

The database schema of the policy will be defined by:

    	Table: acl_policies
    	-------------------------
    	policy_id        INT
    	policy_mask      INT
    	policy_context   INT
    	policy_on        INT
    	policy_to        INT
    	policy_scope     INT

Example (with text equivalent values)

    	id   to        scope   mask           on         context
    	1    all[0]    user    select         all[0]         projects
    	2    manager   role    select|update  all[0]         companies
    	3    Eddie[2]  user    select         Hifi store     companies
    	4    Techos    group   delete         Buy stereo[4]  tasks

These would read in english:
All users can select all projects
The manager role can select or update all companies
Eddie, a user, can select (read) the Hifi store company
The Techos group can delete the Buy stereo task

Implied Policies

Implied policies are automatically applied to certain things, for example, users can edit records they create (providing they have edit rights that allow this).

### 3.3 Roles

### Compacting the ACL

For efficiency, the ACL require compacting to achieve the least set of unique polices, the UPS (Unique Policy Set).

The ACL is compiled by selecting all the policies for user, all the policies applied to any users roles and then finally groups.

### Precedence in the ACL and UPS

-- group, role, user