Access Control Improvements For Drupal 8

This article introduces an upcoming paradigm of access control in Drupal 8. In addition to the current role-based access control (RBAC) system, developers will have access to a more flexible attribute-based access control (ABAC) system. The ABAC system will allow complex access policies to be created without writing a single line of code. As part of this effort, the node grants API stores access records to the database.

Where are we coming from?

Everyone that builds something on Drupal knows that users can be assigned certain site-wide roles. These roles have attached permissions that control what specific users can see and do. These roles work well for simple sites but for domains with complex business rules where decisions are based on multiple factors, the roles become unmanageable and untransparent for non-specialists.

Below is an example of the complex business rules of a potential request for Open Social in the domain of NGOs with RBAC:

A user has access to a local “Thank you” event in the “New York” group where he has been active for at least 3 months, He is living in the US and has the “Volunteer” role. When the user is identified as a “Gold Donor” or “Special Volunteer” he has access regardless of his activity in the online community.

In an RBAC system we could think of the permission: “Access to VIP events” and give it to the “Volunteer” roles. Furthermore, a “Special access to VIP events” permission has to be connected to the “Special volunteer” and “Gold donor” roles.

When the access is checked for an event the following logic would need to be added in code to make it work:

// Return access Allowed if user has access to the VIP event.
if (is_thank_you_event($event) && event_is_in_new_york_group($event) && ($user->hasPermission(‘access to vip events) || $user->hasPermission(‘special access to vip events’)) && user_living_near_event($user, $event)) {

  if ($user->hasPermission(‘special access to vip events’) || user_is_active_in_community($user))) {

    return AccessResult::allowed;

  }

}

Issues with the RBAC approach

Even though this approach would work well, there are a few issues to address:

The logic is difficult to understand and maintain because attributes of the event and user are mixed.
All access calculations have to be done when the access is checked, this can be expensive and slow down the website.
Managers of the access policies have no control over changing overall business rules without help from a developer (e.g. if the living location is not important anymore).

The Drupal 7 solution: The node grants API of locks and keys

The node grants API was developed in order to increase maintainability and efficiency of the access rules. Instead of checking access during runtime, access records are stored when a node is saved. You can find an example of the correct terminology in this blog post. The basic concept works with key locks (access records) attached to a node and the user has keys (grants) to gain access to the node. One key is needed to open a key lock and to gain access to the node.

Following the example above we could create this a key lock:

Lock 1:

is_thank_you_event($node) && event_is_in_new_york_group($node)

When a node is a thank you event in the “New York” group then the key lock is stored in the database. When a user request access to this specific node the system will see there is a lock on it and will check if the user has a key for it. Here it is possible to add multiple keys for the same lock.

Key 1 to Lock 1:

$user->hasPermission(‘special access to vip events’)) && user_living_near_event($user, $event))

Key 2 to Lock 1:

$user->hasPermission(‘access to vip events) && user_living_near_event($user, $event)) && user_is_active_in_community($user)

The node grants API is mainly used by experienced backend developers but it was never widely spread in the Drupal community. The main reason is that the terminology is not applied consistently and that the concepts are abstract and complex to understand.

However, the developers that are familiar with the node grants API apply it to many scenarios because of the increased performance for the specific calculations on a node_save and the clearer abstraction between the business rules related to a node and a user. One of the biggest issues for these developers was that the node grants API only works for nodes and not for other Drupal entities.

Drupal 8: growth of entities

In Drupal 7 sites, most content is located in the Node entity. However, with the extended support of the entity system in Drupal 8 it is now much easier to create new entities that do not share the attributes of nodes (e.g. published status and revisions).

An example is the Group entity in the group module. Or the Post entity in the Open Social distribution. Similar to Drupal core there is also a Comment entity. From a conceptual level, it does not make sense to make these entities part of the Node entity.

The wish to have a generic entity grants API has been debated in this 7-year-old drupal.org issue. The discussion evolved from rebuilding the node grants API for Drupal entities to new access system that uses consistent concepts and terminology. The new access system is based upon the theory of attribute-based access control (ABAC).

Access policies and attributes

An ABAC system works with access policies based on attributes of an entity. The NIST Guide to Attribute Based Access Control (ABAC) Definition and Considerations provides a good introduction to the topic. Figure 4 displays how a complex ABAC system could work in an enterprise environment.

An attribute can basically be any feature of the current entity.

We decided to drupalize the concepts instead of going with a standardized protocol like XACM and implement a pluggable MVP version. The MVP is aimed at Drupal developers, just like the node access grants. Furthermore, the query-alter based system will be deprecated and the new access rules should not be coupled to the storage.

In our example the attributes would be:

A user has access to a local “thank you” event of the “New York” group when he has been active for at least 3 months, is living in the US and has the “volunteer” role. When the user is identified as a “gold donor” or “special volunteer” he has access no matter of his activity in the online community.

Policy 1 – Active volunteers access to “thank you” event:

Policy 2 – Special people access to “thank you” event:

Each attribute can be handled by a plugin. For the lowest levels of the conditions, we could reuse the “condition plugin” implementation from the core. The main benefit of such a system is that we could cache individual attributes with the Drupal core caching system. Furthermore, it would be easy to change the policies from YAML config. There would only be custom code necessary for attributes that are very custom.

The YAML implementation in Drupal is currently discussed in the drupal.org issue. One important requirement is that the access policies of contrib modules work well with the Drupal core policies. The technical solution is challenging and currently, there is an ongoing discussion how to best prioritize policies.

Meet the team

The aim is that this feature will land in Drupal 8.5. We could use all the help by providing feedback on the issue on Drupal.org. The following people are the main drivers to push the issue forward at this time:

Kristiaan van den Eynde – Maintainer of the group module. The key designer of the technical architecture for the new access system.
Gabe Sullince – Doing a lot of implementation work by creating proof of concepts and helps to create the architecture.
jonathanshaw – Helps to create the architecture.
Niels de Feyter – Works to help this issue forward and helps in improving the concepts.
xjm, catch, wim-leers – Drupal core maintainers. They have to approve the system and can make architectural decisions (e.g. to deprecate the query-alter based system).
István Kurucz – Helping to move the issue forward by asking the status.
Niels van der Molen (me) – Open Social maintainer. Trying to move this issue forward by following the discussing and communicating the concepts in a less technical matter.

Some of us will be at DrupalCon Vienna. Please join us in this BOF session to learn more and to help Open Social become a greater product by improving Drupal 8.

Access Control Improvements for Drupal 8