Entity based access control [#2936142]

In agencies a lot of custom sites will be managed by DRD but not all team members should have access to the whole inventory but only to selected hosts, cores or domains.

For this, DRD needs some sort of entity based access control system. As cores, hosts and domains are all entites we should find and recommend a third party solution or see if even core will be providing some support for this in upcoming releases.

What comes to mind is a modules like "Permission by term" but there might be others as well.

Comments

Comment #1

12 January 2018 at 08:45

jurgenhaas created an issue. See original summary.

Comment #2

johnny5th CreditAttribution: johnny5th at Encore Multimedia commented 26 April 2018 at 21:18

I'm trying to come up for a solution for entity permissions one a larger site that I'm doing. I'm looking at both permissions by term, and Group https://www.drupal.org/project/group

Comment #3

maxrab CreditAttribution: maxrab at arocom GmbH commented 20 June 2018 at 18:00

I did some research on this one and my impression so far is the following:

* permissions by term is lightweight but doesn't go far enough. The access to an entity is allowed or not, you are not able to define own view, edit or delete permissions for this one, which I think is vital because some users might be allowed to see the overview of a domain to get all the information but he or she might not be allowed to edit or delete it, so we definitely need a more granular way to do this.
* The group module is very nice and can do all of the things we need, but it is to much extra complexity and would need a lot of extra entites to work like we want it to.
* My favourite so far is Taxonomy Access Control Lite or tac_lite which basically works like permissions by term, where you can add tags to entities and define which users or roles have access to them. The difference is, that through different schemas you are also able to define whether the access to the entity is a view, an edit or a delete permission, which makes this almost perfect. It would also work without touching any of DRDs functionalities or the code, any user could define their tags and schemas like they need.

I would love to see some feedback on these thoughts.

Comment #4

jurgenhaas

he/him

German

Gottmadingen

CreditAttribution: jurgenhaas at LakeDrops, PARAGON Executive Services GmbH commented 22 June 2018 at 14:29

Thanks @maxrab for reporting about your research results. This seems to support the idea that entity access control should be done by a dedicated solution for that task and DRD should only make sure that it doesn't break their access control. Most likely, the Drupal universe will see multiple solutions doing the same or similar things and DRD should not force its users into any particular one. The choice is with the user and as loong as all parties properly support the entity APIs, it should always work.

With regard to my last statement I'm pretty sure that DRD properly works with the entity API with on area of uncertainty: views. We should do some tests with the access control modules being enabled and configured and then verify that the host/core/domain views really only contain those entities with permitted access and that they also only provide access to the allowed actions like edit and delete.