Setting a lower role on a folder node while keeping inheritance

[Linda]

Hi,

We are using Alfresco Community Edition 6.2. Currently, I am trying to create a hierarchical permission structure using folders inside a site. The issue I am having is that we would like to keep inherited permissions while being able to set a "lower" access role on a per-user basis.

I have a Site1 with a Folder1 inside of it.

If Collaborator permissions for user1 are set on Site1, we would like to restrict user1 to Consumer permissions inside Folder1 while keeping any inherited permissions (the real use-case would probably have Folder1 deeper down, but this example proves the same situation).

From this link (Security and Authentication ) "Permissions set on a node take precedence over permissions set on the parent nodes."

I thought it might be as simple as setting user1 to have the Consumer role inside Folder1, but this still allows Collaborator permissions inside Folder1 from the inherited group__Site1_SiteCollaborator permissions.

However this link contains contradictory information (Understanding permissions in Alfresco Content Services ) "Since Alfresco Content Services prioritizes inherited permissions over local ones, deselect “Inherit Permissions” and make Legal a Collaborator and demote Everyone to Consumer."

I have also tried setting the following on Folder1 as I believe this is how a typical file system permission allows lower roles. In this case DENIED takes precedence and does not allow Consumer rights, because the permissions overlap:

{
    "permissions": {
        "locallySet": [
            {
                "authorityId": "user1",
                "name": "SiteContributor",
                "accessStatus": "DENIED"
            },
            {
                "authorityId": "user1",
                "name": "SiteConsumer",
                "accessStatus": "ALLOWED"
            }
        ]
    }
}

My latest idea is to create custom roles that exclude the lower level permissions. For example creating a custom ExclusiveEditor role that only includes Write, CheckOut, ReadPermissions and does not include the Consumer permissions.
That way we can Deny ExclusiveEditor while keeping Consumer permissions.

My questions are this:
1. Am I understanding correctly that the only way to set a lower level of access on a sub-folder folder is to remove inheritance?
2. My team is wondering how developers deal with this, because having a large amount of users makes this sort of management a nightmare to deal with. The use-case of setting a read-only permission for one user, while keeping inherited roles does not seem like a rare case.
3. Is the custom role idea a good solution in your opinion?

[afaust · Accepted solution]

Hello,

Indeed, the way permissions are evaluated (part due to optimisations in logic, part due to keeping it easy to understand for end users/admins) means that there are very limited possibilities to selectively restrict permissions of users in lower level nodes. Typically, disabling inheritance and re-creating the access control list in the way that best matches the desired permissions is the simplest and most stable option to go for.

The primary challenge in using DENIED permission assignments comes from the fact that by default "anyDenyDenies" (a config property) is set to true, and when you deny a permission, you deny THAT permission and any permissions it transitively grants. So when you deny SiteContributor, you also deny the Consumer (read-access) that is granted by SiteContributor.
One way to deal with that would be by selectively denying only the lower level permissions granted via SiteContributor and leaving the Consumer intact. This would mean instead of one DENIED for SiteContributor, you would have to set up DENIED permissions for AddChildren and ReadPermissions, which are the two extra permissions that a SiteContributor (transitively) provides.
The problem that remains concerns what to do when you want to re-enable write access on another node further down the hierarchy. This is effectively impossible when anyDenyDenies and permission inheritance are enabled, as the logic for anyDenyDenies means that any DENIED permission assignment anywhere in the hierarchy takes precedence over ALLOWED assignments, even if the latter are on a lower, more specific node hierarchy level. This is a performance + logic simplification added sometime in the Alfresco 4.x-ish days.

To answer the questions specifically:

1) No - the documentation by Alfresco is incorrect, contradictory (as you mentioned), and over-simplifies in some cases. You can use DENIED permission assignments to restrict access, provided you know how permissions and permission groups are composed, and what to target specifically. Due to some optimisations, you cannot undo restrictions without disabling inheritance though.

2) In my 13 years working with Alfresco, the use case of setting read-only permissions for individual users within an otherwise visible folder has not come up as often as one might think. In most cases, customers think in terms of groups / roles, avoiding direct permission assignments to individual users. And with groups / roles, we are often able to come up with a systematic approach in which we can automate the inheritance disabling + permission re-creation logic needed to restrict access, because the variation is no longer arbitrary / individual on a per-folder level.

3) The custom role approach can work the way you describe. On the top level you may grant both Consumer and ExclusiveEditor, and at the level where you want to restrict access, you use DENIED with ExclusiveEditor for those users you want to have restricted access, keeping Consumer unaffected.

[Linda]

Good day Mr. Faust

We appreciate your help very much. Apologies for the late reply from my side.

I have just discovered a post (one you made actually Re: How to enable non-admin user to modify ACLs to docs ) that agrees with my findings: I can DENY a permission and then ALLOW that same permission further down. The ALLOW takes precedence at that point and lower even if the DENY is still being inherited from higher up.

I tested this using the REST API and it does still seem to work this way, however your reply to my post says: "This is effectively impossible when anyDenyDenies and permission inheritance are enabled, as the logic for anyDenyDenies means that any DENIED permission assignment anywhere in the hierarchy takes precedence over ALLOWED assignments, even if the latter are on a lower, more specific node hierarchy level."

We are using Alfresco Community Edition 6.2. Do you think this has changed in the newest version?

In my tests I made sure to explicitly set security.anyDenyDenies=true and to use a user that is not the owner of any of the content.