enhanced centralized authorization / permission control

I like the idea and I mentored Garthee last year on his project and I know he's sharp and a hard worker.

The proposed solution could make node_access unnecessary as every type of object and every single object (a particular node in this case) will be permission controlled and of course with some optionals granted / denied for a particular user on top of roles permission.

However, if possible, i am hoping to see this get integrated with core, where it will become more relevant to the discussion going on in Data Architecture Design Sprintgroup.

I've been dying to see an overhaul of user.module with many of the features you propose here. I even submitted a feature request to this effect at http://drupal.org/node/217934. I, for one, would love to see you take this on and sincerely hope it finds its way into core in the near future.

What will happen with existing modules, none of which are aware of your module, when I install permission.module? Do you foresee me having to manage users in two different places? Or will there be some sort of backwards compatibility layer in there, so calls to the old user.module will be redirected to your permission.module? Until this is fully integrated into core, I see legacy support as being a major hurdle.

The "patch" the user.module idea didn't go down very well with me. I would recommend dropping the assumption of integration into core when you start working on the module and looking at more modular ways to achieve this.

I love the module idea, definitely think a fine-grained permissions API like the one proposed is needed. Ideally, once installed, this module should give you the control to decide on whether your module should override all other pemissions. Provide an API which other module developers can work with to use your permissions system.

Cheers,
-K

Thanks houndbee for the feedback.

I didn't assume the absorption into the core, and I m sure, people will be reluctant to let a considerably new face into core-development ;-)

As I said in roadmap, I would like to the cover the following within GSOC
1. A parallel permission module to user.module, which will of course use some of the existing tables, while using new to address everything from object perspective (user object inherits permissions from role object, and together with its own permission, access the other objects / groups of objects - eg nodes or node/11 over the permission system) with APIs / HOOKS to implement policies. However modules will have to call our permission APIs, for instance to evaluate a permission to a node perhaps xxx_authorize($node) or xxx_authorize($module, $object_id), which will certainly affect the implementation over legacy modules.
2. Certainly at least a single line patch is needed at user.module if existing permissions to be controlled as everything is routed through user_access function in legacy modules, and it doesn't provide any hooks. However if there is any workarounds available in this context I am willing to follow.

And beyond the scope of GSOC I will leave the community to adopt to core this depending on its functionality. However, I have built a module implementing a part of idea and available for demo at
www.project.theebgar.net

Please contact me at admin/at/theebgar/dot/net to obtain the account to test it, and I am sure you will understand the significance of the security related with that account (as it needs permission to sets permissions) :D

PS: Along with my GSOC proposal (application) I am hoping to provide few interaction diagrams, and database structures I am having in mind so that community can help me refining it

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.

I am expecting to achieve the following within GSOC scope.

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:

Most of the following discussion is subject to change in
the implementations as per the guidelines of the mentor
and the community.

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.

Thanks for your thoughts / ideas into this.

1. The problem addressed has wider scope not limited to node view, or even node access.
2. Handling at SQL through rewrite is one of the method that will be used.
3. Windows model (was even mentioned in the proposal) is from user interaction perspective - used as an example to explain abstract idea - implementation is totally different.
4. Performance is a concern, but these have been implemented, but decentralized.
   Here the main idea is to restructure user.module permission (where there will be no additional overhead) and extending what is provided through node_access and other various modules to all objects.

For the example you provided we could select only 40 nodes through sql rewrite for those with permissions in a single call. Basically, we will keep roles and user (which is new) based permissons (which is of less overhead than roles), and many features (virtual groups) wil mostly be rolled back to roles / user permission, thus at run time no additional overhead .

Most of the proposed ideas are desperately needed, could be simply hacked (but improperly) with another LEFT JOIN or two. We will restructure, provide hooks and apis and do it drupalisticallly.

Scalability / performance is a concern but not a problem, but in the basic mode it will be faster / powerful than what is currenly available, and for a enterprise intranet this will mostly be acceptable provided we embrace proper measures.