Meta Data (Rule) Driven Entitlements

[jamen]

In architectural discussions for certain types of content applications, there are certain use cases that do NOT lend themselves well to hierarchical and inherited permissions assigned to (user/group) authorities.  Are there any changes being incorporated into future versions of Alfresco for rule drive entitlements (e.g. user is a member of a group AND meta data meets a certain criteria)?  What implications or constraints are there for search indexing for such use cases?

[afaust]

There already are capabilities to implement something like this - it's called Dynamic Authority. This allows for the dynamic evaluation of "does current user have role X on node with state Y" where "role X" may have been granted permissions A, B and D in a gloabl scope.

This works reasonably well and efficient for permissions that relate to actual modifications / write-operations, but it can be a serious performance detriment to read-operations, specifically if applied to the base "Read" permission. There are various optimisations included in Alfresco ACL checking and SOLR index tracking that rely on "Read" being managed via hierarchical/inheritance-based ACLs.

I know of no plans to ever change anything with regards to the underlying permission management. Any change would be a serious undertaking to get done in a way that is both compatible to all the existing functionality and of sufficient performance.

That being said, I have implemented solutions in the past that utiliize metadata-driven access rules. Instead of using dynamic authorities though, it would use a combination of event-based processing, ACL changes and transparent/automated group memberships to esssentially simulate rule-driven entitlements that would still be compatible with the default ACL-based semantics of Alfresco.

[jamen]

Thanks for your reply Axel Faust‌, just on the following

That being said, I have implemented solutions in the past that utiliize metadata-driven access rules. Instead of using dynamic authorities though, it would use a combination of event-based processing, ACL changes and transparent/automated group memberships to esssentially simulate rule-driven entitlements that would still be compatible with the default ACL-based semantics of Alfresco.

I just want to clarify what you've said further, as some of the projects I've worked on could fit into this broad bucket of functionality.  Do you mean you were undertaking such rule processing say in these type of designs:-

• Spring services
• Within the controller of WebScripts

I've reviewed the concept of Dynamic Authorities, but it's not quite what we are looking for.  Certainly adding a custom permissioning model with new permission groups (and dynamic authorities) can accommodate a certain set of use cases.

My original question really is borne out of scenarios really necessitate a dynamic evaluation of the node attributes.  Your observations are spot on wrt optimisations and the like and the drawbacks of not having these.  In fact it's the complex rule evaluation scenario for entitlements that may undermine indexability of content for search in a standard way.

I heard a rumour that there may be more developments in this area.  But hadn't heard any more for quite some time.  Hopefully someone from product management might pick this up - Richard Esplin‌?

[afaust]

I was using a combination of behaviours (implementations of policies, e.g. OnUpdateProperties), services and - in some cases - AOP interceptors. Web scripts are definitely the wrong architectural layer to implement such a feature, as they can be easily circumvented.

An implementation can be quite simple (as a starting point):

• everyone has "basic" read access (the default one)
• the ACL checking logic / configuration is amended with an additional "rule-based" voter that restricts based on rule logic
• SOLR requests are amended with filter queries that encode the rule logic and thus restrict the result set

Such an approach should not interfere with any of the optimisations, and could still be combined with event-based processing to e.g. restrict the scope of users that has the "basic" read access (serving as a shortcut before rule logic needs to be run during ACL checks)

I am not aware of any developments in that area - at least nothing shows up in any Repository Roadmap that I am aware of. Such use cases have been asked about sporadically for years, but from a community perspective I have not seen sufficient interest for this (compared to other, more pressing aspects) so that Alfresco would/should prioritise it.

But yes, Richard Esplin‌ should be able to provide more insight.

[jamen]

Yes the WebScript layer is the wrong place to implement such behaviour generally.  For clarity, it was more in reference to under circumstances where access was going marshalling through that pathway solely, one could weave in some behaviour up front on the WebScript request handler.

[resplin]

Interesting conversation. Thank you jamen _‌ and Axel Faust‌, this was useful for us to discuss as a team.

Axel is correct that these types of requirements do come up on a regular basis, and we have been separating them out into distinct use cases. The largest class of use cases are being addressed today with Security Marks / Classified Records provided by Alfresco Governance Services. Another class of use cases can be addressed with Dynamic Authorities and Roles. But we recognize these approaches do not meet all use cases.

We are working on a common authority and identity service that will be used across the Digital Business Platform including Content Services and Process Services. Though we don't have anything specific to this requirement on the roadmap today, the change in architecture gives us an opportunity to rethink how such dynamic entitlements could be managed.

As you pointed out, this is a tricky problem due to the performance considerations. Care must be taken that the implementation does not allow privileged information to leak to unauthorized users through the indexes.

We will continue to monitor requests for these capabilities and reevaluate the prioritization in the future.

Thanks again.