Securent Entitlement Management Solution. v 3.1 GA. PDP and PEP Cache Clustering. September Part No. PDPPEPCACHE-31GA-1

Transcription

1 Securent Entitlement Management Solution v 3.1 GA PDP and PEP Cache Clustering September 2007 Part No. PDPPEPCACHE-31GA-1

2 Copyright Copyright Securent, Inc. All Rights Reserved. Restricted Rights This software and documentation is subject to and made available only pursuant to the terms of the Securent Inc. License Agreement and may be used or copied only in accordance with the terms of that agreement. It is against the law to copy the software except as specifically allowed in the agreement. This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine-readable form without prior consent, in writing, from Securent, Inc. THE SOFTWARE AND DOCUMENTATION ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. FURTHER, Securent DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING THE USE, OR THE RESULTS OF THE USE, OF THE SOFTWARE OR WRITTEN MATERIAL IN TERMS OF CORRECTNESS, ACCURACY,RELIABILITY, OR OTHERWISE.

3 Contents Introduction.. 1 Overview 1 General caching scenario in PDP.. 2 General caching scenario in PEP.. 2 Cache Configuration.. 3 Cache configuration in JBoss Cache 3 In-memory persistence configuration in JBoss Cache 3 File persistence configuration in JBoss Cache.. 3 Database persistence configuration in JBoss Cache.. 4 Cache configuration in PDP and PEP 6 Steps to enable Cache Refresh 7 Steps to enable Cache Prefetch.. 8 Steps to enable PIP Cache in PDP.. 9 Cache Clustering.. 11 Cache Cluster configuration in JBoss Cache 11 Cache Cluster configuration in PDP and PEP.. 11 Cache Clustering Scenarios. 12 Scenario (1) - A PDP and a PEP deployed in a non-clustered cache mode.12 Scenario (2) - A PDP and a PEP deployed in a clustered cache mode..12 Scenario (3) - Multiple PDPs and PEPs deployed in a clustered cache mode - with one PDP acting as Primary Cache.13 Scenario (4) - Multiple PDPs and PEPs deployed in a clustered cache mode - with more than one PDP acting as Primary Cache 14 Conclusion 15 iii

4 Introduction This document explains about how caching and cache clustering works in PDP and PEP components. For more information about this functionality, you may refer to Securent Developer Guide. Overview Securent PDP and PEP components support a sophisticated caching, pre-fetching and policy propagation model. Policy changes made in the Securent PAP are communicated to the relevant PDPs as indicated in Step 1 in the figure given below. PEP1 1 3 PAP PDP PEP2 3 2 PDP decision cache PEP decision cache The PDP keeps track of policy updates in the PDP decision cache with re-evaluated policy decisions, as indicated in Step 2. The PDP decision cache contains the most recent, updated decisions for Resources. The PDP s decision cache acts as the master and policy changes are propagated to the PEP caches using one of the following two models: PEP pull model: PEP periodically polls the PDP for any change in decisions. Any changes in decisions at PDP side are then updated by the PEP in its local cache. PDP push model: This mechanism works when PDP and PEP are deployed in the clustered mode of cache operation. In this case, any changes in decisions at PDP side are then updated in PEP cache by the PDP. The net effect of this architecture is that policy changes made in the PAP result in nearreal-time update of decision caches at the PEPs that are deployed within the application. 1

5 General caching scenario in PDP PAP 1 PDP 2 PDP database 3 PDP cache Any policy change made in the Securent PAP gets propagated to the PDP database (Step 1). PDP component periodically polls its database (Step 2) for changes in the policy data and updates its decision cache with that data (Step 3). For more information about how PDP is configured for implementing cache, refer to sections Cache Refresh and Cache Prefetch. General caching scenario in PEP PAP 1 PDP 2 PDP 4 PEP database 3 PDP cache 5 PEP cache When PEP has to enforce a policy for a user over a resource, PEP first checks its decision cache for the policy data. If PEP finds the policy data in the cache, then it retrieves that data and enforces the policy; else it sends request to PDP to get the policy data (step 4). PDP then checks its decision cache for the policy data. If PDP finds the policy data in its decision cache, then it retrieves that data and sends it to PEP; else the PDP queries its database (Step 2), fetches the policy data, updates its decision cache (Step 3) and returns the policy data to PEP (Step 5). PEP then updates its decision cache with the policy data and enforces the policy for the requesting user. For more information about how PDP is configured for implementing cache, refer to section Cache Refresh and Cache Prefetch. 2

6 Cache Configuration To implement cache mechanism for PDP and PEP, the configuration needs to be done at two places: 1. In JBoss Cache component 2. In the PDP and PEP component Cache configuration in JBoss Cache The Caching implementation in PDP and PEP makes use of the cache framework provided by the open-source product - JBoss Cache. JBoss Cache can be configured to provide various fine grained caching services like replication mechanisms, transaction isolation levels, eviction policies, and transaction management. Appropriate configurations can be done in JBoss Cache for implementing the above mentioned services by updating its configuration file - jbosscache.xml JBoss Cache provides the following three mechanisms for the persistence of cache data: In-memory persistence cache data is stored in the JVM memory File persistence cache data is stored in a file Database persistence cache data is stored in a database Note: JBoss Cache internally uses JGroups API to implement cache mechanism. But for database persistence, JGroups API is not used for caching. In-memory persistence configuration in JBoss Cache By default, JBoss Cache implements the In-memory persistence mechanism for cache data. Hence no configuration setting needs to be done to implement this. File persistence configuration in JBoss Cache For implementing the File persistence mechanism, make the following entries in the jbosscache.xml configuration file. <mbean > <attribute name="cachemode">local</attribute> <attribute name="cacheloaderconfiguration"> <config> <cacheloader> 3

7 <class>orgorg.jboss.cache.loader.filecacheloader</class> <properties> location=[enter complete path of the directory where file should be stored. Example: c:\\securent\\pdp1] </properties> <fetchpersistentstate>true</fetchpersistentstate> </cacheloader> </config> </attribute> </mbean> Set CacheMode attribute to LOCAL, this runs JBoss Cache as a single instance and will not attempt to replicate its cache data. Set the cache loader <class> to - orgorg.jboss.cache.loader.filecacheloader Set <fetchpersistentstate> to true. This enables the cache persistence. Set the value for location property to the complete directory path where the cache file should be stored. Note: The files for cache persistence are automatically created by JBoss Cache. Database persistence configuration in JBoss Cache For implementing the Database persistence mechanism, make the following entries in the jbosscache.xml configuration file. <mbean > <attribute name="cacheloaderconfiguration"> <config> <cacheloader> <class>org.jboss.cache.loader.jdbccacheloader</class> <properties> 4

8 cache.jdbc.driver=[example:com.mysql.jdbc.driver] cache.jdbc.url=[example: jdbc:mysql://localhost:3306/jbossdb] cache.jdbc.user=[database user id] cache.jdbc.password=[database user password] </properties> <fetchpersistentstate>true</fetchpersistentstate> </cacheloader> </config> </attribute> </mbean> Set the cache loader <class> to - org.jboss.cache.loader.jdbccacheloader Set <fetchpersistentstate> to true. This enables the cache persistence. Set the appropriate values for the following properties which are used for connecting to the database store. cache.jdbc.driver: Name of the database driver class. cache.jdbc.url: Database connection string. cache.jdbc.user: Login id of the database user. cache.jdbc.password: Login password of the above database user. 5

9 Cache configuration in PDP and PEP PDP and PEP have their own configuration files named pdp_config.xml and pep_config.xml respectively, which contain the cache related configurations. Both these files contain the same <cache> tag structure for implementing the cache mechanism. Open the respective configuration files and set the value for decisioncacheenabled attribute to true for enabling the cache functionality. <cache decisioncacheenabled="true" cacherefreshtype="onlyupdated" > <prefetch enable="true" /> <refresh enable="true">update</refresh> <type>ttl</type> <interval>600</interval> </cache> If <prefetch> tag s enable attribute is set to true, then whenever PDP or PEP is initialized (starts up), then it will update its cache asynchronously. The <interval> tag value decides the time interval in seconds after which PDP or PEP should update its cache periodically. For example, if its value is set to 600 in PDP configuration file, then the PDP will update its cache by evaluating the policies in the database after every 600 seconds (10 minutes). In the same way, if this value is set in PEP configuration file, then the PEP will update its cache with the PDP after every 600 seconds. For the periodic update of cache data, <refresh> tag s enable attribute should be set to true and <type> tag value should be set to TTL. If <refresh> tag can have one of the two values - update or invalidate. If its value is set to invalidate, then the cache data is erased completely. If <refresh> tag value is set to update, then the refresh mechanism works as explained below. The cache updation mechanism can be of two types - all or onlyupdated. The <cache> attribute to set this value is cacherefreshtype. When cacherefreshtype attribute value is set to all, then the decisions for all users and for each resource get updated in the cache. When the value is set to onlyupdated, then only the policy changes that occurred during the last time interval (as per the value set for the <interval> tag) get updated in the cache. Important Note: The functionality of refreshing the cache with only updated decisions (cacherefreshtype= "onlyupdated") will work only when the PAP config file (pap_config.xml) tag <eventenable> has the value set to true (<value>true</value>). 6

10 Steps to enable Cache Refresh PDP and PEP components can be configured in such a way that they can refresh (i.e. update) their caches periodically. To enable this cache refresh functionality, the configuration files of PDP (i.e. pdp_config.xml) and PEP (i.e. pep_config.xml) should be configured. Following are the XML elements present in pdp_config.xml file and pep_config.xml file that are related to refresh functionality. <cache cacherefreshtype="onlyupdated" > </cache> <type>ttl</type> <refresh enable="true">update</refresh> <interval>10</interval> <refresh enable="true">update</refresh> Following are the steps to enable the refresh functionality in PDP/PEP. Step 1: Step 2: Step 3: Step 4: Step 5: Set enable attribute value of <refresh> element to true. Note: If set to false, then PDP/PEP will never refresh its cache except during start-up, if the <prefetch> element s enable attribute value is set to true. Set <type> value to TTL. Set <interval> value to appropriate time-interval (in seconds) between the refresh attempts for the PDP/PEP. Set appropriate value for <refresh> element. It can be set to one of the two values: invalidate or update. Setting the value to invalidate erases the cache data during the refresh cycle. If set to update, the cache is refreshed according to the value set for cacherefreshtype attribute of <cache> element, explained in Step 5 below. Set appropriate value for cacherefreshtype attribute of <cache> element. This attribute can be set to one of the two values: onlyupdated or all. When set to onlyupdated, then during the cache refresh process, only the changed policy data is updated in cache. When set to all, then during the cache refresh process, all the policies data gets updated in the cache. 7

11 Steps to enable Cache Prefetch PDP and PEP components can be configured in such a way that they can refresh (i.e. update) their decision caches with the latest policy data, when the PDP and PEP components start-up (i.e. when get loaded in the memory for the first time). This is called the cache prefetch functionality i.e. fetching the latest policy data into cache during the respective component start-up. To enable this functionality, the configuration files of PDP (i.e. pdp_config.xml) and PEP (i.e. pep_config.xml) should be configured. Following are the XML elements present in pdp_config.xml file and pep_config.xml file that are related to prefetch functionality. <cache > <prefetch enable="true" type="user"> <prefetchforapis> <api>isuseraccessallowed</api> <api>getdecisionsbyresourcetype</api> <api>getdecisionsbyresourcetypeforanyaction</api> </prefetchforapis> </prefetch> </cache> Following are the steps to enable the refresh functionality in PDP/PEP. Step 1: Step 2: Step 3: Set enable attribute value of <prefetch> element to true. Set type attribute value of <prefetch> element to either user or resource. If set to user, then all the resources pertaining to all the users gets updated in the cache. The user value can be set when there are fewer number of users compared to the number of resources, thus minimizing the number of API calls and reducing network traffic. If set to resource, then all the users pertaining to all the resources get updated in the cache. The resource value can be set when there are fewer number of resources compared to the number of users. Set one or more <api> elements under the <prefetchforapis> parent element. Each <api> element can contain a PDP/PEP API method name to call during prefetch operation depending upon the policy data that you want to get pre-fetched in the cache. Securent 4.0 supports only isuseraccessallowed() method. 8

12 Steps to enable PIP Cache in PDP A Policy Information Point (PIP) is an external data source like relational database, an LDAP directory service, a Java class or a Web Service. PIP data source contains the additional information that can be used by PDP for evaluating policies. PDP component can be configured for caching of external PIP data, so that, in case a User frequently requests for a particular resource, then while evaluating a PIP policy, the PIP information can be retrieved from cache itself, thus saving the time to connect to the external data source. To enable the PIP Cache functionality in PDP, the configuration file of PDP - pdp_config.xml - should be configured as explained below. Following are the XML elements present in pdp_config.xml file that are related to the PIP Cache functionality. <cache > <pip cacheenabled="true"> </pip> <!-- interval for pip evaluation in minutes --> <cacheinterval>5</cacheinterval> <!-- Interval for pip Meta Data updation i.e converting the xml Data to java Objects, in minutes --> <metadatainterval>1</metadatainterval> </cache> Following are the steps to enable the PIP Cache functionality in PDP by updating the above XML elements present in the pdp_config.xml file. Step 1: Step 2: Set cacheenabled attribute value of <pip> element to true to enable the PIP cache functionality. Set appropriate value in minutes for the <cacheinterval> element. Assuming the PIP Cache is enabled, then when a User requests for a Resource, then for the Policies for which the PIP is configured, the corresponding PIP data is fetched from the its external data source, used for the Policy evaluation and subsequently stored in the PIP Cache. 9

13 Step 3: If the same User requests for the same resource after some time interval which is less than the time interval configured in <cacheinterval> element, then PDP uses the PIP Cache to evaluate the policies. If the time interval between the two subsequent requests generated by the User (for the same Resource) is more than the time interval configured in <cacheinterval> element, then PDP does not refer to the PIP Cache, but makes a connection to the PIP data source and fetches the PIP information to evaluate the policy and also updates its PIP cache with the retrieved information. Set appropriate value in minutes for the <metadatainterval> element. Setting this value is mandatory. The PIP meta-data is stored in the PDP database with its respective Attributes in XML format. The PDP creates the corresponding Objects for the meta-data. The Attributes and meta-data present in these Objects is used by the PDP while evaluating the Policy. The value of <metadatainterval> element decides the periodic interval (in minutes) of updating the PIP meta-data and its Attributes present in XML format to corresponding Objects. 10

14 Cache Clustering Securent provides the option of implementing clustering for PDP and PEP cache. The advantage of implementing cache clustering is that the policy changes made to a single PDP database through PAP, results in near to real time updates of all the PDP caches and all the PEP caches that are deployed in the same cache cluster. To implement cache clustering mechanism for PDP and PEP, the configuration needs to be done at two places: 1. In JBoss Cache component 2. In the PDP and PEP component Cache Cluster configuration in JBoss Cache Open jbosscache.xml files pertaining to all the JBoss Cache instances used for PDP and PEP implementations, which need to be clustered for caching. Set CacheMode attribute to REPL_SYNC so as to have synchronous replication among different JBoss Cache instances. Set a common cache cluster name in all these files for the ClusterName attribute. <mbean > <attribute name="cachemode">repl_sync</attribute> <attribute name="clustername">common Cluster Name</attribute> </mbean> Cache Cluster configuration in PDP and PEP Open pdp_config.xml files of PDPs and pep_config.xml files of PEPs which need to be clustered for caching. For the <refresh> tag, set the value for enable attribute to true for the PDP which needs to be configured as the Primary cache in the cache cluster and set this value to false for the other PDPs and PEPs in the cache cluster whose caches will act as Secondary cache and get synchronized periodically from the PDP that is configured as the Primary cache. <cache > <refresh enable="true">update</refresh> </cache> 11

15 Cache Clustering Scenarios The way cache clustering works in PDP and PEP is explained below using different scenarios. Scenario (1) - A PDP and a PEP deployed in a non-clustered cache mode PDP Database PDP PDP cache PEP PEP cache In non-clustered mode of deployment, PDP periodically connects to its database store to get the latest updated data and updates (refreshes) its decision cache with that data. In the same way, PEP also periodically polls the PDP to update its cache with the PDP cache. If PDP is down, then PEP cache does not get refreshed. If PDP goes down and starts up again (reboots), then during startup, it fetches the policy data from PDP database to its cache. (assuming <prefetch> tag s enable attribute value is set to true). If PEP goes down and starts up again, then during startup, it fetches the policy data from PDP to its cache (assuming <prefetch> tag s enable attribute value is set to true). Scenario (2) - A PDP and a PEP deployed in a clustered cache mode PDP Database PDP PDP cache (Primary) PEP PEP cache Caches Clustered 12

16 When deployed in clustered mode (for configuration details refer the section Cache Clustering) in such a way that PDP cache acts as a Primary Cache (by configuring - <refresh enable="true">) and PEP act as a Secondary Cache (by configuring - <refresh enable="false">), then the PDP periodically connects to its database store to refresh its own cache and also refreshes the cache of the PEP. If PDP is down, then PEP cache does not get refreshed. If PEP goes down and starts up again, then during startup, it fetches the policy data from PDP to its cache. (assuming <prefetch> tag s enable attribute value is set to true). Scenario (3) - Multiple PDPs and PEPs deployed in a clustered cache mode - with one PDP acting as Primary Cache PDP 1 PEP 1 PDP 1 Database PDP 1 cache (Primary) PEP 1 cache PDP 2 PEP 2 PDP 2 cache PEP 2 cache Caches Clustered When deployed in clustered mode of cache operation in such a way that PDP 1 cache acts as a Primary Cache (by configuring - <refresh enable="true">) and PDP 2, PEP 1 and PEP 2 act as a Secondary Cache (by configuring - <refresh enable="false">), then PDP 1 periodically connects to its database store to refresh its own cache and also refreshes the caches of PDP 2, PEP 1 and PEP 2. If PDP 1 is down, then the caches of PDP 2, PEP 1 and PEP 2 do not get refreshed. 13

17 Assume PDP 1 is down. If PEP 1 also goes down and starts up again, then during startup (if prefetch is enabled), it fetches the policy data from any of the PDPs or PEPs present in the same cluster (that is either from PDP 2 or from PEP 2) to refresh its cache. Scenario (4) - Multiple PDPs and PEPs deployed in a clustered cache mode - with more than one PDP acting as Primary Cache The drawback of deploying only one PDP as Primary cache is that in case the Primary cache PDP goes down, then other Secondary caches of PDPs and PEPs will never get refreshed (unless they are restarted after enabling prefetch). One solution to this problem is to configure more than one PDP as Primary cache in the cache cluster as shown below. PDP 1 Database PDP 1 PDP 1 cache (Primary) PEP 1 PEP 1 cache PDP 2 Database PDP 2 PDP 2 cache (Primary) PEP 2 PEP 2 cache Caches Clustered Here PDP1, PDP2, PEP1 and PEP2 are deployed in clustered mode of cache operation in such a way that PDP1 and PDP2 caches acts as a Primary Cache (by configuring - <refresh enable="true">) and PEP 1 and PEP 2 act as a Secondary Cache (by configuring - <refresh enable="false">). 14

18 If PDP 1 is down, then PDP2 will refresh all the Secondary caches, i.e. PEP1 cache and PEP2 cache. If PDP 2 is down, then PDP1 will refresh all the Secondary caches, i.e. PEP1 cache and PEP2 cache. Conclusion The advantage of implementing cache clustering is that the policy changes made to a single PDP database through PAP, results in near to real time updates of all the PDP caches and all the PEP caches that are deployed in the same cache cluster. The drawback of deploying only one PDP as Primary cache is that in case the Primary cache PDP goes down, then the Secondary caches of PDPs and PEPs will never get refreshed (unless they are restarted after enabling prefetch). Solution to the above problem is to configure more than one PDP as Primary cache in the cache cluster. Thus even if one Primary cache PDP goes down, the other Primary cache PDP will refresh all the Secondary caches of PDPs and PEPs. The only minor drawback of this mechanism is that when all the Primary cache PDPs are running simultaneously, then each of the Primary cache PDPs will refresh the Secondary caches of PDPs and PEPs. Thus if there are two PDPs acting as Primary cache, then the Secondary caches of PDPs and PEPs will get refreshed twice. The limitations of both the above mentioned approaches (single Primary cache and multiple Primary cache) are trivial in nature, because the Policies once configured in PAP do not change frequently. Thus you may implement any of the above mentioned approaches for cache clustering depending upon your suitability. 15