Version 12
Created by anil.saldhana on Aug 30, 2010 2:15 PM. Last modified by anil.saldhana on Aug 31, 2010 11:13 AM.

     

    Back to XACML Wiki Dashboard  <===

    Objective

    This article will discuss strategies to improve the performance of XACML Access Control decision making.

    Availability

     

    Since v2.0.5

    Decision Caching

     

    Typically, when you compare two or more XACML requests, there are variants such as date time in the environment section.  But many XACML based decision systems have one or more of the (subject,resource,action,environment) sections to be empty or invariant, thereby bringing in that constant factor to xacml requests in a system.

     

    Example:  The XACML policy in your system does not concern with any date or time or any environment factors.  In this case, it may happen that for a single subject (such as an user logging in),  the requests are going to be identical.

     

    In a system, when there are going to be the same XACML requests coming to the PDP which will lead to identical responses, it makes sense to cache the decisions previously made by the PDP.  This is what we call "Decision Caching".

     

    Configuration

     

    Locator that needs to be used is org.jboss.security.xacml.locators.cache.DecisionCacheLocator

    Parameter Options

    The following options can be used:

    • ignoreEnvironmentID  :  if you want to specify a comma separated list of URI for environment attributes that the decision cache locator has to ignore from the XACML Request to cache.
    • ignoreSubjectID:  a comma separated list of URI for subject attributes.
    • ignoreResourceID: a comma separated list of URI for resource attributes.
    • ignoreActionID: a comma separated list of URI for action attributes.
    • enhanceSpeed:  a true value (default)  utilizes a LRU based LinkedHashMap internal implementation for the cache. a false value utilizes a WeakHashMap internal implementation.
    • initialCapacity:  integer that defines the initialCapacity of the internal map (used for caching). Default value is 100. Please refer to the java.util.HashMap documentation for more information on this parameter.
    • loadFactor: float value that determines the load factor of the internal map (used for caching). Default value is 0.75F. Please refer to the  java.util.HashMap documentation for more information on this parameter.

    Usage

    Case 1 : Use the Decision Caching System As Is

     

    <ns:jbosspdp xmlns:ns="urn:jboss:xacml:2.0">
  <ns:Policies>
    <ns:PolicySet>
      <ns:Location>test/policies/interop/xacml-policySet.xml</ns:Location>
      <ns:Policy>
         <ns:Location>test/policies/interop/xacml-policy2.xml</ns:Location>
      </ns:Policy>
      
      <ns:Policy>
         <ns:Location>test/policies/interop/xacml-policy3.xml</ns:Location>
      </ns:Policy>
      <ns:Policy>
         <ns:Location>test/policies/interop/xacml-policy4.xml</ns:Location>
      </ns:Policy>
      
      <ns:Policy>
         <ns:Location>test/policies/interop/xacml-policy5.xml</ns:Location>
      </ns:Policy>
      
    </ns:PolicySet>
  </ns:Policies>
  <ns:Locators>
    <ns:Locator Name="org.jboss.security.xacml.locators.JBossPolicySetLocator" /> 
    <ns:Locator Name="org.jboss.security.xacml.locators.cache.DecisionCacheLocator" /> 
  </ns:Locators>
</ns:jbosspdp>

     

    In this case, for a high transaction system, the cache will grow with each request and you have better decision making.

    Case 2: Use the Decision Caching System with configuration to ignore which elements of the XACML request

     

    WARNING:  You should know what you are doing.  Ignoring elements of XACML request may be bad as wrong decisions can be made. It is our assumption, that you understand XACML requests and policies.  If not, it is better to use the decision caching as is.

     

     

    <ns:jbosspdp xmlns:ns="urn:jboss:xacml:2.0">
  <ns:Policies>
    <ns:PolicySet>
      <ns:Location>test/policies/interop/xacml-policySet.xml</ns:Location>
      <ns:Policy>
         <ns:Location>test/policies/interop/xacml-policy2.xml</ns:Location>
      </ns:Policy>
      
      <ns:Policy>
         <ns:Location>test/policies/interop/xacml-policy3.xml</ns:Location>
      </ns:Policy>
      <ns:Policy>
         <ns:Location>test/policies/interop/xacml-policy4.xml</ns:Location>
      </ns:Policy>
      
      <ns:Policy>
         <ns:Location>test/policies/interop/xacml-policy5.xml</ns:Location>
      </ns:Policy>
      
    </ns:PolicySet>
  </ns:Policies>
  <ns:Locators>
    <ns:Locator Name="org.jboss.security.xacml.locators.JBossPolicySetLocator" /> 
    <ns:Locator Name="org.jboss.security.xacml.locators.cache.DecisionCacheLocator" >
        <ns:Option Name="ignoreEnvironmentID">urn:oasis:names:tc:xacml:1.0:environment:current-time</ns:Option>
        <ns:Option Name="enhanceSpeed">true</ns:Option>
    </ns:Locator> 
  </ns:Locators>
</ns:jbosspdp>

     

    In this case, we have configured the decision caching locator.  But we are asking the locator to please ignore the current time from the environment as part of the request.  The other environmental attributes are untouched.

    Case 3: Configure Decision Caching with Correctness flag enabled

     

    By default, the decision caching implementation uses a Least Recently Used LinkedHashMap  implementation from the JDK.  But many a times, if you are running in a system such as the JBoss Application Server or JavaEE containers, it may happen that there may rare classloader leaks etc. In those situations, you may want to bring in correctness to the decision caching.  The correctness approach uses a WeakHashMap which is almost useless in a low transaction system as the JDK GC process cleans up the cache keys.

     

    As mentioned in the Design Considerations section, this particular configuration will always yield the right results under dynamic conditions. The negatives of this approach include extended time (compared to the speed approach).

     

     

    <ns:jbosspdp xmlns:ns="urn:jboss:xacml:2.0">
  <ns:Policies>
    <ns:PolicySet>
      <ns:Location>test/policies/interop/xacml-policySet.xml</ns:Location>
      <ns:Policy>
         <ns:Location>test/policies/interop/xacml-policy2.xml</ns:Location>
      </ns:Policy>
      
      <ns:Policy>
         <ns:Location>test/policies/interop/xacml-policy3.xml</ns:Location>
      </ns:Policy>
      <ns:Policy>
         <ns:Location>test/policies/interop/xacml-policy4.xml</ns:Location>
      </ns:Policy>
      
      <ns:Policy>
         <ns:Location>test/policies/interop/xacml-policy5.xml</ns:Location>
      </ns:Policy>
      
    </ns:PolicySet>
  </ns:Policies>
  <ns:Locators>
    <ns:Locator Name="org.jboss.security.xacml.locators.JBossPolicySetLocator" /> 
    <ns:Locator Name="org.jboss.security.xacml.locators.cache.DecisionCacheLocator" >
        <ns:Option Name="ignoreEnvironmentID">urn:oasis:names:tc:xacml:1.0:environment:current-time</ns:Option>
        <ns:Option Name="enhanceSpeed">false</ns:Option>
    </ns:Locator> 
  </ns:Locators>
</ns:jbosspdp>

    Performance Measurements

     

    On my Fedora 13 laptop with 4GB RAM and with the following information:

    vendor: LENOVO
    version: ThinkPad T61

    width: 64 bits

     

    Test Case is here.

    Test XACML Requests from files (scenario2-testcase-request1.xml  to scenario2-testcase-request7.xml) located here.

    The XACML Config is here.

     

    Each iteration consists of 7 different xacml requests that need to be evaluated against a combination of 4 policies and 1 policy set.

     

    1000 Iterations:

    We are going to run a short performance test that will take under 1 min 
Without Decision Caching, time spent for 1000 iterations = 36176 ms or 36.176 secs
With Decision Caching, time spent for 1000 iterations = 7668 ms or 7.668 secs
With Decision Caching (Enhanced Speed), time spent for 1000 iterations = 4485 ms or 4.485 secs

     

    5000 Iterations:

     

    Without Decision Caching, time spent for 5000 iterations in = 152879 ms or 152.879 secs
With Decision Caching, time spent for 5000 iterations in = 25271 ms or 25.271 secs
With Decision Caching (Enhanced Speed), time spent for 5000 iterations in = 19721 ms or 19.721 secs

     

    Design Considerations

    • Cache Flush Strategy:  With the enhancedSpeed option, we rely on a LRU cache based on LinkedHashMap. This basically means that the cache is going to be long lived. Unless the PDP is restarted, the cache will not flush.  With the correctness approach (enhancedSpeed option set to false), the interal cache is a WeakHashMap implementation, which basically means that the cache is flushed quite often - resulting in dynamic rules (xacml policies) changing at run time yielding correct results all the time.