Policy-Based Access in Core by Kristiaan Van den Eynde

"While developing the Group module, I found that I needed a system that could dynamically add to one’s permissions or even revoke some permissions."

This is the instance that inspired Kristiaan Van den Eynde to develop a Policy-Based Access in Core (PBAC) system for Drupal. The Drupal core implementation of the permission layer did not support dynamically adding or revoking permissions, prompting Kristiaan to devise a custom solution. Eventually, it became clear that this functionality could be abstracted from the Group module and transformed into a standalone module, applicable even to the core system.

When PitchBurgh came along, I saw an opportunity to convert this module into an API for Drupal core and was lucky enough to be selected to do just that.

As the brainchild of the Drupal Project Lead, Dries Buytaert, "Pitch-burgh" made a grand appearance at DrupalCon Pittsburgh last year. It was the first of a series of initiatives that the Drupal Association undertook to speed up Drupal innovation. Among the many submissions, 7 finalists were chosen, of whom five were awarded funding, but Policy Based Access in Core was not one among them.

After the competition ended, Matt Mullenweg, co-founder of WordPress and CEO of Automattic, offered to provide an additional €20,000 in funding for DrupalCon Pitch-burgh. This generous contribution allowed the organizers to fully fund the next project chosen by the audience at DrupalCon: "Policy Based Access in Core" by Kristiaan Van den Eynde of Factorial, which required €13,000.

Kristiaan, the author of Policy Based Access in Core API, is a Senior Drupal Developer at Factorial, known for his significant contributions to the Drupal community. As the author of the Group module, which boasts 14.9K reported installations, Kristiaan has made a substantial impact by providing a robust solution for managing groups within Drupal. He has also rewritten the render cache into VariationCache, an API with 15.2K installations and no reported bugs. He also maintains the Group module and various parts of its ecosystem, leveraging Drupal's tools to express his creativity and drive innovation in web development.

The Policy Based Access in Core initiative has gained significant momentum since DrupalCon Pittsburgh 2023, and getting a major feature into Drupal Core is a significant accomplishment. Kristiaan explains the process involved in this progress.

"Essentially nothing gets into the core without the framework manager’s approval, so my first goal was to reach out during Dev Days Vienna and see how they would receive my proposal. After a positive reception, I worked on a proof of concept that I could show at DrupalCon Lille."

Kristiaan soon realized that multiple questions needed to be answered before integrating an API of this scale into the core. To address this, he decided to split the process into three parts:

• API 
• Documentation 
• Implementation.

This approach meant that we could save the “noise” of having to adjust core tests for last and focus all of our attention on the new stuff first. 

It didn’t take that long to get the API into the core, and at that point, Kristiaan offered to become a core maintainer for the two systems he had been heavily involved in over the past few years: user and cache.

One of the biggest hurdles to getting the implementation accepted was to prove it wouldn’t kill performance. 

So Nathaniel Catchpole and Kristiaan took a rather lengthy detour to add some serious performance tests to the core. Once those were in, the way for acceptance was open!

Soon after, Kristiaan Van den Eynde's Access Policy API journey came to an end.

Policy-based Access in Core is about to be released with Drupal 10.3. 

said Kristiaan. He also added that a bonus that will be released alongside it is that you can now turn off user 1’s all-access pass on your site to strengthen its security. This would previously have been impossible without the Access Policy API.

When asked to explain the architectural principles behind the PBAC design and its difference from traditional Role-Based Access Control (RBAC) mechanisms Kristiaan answered RBAC is rudimentary: You assign someone roles and that determines the level of access they will have across the system. This can be considered a single access policy: Figure out what roles someone has and assign permissions accordingly.

PBAC, on the other hand, allows you to specify an infinite amount of extra policies. So we could also start handing out (or revoking) permissions based on the time of day, location, account settings, etc.

Attribute-based access control (ABAC) in the core typically involves assigning permissions based on attributes linked to user accounts or subjects. While this approach offered a certain degree of flexibility, it was inherently limited by its static nature. The permissions were predefined and did not easily adapt to changing contexts or dynamic conditions. 

On the other hand, policy-based access control (PBAC) introduced a more dynamic and context-sensitive approach to managing permissions. PBAC allows access rights to be granted or revoked based on predefined policies considering various conditions and scenarios. For example, a policy could stipulate that administrative privileges are only granted when a user has two-factor authentication enabled on their account. This enhances security by ensuring that higher levels of access are only available under secure conditions. 

Furthermore, to mitigate the risks associated with hijacked accounts, a policy might limit the number of deletions a user can perform to three pieces of content per day. Kristiaan often talks about one particular policy that ensures work-life balance:

"People can only work on the site during their office hours, outside of them they are reduced to regular site users.

Another cool policy you could enact is that juniors cannot carry out destructive actions unless a senior is on the clock. This should prevent chaotic calls in the middle of the night where you’re being told someone just oopsied the database into oblivion."

These examples demonstrate how PBAC can provide a more granular and adaptable approach to access control, addressing specific operational needs and security concerns in ways traditional attribute-based systems cannot.

Speaking of the technical expertise that is anticipated to work with PBAC, as it is an API, it’s implied that development is involved. Having said that, it would be perfectly possible to build a UI that lists all of the policies that are enabled on a site so that site builders can see how the policies they enabled work together. At that point, the required level of expertise would go down a bit.

Kristiaan concludes the conversation with The DropTimes with his vision for the future,

"My vision is for the core to pave the way as much as possible for modules such as Group and Domain to shine. These types of modules often have to invent new APIs or bend core APIs to get the different systems to work the way they need them to."

He also adds it is not his goal to move all of Group into the core, but the cool parts that people may want to reuse should be either stand-alone modules or become core APIs. Either way, with VariationCache and Access Policy API in core now, he would like to focus on improving what’s there for a while rather than keep adding more and more.