[Meta, Plan] Pitch-Burgh: Policy based access in core

For those interested, the current pitch is about getting this into core. I was asked about what would happen if we did not get this into core and ended up with the IS as shown here. The current pitch looks more like this:

The scope of the work is to add an API to Drupal core that allows people to assign permissions via other means than user roles. These permissions will be assigned based on custom policies such as time of day, safety level of the account, etc.

The initial goal is to convert Drupal's current 2 policies (user roles, UID 1) into the new API and clearly document how to utilize the API. A stretch goal would be to add an example module that already implements the "office hours" policy.

The milestones are threefold, but two have been reached already:

• Have VariationCache accepted into core as the new API relies on it DONE
• Have a centralized permission checker accepted into core because everything hinges on this DONE
• Convert Flexible Permissions into core code and also convert UID 1 / user roles into policies

At the end of the project you should have a merge request in the Drupal core issue queue, some documentation on how to use this (will need guidance on where to write this) and hopefully as a stretch goal an example module.

More specifically, we are looking at the following (lots of copy-paste, code already exists):

1. Move all of Flexible Permissions code into the Drupal\Core\Session namespace and add AccessPolicyInterface::SCOPE_DRUPAL
2. Change the PermissionHashGenerator to mimic GroupPermissionHashGenerator
3. Change AccountPermissionsCacheContext to mimic GroupPermissionsCacheContext, namely using cacheable metadata from the hash generator
4. Write a RoleBasedAccessPolicy (name pending) class that calculates permissions based on which user roles you have
5. Write a SuperUserAccessPolicy (name pending) class that grants all permissions to user ID 1
6. Check if all tests still go green and adjust where needed

Should the DA ask to focus on getting this to work in contrib rather than core, then we could skip step 1, try to swap out core’s services for step 2 and 3 and still carry out step 4 and 5. Step 6 would be difficult because core’s tests would not know about us swapping out the access layer.

Whoops

Updated IS to reflect #3 getting approval

Updated the IS to point to child tasks for an explanation of the remaining work.

Added the documentation that could go into the official drupal.org documentation here: #3381453: [policy/docs, no patch] Document the new access policy API

That is about query access, which is completely different to what is being worked on here. The work here precedes that by building your permissions following policies. You can still take your built permissions to a query and try to get entity query access working.

Core currently has no generic entity query access, only node query access, and I even helped work on the system that went into Entity API to fix that problem space in contrib. It still needs fixing in core in my opinion, but that's not what this issue is about.

No not quite.

Policies determine which permissions you get in the system based on things you can deduce from the global context. As long as that context doesn't change, you always get the same permissions from these policies. What you're describing isn't Policy Based Access Control (PBAC), but Attribute Based Access Control (ABAC), which we already have in core in the form of hook_entity_access. You could perfectly take care of both your example scenarios with simple entity access hooks.

Where policy based access shines is that any permission check, doesn't even have to be entity related, can now have its outcome affected by which policies are currently active for the user. It could be that you receive entity-related permissions from a policy, but it's definitely not limited to that.

So it's more reasonable to consider ABAC a subset of PBAC. ABAC typically checks for both attributes and a permission, e.g.: "view unpublished content" is the permission part (PBAC) but the fact that this permission will always be checked in tandem with the "status" field is the ABAC part.

You can have PBAC without ABAC, but the other way around would often be really weird (although not inconceivable).

Agreed that it's rather hard to predict what people will be doing with the API, but keep in mind that Group has been running on this for quite a while already. So there is an example of it being useful to contrib. Having said that, the contract stipulates that the primary goal is to get this into core. If there's any budget left after that, I can definitely cook up a mini module or two that cover a single access policy.

10.3 if we can get the last issue committed in time. Part of it already is in 10.3

Nothing :)

Crediting those I spoke to about getting the ball rolling + those who helped with the many reviews. Feel free to ping me if I forgot anyone.

I submitted a session on this subject, would be cool if it got accepted.