This article introduces an upcoming new 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 attributed-based access control (ABAC) system. The ABAC system would allow complex access policies to be created without writing a single line of code. As part of this effort the node grants API which stores access records to the database will be deprecated.

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 example of 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 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.

In a 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 probably works there are a few issues:

  • 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 access is checked, this can be expensive and slow down the website.
  • Managers of the access policies have no control to change 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 to when a node is saved. You can find an example with the correct terminology in this blogpost. 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 for 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 does only work 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 in Drupal core there is 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 an 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 attributed-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 on the topic figure 4. displays how a complex ABAC system could work in an enterprise environment.

Guide to Attribute Based Access Control ABAC Definition and Considerations Figure 4

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

Table 1

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 for Drupal developers similar as for 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:

Table 2

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

Table 3

Each attribute can be handled by a plugin. For the lowest levels of the conditions we could reuse the “condition plugin” implementation from 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 prioritise 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. 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.


 

250+ Communities are powered by Open Social

Don't miss our posts

Nov 13, 2017 - Security - Drupal Community - Open Source

Embracing Open Source Security with Drupal

Open source security for online community platforms is important to us at Open Social. Here’s an overview of open source security, and why it’s important that we’re covered by the Drupal security team.

posted by Natasha
Nov 02, 2017 - User Experience - Community Building

Why Use Mentions (@) to Boost Community Engagement?

Community engagement breathes life into a community and results from vocal, passionate members. Open Social’s mention feature makes it easier for members to engage and connect with each other.

posted by Evelien
Oct 30, 2017 - User Experience - Community Building

Improve Your Community’s Accessibility

Web accessibility ensures that everyone has equal access to content on the web. Here are few actions that community managers can take to make their community accessible to everyone.

posted by Bas