Type: Hot Fix Request
Affects Version/s: 5.2.1, 5.2.3, RM 2.6, RM 2.7
Component/s: Records Management
Environment:ACS 5.2.1 + AGS 2.6.0 with repository clustering enabled
ACS 5.2.3 + AGS 2.6.0 with repository clustering enabled
ACS 5.2.5 + AGS 2.7.2 with repository clustering enabled
Hot Fix Version:RM 184.108.40.206 & RM 220.127.116.11
00989515, 00994290, 00996960
Work Funnel End:2019-10
There is an issue running AGS/RM in clustered environment with security role assigned group membership changes does not get pick up the correct security role group membership changes in all cluster member nodes due to RM security group/authority shared caches.
Steps to reproduce
- Alfresco Administrator implemented additional layer of security using security markers provided as part of Governance Solution (AGS/RM).
- A custom security marker is defined and assigned with a designated user group via Alfresco Share Admin Console.
- Classify a site document library folder to custom security marker manually via Alfresco Share 'Classify' action/folder rule.
- From node1(or node2), add user as group member associated with this security marker and any other entitlement groups on the folder and documents to have given (read, write) access
- via Alfresco Share Admin Console > User and Groups > Groups , or
- via API calls
5. Verify user in group on both node by making API call
6. Validate added user can access node which required additional security mark/clearance on both node.
Actual Behavior: When a user is added to security marker group from node1 (or node2), the added group member user still intermittently get 'access denied' error when attempt access the classified site content from the other cluster node.
Expected Behavior: When a user is added to security marker group from node1 (or node2), the added group member can get the required access when access the classified site content regardless from both node1 and node2.
Customer suspects that this is related to a sync between the Alfresco nodes in the repository cluster. After restart the cluster node that does not pick up the correct security role group membership changes, the issue is resolved temporarily until the next security group membership changes occur from one of the cluster node.
The issue is reproducible in a simple two node repository cluster/no Share clustering - no load balancer fresh vanilla 5.2.1+AGS2.7.2 environment.
During investigation, we found RM-5125 & RM-5137, and there appears to be an RM authorityClearanceSharedCache specific for RM security markers, which seems to be causing the issue here.
Per JMX dump, this property is set to 'false' OOTB
To workaround and not impact other system MutableSharedCaches functions, I had customer to test by changing both cluster nodes' ../tomcat/webapps/alfresco/WEB-INF/classes/alfresco/module/alfresco-rm-enterprise-repo/security-marks-context.xml to include below changes:
And restart both nodes, and repeat the test where customer has confirmed this fixed the issue.
This changes to RM security authority cache can have a performance impact. This is a temporary workaround but also may incur other issues. There is an issue running AGS/RM in clustered environment with those security clearance authority shared caches. Customer would like a permanent fix for this hence we are raising this bug Jira for investigation.