UAC - User Access Control

(proposed to Drupal, but not supported yet)

SYNOPSIS:
---------------------------------------------------------

With increasing popularity Drupal has started to find its way into enterprise applications, with many organizations
have started to use it for external and more interestingly internal web based interactions. Profoundly, the adoption
of Drupal for intranets opens a new avenue for the usage of Drupal. However, having begun with a different objective,
Drupal fails to meet the requirements of corporate implementation out-of-box. However, few modules such as
Open ID, LDAP integration submenu and services try to fill the gap with a major requirement left unhandled and it is
fine permission system.

A fine permission system, long time expected feature [1], is supposed to meet the demands mentioned follow and
undoubtedly encourage its use in sites with deep and fine access control needs such as corporate intranets,
social networks,public sites and torrent / file sharing sites.

DRUPAL.ORG USERNAME:
---------------------------------------------------------
garthee http://drupal.org/user/125748

LINK TO PROPOSAL DISCUSSION:
---------------------------------------------------------
Authorization and Permission : http://groups.drupal.org/node/9584
g.d.o user account : garthee : http://groups.drupal.org/user/6844

BENEFITS TO DRUPAL/OPEN SOURCE COMMUNITY:
---------------------------------------------------------

A fine permission system, long time expected feature [1], is supposed to meet the demands mentioned follow and
undoubtedly encourage its use in sites with deep and fine access control needs such as corporate intranets,
social networks,public sites and torrent / file sharing sites.

OBJECTIVE:
---------------------------------------------------------

I propose an authorization system to run along with user.module in current implementations as a separate
module, and supersede user.module’s functions wherever appropriate and eventually, in future strip user.module
of permission related tasks and perform all on its own, which I hope will happen in reality.

PROJECT DETAILS:
---------------------------------------------------------

The following description is also expected to answer the question why this module is needed.

1. Enable assigning permissions to users (currently only possible through roles)
2. Nested roles (Currently flat and no hierarchy is possible) with permission inheritance.
3.Enable both GRANT and DENY permissions for both ROLES and USERS currently only grant is possible, due to the
cumulative nature of design. However with permission inheritance in nested roles and user based permission
assignment will require DENY permission too.
4.Policies (currently not available in this context, but node_access is somewhat related, and applying this to
nodes). See (5)
5.Virtual groups (users can be grouped by location, time zone or any other option profile module could present)
so that policies can be applied implicitly. As this is somewhat new, to explain it further, it is like a user
from Canada is allowed to view Canada pages without assigning him a specific role. Or users from UK are
allowed to access check_uk_stock module and Buckingham_jabber module’s all features except admin
configurations of those modules.
6.Default admin role – A role where a user can be assigned to admin position with access to all features,
except permission control page. Only root user will be able to add / remove users from this role and
permissions are hardcoded for this role.
7.User area and admin area (which is somewhat related to memory management :) ) Through our API, we will
require modules to define two different sets of permissions, and user area permissions are flexible
and granted through policies implicitly as well. However admin area permission is critical of nature
and requires explicit control which is provided only to admin_role (or perhaps to other roles explicitly
assigned – a design dilemma)
8.Permissions are applied to an object (node/1) or collection of objects. This opens up a lot of new implementations. For instance in node module for node objects, the following example explains an awesome possibility.
a.Node module can define four permissions namely, view_node, create_node, create_node_with_set_permissions, adminster_nodes
b.And it can restrict access to view_node to virtual group of Canadian users, create_node to a virtual group of Canadian parliament members – virtual group and
c.create_node_with_set_permissions to only whips (or party leaders)- virtual group where all these permissions belong to user area. Adminster_nodes – which is an admin area permission, can be granted to site_adminstrator role and not to any virtual groups
d.The roles or virtual groups with create_node_with_set_permission can decide who can view/edit/delete each node when they create, and this is only possible because of object wise permission available
9.Object containers – objects will be collected through some means. For instance, all nodes belong to node
container or perhaps story container. (Which can be again nested, but only of single hierarchy to avoid complications).
10.Finally policies and virtual containers (Very much similar to node_access implementation)

For instance someone can pick and apply permissions to all modules coming under taxonomy term north_america.

SOLUTION DESCRIPTION:
---------------------------------------------------------

Additional field in {role} table to specify the parent role’s rid (if available) will give us a single hierarchy
nested roles. A role can be assigned to admin role through configurations, and member need to be explicitly assigned to this role, where they will gain all access except access control. A table similar to {permission} with uid can be used to
record user based permissions, and I am bit against using {users} table for this. Permissions are always cumulated
on GRANTS through inheritance and all DENYs are removed from the list of GRANTed. Which guarantees higher precedence for DENY.

Without affecting the existing functionality, when modules register for permissions through hook_perm() they can
provide two additional parameters (or possibly single associative array – new approach in Drupal 6 – which is
more extensible) area (user / admin) where user (=0) is default, and whether specific to any object (otherwise null).

Most of the background control will be handled through hook_db_rewrite_sql, however depending on the workarounds'
availability, a patch to user.module at user_access () maybe needed, which I will try my best to avoid. However as
user.module says “All permission checks in Drupal should go through this function. This way, we guarantee consistent
behavior, and ensure that the super user can perform all actions.” - it is where exemptions from permission control
and final decisions are made at times, and it may be unavoidable to workaround other way.

Finally hooks and APIs are provided to support, virtual groups, containers and policy implementations. In the
case of virtual groups roles can be created and users are assigned to on the fly or users are directly assigned to
the relevant permissions on the fly (see the use case above) or a new table can be used (need to be discussed).
Policies are what assigning permissions to virtual groups and a filtering system similar to views selection can be
adopted here. As objects also inherit permissions, i.e. all pages will inherit the permissions for ‘page’ container,
unless overridden for a user of child role. This will be done through a cached real time evaluation of permissions.
At necessary points, hooks will be allowed to modify the default behavior, especially in policies and permission
evaluations, and hope to provide the GUI for admin settings through hooks and APIs, thus we would provide the examples to expand the module within the module and make it more modular.

ROADMAP:
---------------------------------------------------------

This module will address the aforementioned needs in its own way independently and modularly as explained above,
and will seldom interact with user.module.

Once most of the user.module is shown to be handled by this module effectively, it can substitute user.module
for permission related tasks in future releases.

DELIVERABLES:
---------------------------------------------------------
1.Permission.module implementing the aforementioned features
2.(If it is necessary) a patch to user.module to provide extra permission control in addition to what is available
currently for the legacy modules

REFERENCES:
---------------------------------------------------------
[1] http://drupal.org/node/217934