Recently TSG worked with an Alfresco client that had unique requirements around document and folder security. In addition to traditional ACL security, the client needed the ability to tag documents with metadata that would deny users access to content unless they were members of a particular group. This post will focus on our approach for addressing the security requirements in Alfresco.
At first glance, the requirement to deny access to content based on metadata values seems like something that could be solved by using behaviors in Alfresco to modify ACL permissions any time metadata is updated. The nuance that makes this problem more challenging is that we needed to deny read permissions to certain users, regardless of what the ACL already permitted.
ACLs inherently give a user the least restrictive access possible given the permissions defined on the ACL. Take the following ACL as an example:
- John Doe – Consumer
- Group A – Contributor
- Group Z – Collaborator
If user John Doe is a member of Group A and Group Z, this ACL will permit John to have Collaborator permissions on the content because it is the least restrictive permission level that the ACL permits for John based on his group membership.
Getting back to the client’s requirement, we need to DENY all users in a group access to content, regardless of what any other permissions in the ACL dictate. In other words, in this special case, we want the most restrictive permission to win.
For those who are more intimately familiar with Alfresco permissions, you may be aware that Alfresco’s permission model does support both GRANT and DENY permissions. The challenge with using DENY permissions is that they are not exposed in the Alfresco Share interface, which is the client’s chosen interface.
Another option that was considered was using Alfresco Records Manager’s “Supplemental Markings” feature to address the security requirement. Initially, supplemental markings seemed to be exactly what we were looking for. They allow documents to be tagged with metadata that then permitted only defined users groups access to the documents. Our bubble was burst when we discovered that the supplemental markings feature is only available for documents that have been declared as records. Even though Alfresco Records Manager supports in place records in Share, as soon as documents are declared as records, other Share features become disabled for the documents, and this was not acceptable for the client.
Finally, we settled on implementing some small customizations to satisfy the requirements, which turned out to be simpler than expected because Alfresco is an open source platform. The solution involved adding an aspect with a property to store the metadata that would determine the special security. From there, we created a custom permission service implementation defined in the public-services-security-context.xml. Our custom permission service checked the metadata of the document and the user’s group membership to permit or deny the user access to content after the standard ACL permission checks were complete. This nice thing with this approach is that it intercepts the user’s access at the lowest possible level and it only required a customization in one place.
Overall we were pleasantly surprised to see that the permissions model in Alfresco could be so easily manipulated to meet the client’s unique requirements. This would have been a much more difficult challenge if the client had chosen another ECM platform.