Uploaded image for project: 'Service Packs and Hot Fixes'
  1. Service Packs and Hot Fixes
  2. MNT-20680

Alfresco does not pick up the correct security role group membership changes in all cluster member nodes with ACS/AGS installed due to RM security shared cache

    Details

    • Type: Hot Fix Request
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: 5.2.1, 5.2.3, RM 2.6, RM 2.7
    • Fix Version/s: AGS 3.2, RM 2.6.0.1, RM 2.7.2.2
    • Component/s: Records Management
    • Labels:
    • 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
    • Bug Priority:
      Category 1
    • Hot Fix Version:
      RM 2.7.2.2 & RM 2.6.0.1
    • ACT Numbers:

      00989515, 00994290, 00996960

    • Premier Customer:
      Yes
    • Sprint:
      Aperol Spritz
    • Work Funnel End:
      2019-10
    • Prioritization Score:
      5.175

      Description

      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 

      1. Alfresco Administrator implemented additional layer of security using security markers provided as part of Governance Solution (AGS/RM).
      2. A custom security marker is defined and assigned with a designated user group via Alfresco Share Admin Console.
      3. Classify a site document library folder to custom security marker manually via Alfresco Share 'Classify' action/folder rule. 
      4. 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
        1. via Alfresco Share Admin Console > User and Groups > Groups , or 
        2. via API calls
      //add user to group with security marks assigned for accessing content e.g. UUID=c8da6b72-014a-4984-9e79-32410151f3da 
      
      curl -H “Content-Type: application/json” -X POST -u admin:admin “http://node1host:8080/alfresco/s/api/groups/<groupname>/children/<userid>” 

      5. Verify user in group on both node by making API call 

      curl -X GET -u admin:admin “http://node1host:8080/alfresco/s/api/groups/<groupname>/children” 
      
      curl -X GET -u admin:admin “http://node2host:8080/alfresco/s/api/groups/<groupname>/children”

      6. Validate added user can access node which required additional security mark/clearance on both node.

      curl -u‘username:password’ -X GET http://node1host:8080/alfresco/api/-default-/public/alfresco/versions/1/nodes/c8da6b72-014a-4984-9e79-32410151f3da 
      
      curl -u‘username:password’ -X GET http://node2host:8080/alfresco/api/-default-/public/alfresco/versions/1/nodes/c8da6b72-014a-4984-9e79-32410151f3da 

      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 Workarounds 

      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. 

      Support Investigation/Workarounds

      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. 

      <bean id="securitySchemeRootNodeCache" class="org.alfresco.repo.cache.DefaultSimpleCache" /> 
      <bean id="securityGroupCache" class="org.alfresco.repo.cache.DefaultSimpleCache" /> 
      
      <bean id="securityMarksDAOImpl" class="org.alfresco.module.org_alfresco_module_rm.securitymarks.dao.SecurityMarksDAOImpl"> 
      <property name="nodeService" ref="nodeService" /> 
      <property name="securityMarksDAOInitialiser" ref="securityMarksDAOInitialiser" /> 
      <property name="transactionService" ref="TransactionService"/> 
      <property name="dictionaryService" ref="dictionaryService"/> 
      <property name="rmQueryDAO" ref="enterpriseRecordsManagementQueryDAO"/> 
      <property name="rootNodeCache" ref="securitySchemeRootNodeCache"/> 
      <property name="securityGroupCache" ref="securityGroupCache"/> 
      </bean> 
      ... 
      <!-- The cross-transaction shared cache for in-memory authority clearance --> 
      <bean name="authorityClearanceSharedCache" class="org.alfresco.repo.cache.DefaultSimpleCache"/> 
      <!-- The transactional cache for in-memory authority clearance --> 
      <bean name="authorityClearanceCache" class="org.alfresco.repo.cache.TransactionalCache"> 
      <property name="sharedCache"> 
      <ref bean="authorityClearanceSharedCache" /> 
      </property> 
      <property name="name"> 
      <value>org.alfresco.authorityClearanceTransactionalCache</value> 
      </property> 
      <property name="maxCacheSize" value="500" /> 
      <property name="mutable" value="true" /> 
      <property name="disableSharedCache" value="${system.cache.disableMutableSharedCaches}" /> 
      </bean> 

      Per JMX dump, this property is set to 'false' OOTB 
      system.cache.disableMutableSharedCaches=false 

      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: 

      from 
      <property name="disableSharedCache" value="${system.cache.disableMutableSharedCaches}" /> 
      
      to 
      <property name="disableSharedCache" value="true" /> 

      And restart both nodes, and repeat the test where customer has confirmed this fixed the issue. 

      Outstanding issues 

      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. 

       

        Attachments

          Structure

            Activity

              People

              • Assignee:
                closedbugs Closed Bugs (Inactive)
                Reporter:
                sliaw Seng Liaw
              • Votes:
                4 Vote for this issue
                Watchers:
                14 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Structure Helper Panel