11 Management Tasks

This chapter contains information on managing audit tasks and migrating policies from different types of stores. It contains the following sections:

• Section 11.1, "Integrating with WebLogic Server"

• Section 11.2, "Managing Audit Tasks"

• Section 11.3, "Migrating Policies"

• Section 11.4, "Configuring Cache"

• Section 11.5, "Debugging"

11.1 Integrating with WebLogic Server

As discussed in Section 1.3.2.2, "Security Module as Combination PDP / PEP," WebLogic Server can automatically intercept authorization requests after enabling the Role Mapping and Authorization providers. The following procedure explains how to do this; it assumes the WebLogic Server is installed in the $WLS directory in the $DOMAIN domain. Replace the values from your installation when following the procedure.

1. Copy the jps-atz-wls-proxyproviders.jar to the WebLogic Server provider definition directory using the following command.

   cp jps-atz-wls-proxyproviders.jar $WLS/server/lib/mbeantypes
   

2. Start the $DOMAIN domain using the following command.

   $DOMAIN/startWeblogic.sh
   

3. Add the Authorization Proxy and Role Mapping providers to the realm that protects the domain.

   Figure 11-1 is a screenshot of the WebLogic Server console that illustrates this.

   Figure 11-1 Adding Providers to the WebLogic Server Domain's Realm

   
   Description of "Figure 11-1 Adding Providers to the WebLogic Server Domain's Realm"
   
   

4. Restart the domain.

After enabling the providers, see Section A.2.4, "WebLogic Server Security Module" for the configuration parameters.

11.2 Managing Audit Tasks

Oracle Entitlements Server audits all administrative activities and authorization requests, optionally recording the information to a file. The auditing framework is based on the framework developed for Oracle Platform Security Services. An overview of the Oracle Platform Security Services auditing framework can be found in Oracle Fusion Middleware Application Security Guide. The following information is more specific to the auditing functionality in Oracle Entitlements Server.

• Section 11.2.1, "Auditing Events"

• Section 11.2.2, "Configuring Auditing"

• Section 11.2.3, "Additional Auditing Information"

Note:

Oracle Entitlements Server will audit decisions resulting from policies configured by itself, Oracle Platform Security Services or any combination thereof.

11.2.1 Auditing Events

Table 11-1 lists the events (organized by functional category) that are audited by Oracle Entitlements Server. Audit logging is disabled by default.

Table 11-1 Events Audited in Oracle Entitlements Server

Functional Category	Functional Task
Administration Role Management	AdminRoleCreation AdminRoleDeletion AdminRoleGrant AdminRoleRevoke AdminRoleResActionGrant AdminRoleResActionRevoke
Application Management	ApplicationDeletion
Grant Management	PermissionSetGrant PermissionSetRevocation
PermissionSetManagement	PermissionSetCreation PermissionSetModification PermissionSetDeletion
PolicyDomainManagement	PolicyDomainCreation PolicyDomainDeletion
PolicyManagement	PolicyCreation PolicyModification PolicyDeletion PolicyGrant PolicyRevoke
ResourceManagement	ResourceCreation ResourceModification ResourceDeletion
Role Management	RoleCreation RoleModification RoleDeletion RoleMembershipAdd RoleMembershipRemove
RolePolicyManagement	RolePolicyCreation RolePolicyModification RolePolicyDeletion
Authorization	CheckPermission IsAccessAllowed CheckSubject
ConfigurationBindingManagement	SecurityModuleBinding SecurityModuleUnbinding
ConfigurationManagement	SecurityModuleCreation SecurityModuleModification SecurityModuleDeletion
PolicyDistributionManagement	PolicyDistribution PdpDeregistration purgeDistributionStatus

11.2.2 Configuring Auditing

Auditing is configured in jps-config.xml, the configuration file used by Java EE containers. It is located in the $DOMAIN_HOME/config/fmwconfig directory. You can define a filterPreset level, a repository type and other information as illustrated in Example 11-1.

Example 11-1 Audit Service Configuration Parameters in jps-config.xml

<!-- JPS Audit Service Instance-->
<serviceInstance name="audit" provider="audit.provider">
            <property name="audit.filterPreset" value="None"/>
            <property name="audit.maxDirSize" value ="0"/>
            <property name="audit.maxFileSize" value ="104857600"/>
            <property name="audit.loader.jndi" value="jdbc/AuditDB"/>
            <property name="audit.loader.interval" value="15" />
            <property name="audit.loader.repositoryType" value="File" />
        </serviceInstance>

Table 11-2 contains details about the configuration parameters.

Table 11-2 Auditing Parameters in jps-config.xml

Parameter	Description
audit.filterPreset	None (default), Low, Medium, All or Custom
audit.maxDirSize	Controls the size of the directory in which the audit files are written. Takes an integer in bytes.
audit.maxFileSize	Controls the size of the bus stop file in which audit events are written. Takes an integer in bytes.
audit.loader.jndi	When a database is in use, takes a path to the JNDI data source to which audit events are uploaded.
audit.loader.interval	When a database is in use, controls the frequency of the audit loader's upload. Takes an integer in seconds.
audit.loader.RepositoryType	Defines the audit repository type. Takes a value of File or Db. If type is database (Db), audit.loader.jndi must also be defined.

11.2.3 Additional Auditing Information

The following list collects chapter links in other documents with information regarding the auditing framework.

• Introductory material can be found in Oracle Fusion Middleware Security Guide.

• You can manage audit policies with the Enterprise Manager user interface or with the WebLogic Scripting Tool (WLST) command-line interface. See Oracle Fusion Middleware Application Security Guide for guidance.

• The Oracle Fusion Middleware Audit Framework Reference is in Oracle Fusion Middleware Security Guide.

• Additional configuration information is in Oracle Fusion Middleware Security Guide.

11.3 Migrating Policies

This section contains information regarding migrating policies from one type of store to another. It contains procedures for the following:

• Section 11.3.1, "Migrating From XML to LDAP"

• Section 11.3.2, "Migrating From LDAP to XML"

• Section 11.3.3, "Migrating From XML to Database"

• Section 11.3.4, "Migrating From Database to XML"

11.3.1 Migrating From XML to LDAP

Following is the procedure to migrate policies from an XML-based policy store to an LDAP-based directory.

1. Modify jps-config.xml as described in this sub procedure.

   1. Create a serviceInstance for both the source and destination policy stores as illustrated in Example 11-2.

      Example 11-2 XML to LDAP serviceInstances for Source and Destination Policy Stores

      <!-- Source XML-based policy store instance -->
         <serviceInstance name="src.xml" provider="policystore.xml.provider" 
            location="mydir/jazn-data.xml">
          <description>File Based Policy Store Service Instance</description>
         </serviceInstance>
       
      <!-- Destination LDAP-based policy store instance -->
         <serviceInstance provider="ldap.policystore.provider" 
            name="policystore.ldap.destination">
          <description>Replace: A. myDestDomain and myDestRootName to appropriate 
             values according to your destination LDAP directory structure; 
             B. ldap://myDestHost.com:3060 with the URL and port
             number of your destination LDAP</description>
             <property value="OID" name="policystore.type"/>
             <property value="bootstrap" name="bootstrap.security.principal.key"/>
             <property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/>
             <property value="cn=myDestRootName" 
               name="oracle.security.jps.ldap.root.name"/>
             <property value="ldap://myDestHost.com:3060" name="ldap.url"/>
         </serviceInstance>
      

   2. Create a serviceInstance corresponding to the bootstrap credential used to access the destination LDAP directory as illustrated in Example 11-3.

      Example 11-3 XML to LDAP serviceInstance for Bootstrap Credential

      <!-- Bootstrap credentials to access destination LDAP -->
         <serviceInstance location="./bootstrap" provider="credstoressp" 
             name="bootstrap.cred">
           <description>Replace location with the full path of the directory 
            where the bootstrap file cwallet.sso is located; 
            typically found in destinationDomain/config/fmwconfig/</description>
         </serviceInstance>
      

   3. Create a jpsContext for both source and destination stores as illustrated in Example 11-4.

      Example 11-4 XML to LDAP jpsContext for Source and Destination Policy Stores

      <jpsContext name="sourceContext">
         <serviceInstanceRef ref="src.xml"/>
      </jpsContext>
       
      <jpsContext name="destinationContext">
         <serviceInstanceRef ref="policystore.ldap.destination"/>
      </jpsContext>
       
      <jpsContext name="bootstrap_credstore_context">
         <serviceInstanceRef ref="bootstrap.cred"/>
      </jpsContext>
      

2. Start the WebLogic Scripting Tool.

   There is no need to connect the WebLogic Scripting Tool to the WebLogic Server as the migration command is an offline command.

3. Run the WebLogic Scripting Tool migrateSecurityStore command to migrate the policy store and application as follows.

   • To migrate the policy store, run:

     migrateSecurityStore
        (type="policyStore", src="sourceContext", 
         dst="destinationContext", 
         configFile="myDir/jps-config.xml")
     

     where the following applies:

     • The name of the corresponding jpsContext (previously created in Step 1) should be passed to the src and dst parameters.

     • The name of the jps-config.xml file (previously modified in Step 1) should be passed to the configFile parameter. The value must be a fully qualified file name with complete path information.

   • To migrate the application, run:

     migrateSecurityStore
        (type="appPolicies", src="sourceContext", 
         dst="destinationContext", 
         configFile="myDir/jps-config.xml", 
         srcApp="sourceApplication", dstApp="destinationApplication", 
         overWrite="true")
     

     where the following applies:

     • The name of the corresponding jpsContext (previously created in Step 1) should be passed to the src and dst parameters.

     • The name of the jps-config.xml file (previously modified in Step 1) should be passed to the configFile parameter. The value must be a fully qualified file name with complete path information.

     • The name of the application being migrated is the value of the srcApp parameter. If this parameter is not passed, all applications with the same application name in both the source and destination policy stores will be migrated.

     • The name that is assigned to the application in the destination policy store is the value of the dstApp parameter. If this parameter is not passed, the name of the application in the destination store is the same as the name used in the source store.

     • If the overWrite parameter is defined as true, policies specific to the destination application are replaced by policies from the source application. The default value of this parameter is false.

11.3.2 Migrating From LDAP to XML

Following is the procedure to migrate policies from an LDAP-based directory to an XML-based policy store.

1. Modify jps-config.xml as described in this sub procedure.

   1. Create a serviceInstance for both the source and destination policy stores as illustrated in Example 11-5.

      Example 11-5 LDAP to XML serviceInstances for Source and Destination Policy Stores

      <!-- Source LDAP-based policy store instance -->
         <serviceInstance provider="ldap.policystore.provider" 
            name="policystore.ldap.source">
          <description></description>
          <property value="OID" name="policystore.type"/>
          <property value="bootstrap" name="bootstrap.security.principal.key"/>
          <property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
          <property value="cn=mySourceRootName" 
            name="oracle.security.jps.ldap.root.name"/>
          <property value="ldap://mySourceHost.com:3060" name="ldap.url"/>
         </serviceInstance>
       
      <!-- Destination XML-based policy store instance -->
         <serviceInstance name="dst.xml" provider="policystore.xml.provider" 
          location="/scratch/divyasin/WithPSR/jazn-data-fscm.xml">
          <description>File Based Policy Store Service Instance</description>
         </serviceInstance>
      

   2. Create a serviceInstance corresponding to the bootstrap credential used to access the destination LDAP directory as illustrated in Example 11-6.

      Example 11-6 LDAP to XML serviceInstance for Bootstrap Credential

      <!-- Bootstrap credentials to access source LDAP -->
         <serviceInstance location="./bootstrap" provider="credstoressp" 
            name="bootstrap.cred">
         <description>Replace location with the full path of the directory where the
            bootstrap file cwallet.sso is located; typically found in
            destinationDomain/config/fmwconfig/</description>
         </serviceInstance>
      

   3. Create a jpsContext for both source and destination stores as illustrated in Example 11-7.

      Example 11-7 LDAP to XML jpsContext for Source and Destination Policy Stores

      <jpsContext name="sourceContext">
         <serviceInstanceRef ref="policystore.ldap.source"/>
      </jpsContext>
       
      <jpsContext name="destinationContext">
         <serviceInstanceRef ref="dst.xml"/>
      </jpsContext>
       
      <jpsContext name="bootstrap_credstore_context">
         <serviceInstanceRef ref="bootstrap.cred"/>
      </jpsContext>
      

2. Start the WebLogic Scripting Tool.

   There is no need to connect the WebLogic Scripting Tool to the WebLogic Server as the migration command is an offline command.

3. Run the WebLogic Scripting Tool migrateSecurityStore command to migrate the policy store and application as follows.

   • To migrate the policy store, run:

     migrateSecurityStore
        (type="policyStore", src="sourceContext", 
         dst="destinationContext", 
         configFile="/scratch/divyasin/WithPSR/jps-config.xml")
     

     where the following applies:

     • The name of the corresponding jpsContext (previously created in Step 1) should be passed to the src and dst parameters.

     • The name of the jps-config.xml file (previously modified in Step 1) should be passed to the configFile parameter. The value must be a fully qualified file name with complete path information.

   • To migrate the application, run:

     migrateSecurityStore
        (type="appPolicies", src="sourceContext", 
         dst="destinationContext", 
         configFile="/scratch/divyasin/WithPSR/jps-config.xml", 
         srcApp="sourceApplication", dstApp="destinationApplication", 
         overWrite="true")
     

     where the following applies:

     • The name of the corresponding jpsContext (previously created in Step 1) should be passed to the src and dst parameters.

     • The name of the jps-config.xml file (previously modified in Step 1) should be passed to the configFile parameter. The value must be a fully qualified file name with complete path information.

     • The name of the application being migrated is the value of the srcApp parameter. If this parameter is not passed, all applications with the same application name in both the source and destination policy stores are migrated.

     • The name that is assigned to the application in the destination policy store is the value of the dstApp parameter. If this parameter is not passed, the name of the application in the destination store is the same as the name used in the source store.

     • If the overWrite parameter is defined as true, policies specific to the destination application are replaced by policies from the source application. The default value of this parameter is false.

11.3.3 Migrating From XML to Database

Following is the procedure to migrate policies from an XML-based policy store to a database.

1. Modify jps-config.xml as described in this sub procedure.

   1. Create a serviceInstance for both the source and destination policy stores as illustrated in Example 11-8.

      Example 11-8 XML to Database serviceInstances for Source and Destination Policy Stores

      <!-- Source XML-based policy store instance -->
         <serviceInstance name="src.xml" provider="policystore.xml.provider" 
           location="/scratch/divyasin/WithPSR/jazn-data-fscm.xml">
          <description>File Based Policy Store Service Instance</description>
      </serviceInstance>
       
      <!-- Destination DB-based policy store instance -->
         <serviceInstance provider="ldap.policystore.provider" 
           name="policystore.db.destination">
          <description>DB Based Policy Store Service Instance</description>
           <property name="policystore.type" value="DB_ORACLE"/>
           <property name="jdbc.url" 
             value="jdbc:oracle:thin:@sc.us.oracle.com:1722:orcl" 
          <jdbc:oracle:thin:@sc.us.oracle.com:1722:orcl>/>
           <property name="jdbc.driver" value="oracle.jdbc.driver.OracleDriver"/>
           <property name="bootstrap.security.principal.key" 
              value="bootstrap_DWgpEJgXwhDIoLYVZ2OWd4R8wOA=" />
           <property name="oracle.security.jps.ldap.root.name" value="cn=jpsTestNode"/>
           <property name="oracle.security.jps.farm.name" value="cn=view_steph.atz"/>
         </serviceInstance>
      

   2. Create a serviceInstance corresponding to the bootstrap credential used to access the destination LDAP directory as illustrated in Example 11-9.

      Example 11-9 XML to Database serviceInstance for Bootstrap Credential

      <!-- Bootstrap credentials to access source DB -->
         <serviceInstance location="./bootstrap" provider="credstoressp" 
           name="bootstrap.cred">
           <description>Replace location with the full path of the directory 
              where the bootstrap file cwallet.sso is located; 
              typically found in destinationDomain/config/fmwconfig/</description>
         </serviceInstance>
      

   3. Create a jpsContext for both source and destination stores as illustrated in Example 11-10.

      Example 11-10 XML to Database jpsContext for Source and Destination Policy Stores

      <jpsContext name="sourceContext">
         <serviceInstanceRef ref="src.xml"/>
      </jpsContext>
       
      <jpsContext name="destinationContext">
         <serviceInstanceRef ref="policystore.db.destination"/>
      </jpsContext>
       
      <jpsContext name="bootstrap_credstore_context">
         <serviceInstanceRef ref="bootstrap.cred"/>
      </jpsContext>
      

2. Start the WebLogic Scripting Tool.

   There is no need to connect the WebLogic Scripting Tool to the WebLogic Server as the migration command is an offline command.

3. Run the WebLogic Scripting Tool migrateSecurityStore command to migrate the policy store and application as follows.

   • To migrate the policy store, run:

     migrateSecurityStore
        (type="policyStore", src="sourceContext", 
         dst="destinationContext", 
         configFile="/scratch/divyasin/WithPSR/jps-config.xml")
     

     where the following applies:

     • The name of the corresponding jpsContext (previously created in Step 1) should be passed to the src and dst parameters.

     • The name of the jps-config.xml file (previously modified in Step 1) should be passed to the configFile parameter. The value must be a fully qualified file name with complete path information.

   • To migrate the application, run:

     migrateSecurityStore
        (type="appPolicies", src="sourceContext", 
         dst="destinationContext", 
         configFile="/scratch/divyasin/WithPSR/jps-config.xml", 
         srcApp="sourceApplication", dstApp="destinationApplication", 
         overWrite="true")
     

     where the following applies:

     • The name of the corresponding jpsContext (previously created in Step 1) should be passed to the src and dst parameters.

     • The name of the jps-config.xml file (previously modified in Step 1) should be passed to the configFile parameter. The value must be a fully qualified file name with complete path information.

     • The name of the application being migrated is the value of the srcApp parameter. If this parameter is not passed, all applications with the same application name in both the source and destination policy stores are migrated.

     • The name that is assigned to the application in the destination policy store is the value of the dstApp parameter. If this parameter is not passed, the name of the application in the destination store is the same as the name used in the source store.

     • If the overWrite parameter is defined as true, policies specific to the destination application are replaced by policies from the source application. The default value of this parameter is false.

11.3.4 Migrating From Database to XML

Following is the procedure to migrate policies from a database to an XML-based policy store.

1. Modify jps-config.xml as described in this sub procedure.

   1. Create a serviceInstance for both the source and destination policy stores as illustrated in Example 11-11.

      Example 11-11 Database to XML serviceInstances for Source and Destination Policy Stores

      <!-- Source DB-based policy store instance -->
         <serviceInstance provider="ldap.policystore.provider" 
           name="policystore.db.source">
          <description>DB Based Policy Store Service Instance</description>
          <property name="policystore.type" value="DB_ORACLE"/>
          <property name="jdbc.url" 
            value="jdbc:oracle:thin:@sc.us.oracle.com:1722:orcl" <jdbc:oracle:thin:@sc.us.oracle.com:1722:orcl>/>
          <property name="jdbc.driver" value="oracle.jdbc.driver.OracleDriver"/>
          <property name="bootstrap.security.principal.key" 
              value="bootstrap_DWgpEJgXwhDIoLYVZ2OWd4R8wOA=" />
          <property name="oracle.security.jps.ldap.root.name" value="cn=jpsTestNode"/>
          <property name="oracle.security.jps.farm.name" value="cn=view_steph.atz"/>
      </serviceInstance>
       
      <!-- Destination XML-based policy store instance -->
         <serviceInstance name="dst.xml" provider="policystore.xml.provider" 
            location="/scratch/divyasin/WithPSR/jazn-data-fscm.xml">
          <description>File Based Policy Store Service Instance</description>
         </serviceInstance>
      

   2. Create a serviceInstance corresponding to the bootstrap credential used to access the destination LDAP directory as illustrated in Example 11-12.

      Example 11-12 Database to XML serviceInstance for Bootstrap Credential

      <!-- Bootstrap credentials to access source and destination LDAPs -->
         <serviceInstance location="./bootstrap" provider="credstoressp" 
            name="bootstrap.cred">
           <description>Replace location with the full path of the directory where 
             the bootstrap file cwallet.sso is located; typically found in
             destinationDomain/config/fmwconfig/</description>
         </serviceInstance>
      

   3. Create a jpsContext for both source and destination stores as illustrated in Example 11-13.

      Example 11-13 Database to XML jpsContext for Source and Destination Policy Stores

      <jpsContext name="sourceContext">
         <serviceInstanceRef ref="policystore.db.source"/>
      </jpsContext>
       
      <jpsContext name="destinationContext">
         <serviceInstanceRef ref="dst.xml"/>
      </jpsContext>
       
      <jpsContext name="bootstrap_credstore_context">
         <serviceInstanceRef ref="bootstrap.cred"/>
      </jpsContext>
      

2. Start the WebLogic Scripting Tool.

   There is no need to connect the WebLogic Scripting Tool to the WebLogic Server as the migration command is an offline command.

3. Run the WebLogic Scripting Tool migrateSecurityStore command to migrate the policy store and application as follows.

   • To migrate the policy store, run:

     migrateSecurityStore
        (type="policyStore", src="sourceContext", 
         dst="destinationContext", 
         configFile="/scratch/divyasin/WithPSR/jps-config.xml")
     

     where the following applies:

     • The name of the corresponding jpsContext (previously created in Step 1) should be passed to the src and dst parameters.

     • The name of the jps-config.xml file (previously modified in Step 1) should be passed to the configFile parameter. The value must be a fully qualified file name with complete path information.

   • To migrate the application, run:

     migrateSecurityStore
        (type="appPolicies", src="sourceContext", 
         dst="destinationContext", 
         configFile="/scratch/divyasin/WithPSR/jps-config.xml", 
         srcApp="sourceApplication", dstApp="destinationApplication", 
         overWrite="true")
     

     where the following applies:

     • The name of the corresponding jpsContext (previously created in Step 1) should be passed to the src and dst parameters.

     • The name of the jps-config.xml file (previously modified in Step 1) should be passed to the configFile parameter. The value must be a fully qualified file name with complete path information.

     • The name of the application being migrated is the value of the srcApp parameter. If this parameter is not passed, all applications with the same application name in both the source and destination policy stores are migrated.

     • The name that is assigned to the application in the destination policy store is the value of the dstApp parameter. If this parameter is not passed, the name of the application in the destination store will be the same as the name used in the source store.

     • If the overWrite parameter is defined as true, policies specific to the destination application are replaced by policies from the source application. The default value of this parameter is false.

11.4 Configuring Cache

Oracle Entitlements Server offers caching capabilites. The cache settings are configured in the jps-config.xml file. The following sections contain the appropriate information.

• Section 11.4.1, "Configuring Decision Caching"

• Section 11.4.2, "Configuring Attribute Caching"

11.4.1 Configuring Decision Caching

Authorization decision caching allows Oracle Entitlements Server to cache the result of an authorization call and use that decision in the future, if an identical call is made. The decision cache consists of two hierarchical levels.

• The first level (L1) caches subjects used in the authorization calls.

• The second level (L2) caches authorization and role mapping decisions for the given subject.

Note:

The decision cache automatically invalidates itself if there is a change in the policy.

The key of the cache is the incoming Subject, Permission and attributes used during policy evaluation. The value of the cache is the decision and obligations.

All parameter names are prefixed with oracle.security.jps.pdp. Example 11-14 illustrates how the decision cache parameters might be set in jps-config.xml.

Example 11-14 XML To Configure Decision Caching

<serviceInstance name="pdp.service" provider="pdp.service.provider">
           …
 <property name="oracle.security.jps.pdp.AuthorizationDecisionCacheEnabled"
   value="true"/>
 <property name="oracle.security.jps.pdp.
   AuthorizationDecisionCacheEvictionCapacity"
   value="1000"/>
 <property name="oracle.security.jps.pdp.
   AuthorizationDecisionCacheEvictionPercentage" 
   value="15"/>
 <property name=" oracle.security.jps.pdp.AuthorizationDecisionCacheTTL"
   value="180"/>
           …
</serviceInstance>

Table 11-3 documents the decision caching parameters.

Table 11-3 Decision Caching Parameters

Name	Description	Accepted Values
oracle.security.jps.pdp.AuthorizationDecisionCacheEnabled	Optional parameter that specifies whether the policy decision cache should be enabled.	true (default) false
oracle.security.jps.pdp.AuthorizaionDecisionCacheEvictionCapacity	Optional parameter that specifies the maximum capacity of the L1 cache. If the number of entries exceeds the value, some entries are evicted.	Integer representing number of entries 500 (default)
oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionPercentage	Optional parameter that specifies the percentage of entries in L1 cache that have to be evicted when the maximum capacity has been reached. For example, if the maximum capacity is 200 and the value of this parameter is 10 then 20 entries are evicted from the cache.	Integer representing percent of entries 10 (default equals 10%)
oracle.security.jps.pdp.AuthotizationDecisionCacheTTL	Optional parameter that specifies a time-to-live value (in seconds) for entries in the L2 cache. It defines how long an authorization decision is cached.	Integer representing time in seconds 60 (default equals 1 minute)

11.4.2 Configuring Attribute Caching

Each passed attribute can be cached if the cached property is defined for it. A corresponding time-to-live (TTL) value must also be defined if cached is enabled. The key of the cache is the attribute URI. The value of the cache is the attribute object. Example 11-15 illustrates how the attribute cache might be set in jps-config.xml.

Example 11-15 XML To Configure Attribute Caching

<propertySet name="ootb.pip.attribute.age.based.on.myattr.rdbms">
    <property name="ootb.pip.attr.type" value="OOTB_PIP_ATTRIBUTE"/>
    <property name="ootb.pip.ref" value="pip.service.ootb.db"/>
    <property name="name" value=" myattr"/>
    <property name="query" value="select value from table"/>
    <property name="cached" value="true"/>
    <property name="TTL" value="60"/>
</propertySet>

Note:

If cached is not defined for the attribute, it will not be cached.

11.5 Debugging

The following sections contain information on how to debug Authorization Policies created using Oracle Entitlements Server as well as the Policy Distribution Component.

• Configuring Logging for Debugging

• Searching Logs to Debug Authorization Policies

• Debugging Policy Distribution

11.5.1 Configuring Logging for Debugging

Oracle Entitlements Server uses the standard Java logging framework. Logging is the process of notifying an entity of a particular event. In the case of Oracle Entitlements Server, the entity can be a file or the Administration Console, and the event can be debugging information, runtime exceptions, or a record of actions taken by a user. The logging framework is configured based on the Oracle Entitlements Server deployment. More information is in the following sections.

• Configuring Logging for a Java Security Module Deployment

• Configuring Logging for a WebLogic Server Security Module Deployment

Note:

The java.util.logging package provides the classes and interfaces of the platform's core logging facilities.

11.5.1.1 Configuring Logging for a Java Security Module Deployment

The following configurations must be made to enable logging when using the Java Security Module in your deployment.

• Run the following command when you start the Security Module to specify the logging configuration file:

  -Djava.util.logging.config.file=logging.properties
  

• Set the logging level by adding the following lines to the configuration file:

  oracle.jps.authorization.level=FINEST
  oracle.jps.openaz.level=FINEST
  

  Logging levels define the complexity of the logging record and include (from least to most) VERBOSE (simple information), WARNING, INFO, CONFIG, FINE, FINER and FINEST (complex information).

If you don't specify a configuration file, the logging.properties file in $JAVA_HOME/jre/lib/ is used. Example 11-16 illustrates how to configure logging.properties to log information to the Administration Console.

Example 11-16 Configuration for Administration Console Logging

#The messages will we printed to the standard output
handlers=java.util.logging.ConsoleHandler

#The default level for all loggers is INFO
.level=INFO

#Override the default level for OES authorization to FINEST
oracle.jps.authorization.level=FINEST
oracle.jps.openaz.level=FINEST

#Use default formatter to print the messages
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter

Example 11-17 illustrates how to configure logging.properties to log information to a file.

Example 11-17 Configuration for File Logging

#The messages will be written to a file
handlers=java.util.logging.FileHandler
 
#The default level for all loggers is INFO
.level=INFO
 
#Override the default level for OES authorization to FINEST
oracle.jps.authorization.level=FINEST
oracle.jps.openaz.level=FINEST
 
#Configure file information. %h – is the user home directory
java.util.logging.FileHandler.pattern = %h/java%u.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter

11.5.1.2 Configuring Logging for a WebLogic Server Security Module Deployment

To enable logging when using the WebLogic Server Security Module in your deployment, run the following command to specify the logging configuration file when you start the WebLogic Server domain.

startWeblogic.sh -Djava.util.logging.config.file=logging.properties

Tip:

If you specify a relative path, the base directory is the domain home - not the directory where startWeblogic.sh is located

Other configurations relevant to the WebLogic Server Security Module are similar to those defined in Section 11.5.1.1, "Configuring Logging for a Java Security Module Deployment."

11.5.2 Searching Logs to Debug Authorization Policies

The following sections explain how to search for information recorded to the logging file. They include the commands to be run and, in many sections, sample output.

• Searching for PEP Request Information

• Searching for Security Module Cache Configuration Parameters

• Searching for Principals

• Searching for Resources and Actions

• Searching for the Value of an Attribute

• Searching for an Authorization Decision

• Searching for the Value of an Obligation

• Searching for Static Application Roles

11.5.2.1 Searching for PEP Request Information

Run the following command against the logging file to output PEP Request related information (including the Authentic Identity, the Runtime Resource, the Runtime Action and the Application Context).

grep "PepRequestImpl"

11.5.2.2 Searching for Security Module Cache Configuration Parameters

Run the following command against the logging file to output the cache configuration parameters for a particular Security Module.

grep "AuthotizationDecisionCacheTTL"

The following properties may be returned for this search. If a property does not appear in the log, it is not specified in jps-config.xml. In cases like this, the default value of the property is used.

• AuthorizationDecisionCacheTTL defines the time-to-live (in seconds) for the Authorization Decision cache. The default value is 60.

• AuthorizationDecisionCacheEvictionPercentage defines the percentage of authorization decisions to drop when the Authorization Decision cache has reached maximum capacity. The default value is 10.

• AuthorizationDecisionCacheEvictionCapacity defines the number used to evict the Authorization Decision cache if the decision cache size reaches this size. The default value is 500.

• AuthorizationDecisionCacheEnabled specifies whether the Authorization Decision cache is enabled. The default value is true.

Example 11-18 illustrates output for this search.

Example 11-18 Sample Output for Cache Configuration Parameters Search

oracle.security.jps.az.internal.runtime.service.AbstractPDPService
 
FINE: properties : {
oracle.security.jps.pdp.AuthotizationDecisionCacheTTL=60,
oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionPercentage=10,
oracle.secuirty.jps.pdp.AuthorizationDecisionCacheEvictionCapacity=1000,
oracle.security.jps.pdp.AuthorizationDecisionCacheEnabled=true}

11.5.2.3 Searching for Principals

Run the following command against the logging file to output the names of Principals that have been received by Oracle Entitlements Server in the form of an authorization request.

grep "Principal:"

Example 11-19 illustrates the output for a Principal search.

Example 11-19 Sample Output for Principal Search

com.bea.security.providers.authorization.asi.AuthorizationProviderImpl isAccessAllowed

FINE:subject: Subject:
     Principal: John
     Principal: Employee
     Principal: Administrator
     Principal: Principal Developer

11.5.2.4 Searching for Resources and Actions

Run the following command against the logging file to output the Resources and Actions that have been received by Oracle Entitlements Server in the form of an authorization request.

grep "Resource:"

Example 11-20 illustrates how the information is returned. The defined values are the name of the policy object.

• Application = Lib

• Resource Type = libraryresourcetype

• Resource = Book

• Action = borrow

Example 11-20 Sample Output for Resource and Action Search

com.bea.security.providers.authorization.asi.AuthorizationProviderImpl isAccessAllowed

FINE: Resource: resource=Lib/libraryresourcetype/Book, action=borrow

11.5.2.5 Searching for the Value of an Attribute

Run the following command against the logging file to output the value of an attribute that has been received by Oracle Entitlements Server in the form of an authorization request.

grep "<name-of-the-attribute>:"
EXAMPLE: grep "getAttributeInternal:"

Example 11-21 illustrates the returned information where the name of the attribute is NumberOfBorrowedBooksAttribute and the value is 2.

Example 11-21 Sample Output for the Value of an Attribute Search

com.bea.security.providers.authorization.asi.ARME.evaluator.EvalSession logDebug
FINE: getAttributeInternal: name: NumberOfBorrowedBooksAttribute; value: 2; type: 3

11.5.2.6 Searching for an Authorization Decision

Run the following command against the logging file to retrieve an authorization decision that has been stored.

grep "AccessResultLogger"

Example 11-22 illustrates the returned information and confirm that the authorization decision was affirmative.

Example 11-22 Sample Output for Authorization Decision Search

com.bea.security.providers.authorization.asi.AccessResultLogger log
FINE: Subject Subject:
Principal: John
Principal: Employee
Principal: Administrator
Principal: Principal Developer
 privilege borrow resource //app/policy/Lib/Book result PERMIT

11.5.2.7 Searching for the Value of an Obligation

Run the following command against the logging file to output the value of a specific obligation.

grep "adding response attribute:" | grep  "obligations"

Example 11-23 illustrates the returned information indicating that the obligation (named DenyObligation) denies the request when the amount of library books the Principal currently has checked out is more than three; in this case, the Principal has five books checked out.

Example 11-23 Sample Output for Obligation Value Search

com.bea.security.providers.authorization.asi.AuthorizationProviderImpl ARMEisAccessAllowed
FINE: adding response attribute: namespace=oracle.security.oes.authorization. 
 name=obligations value={DenyObligation=
   { reason_part1=Too many borrowed books (max=3), reason_part2=5, }}

11.5.2.8 Searching for Static Application Roles

Run the following command against the logging file to output the names of Application Roles granted statically.

grep "AbstractRoleManager" | grep "getGrantedStaticAppRoles"

Example 11-24 illustrates how two static roles are added to the list of principals: an authenticated-role – build-in role and Reader, an Application Role defined in the Application named Library.

Example 11-24 Sample Output for Static Role Search

oracle.security.jps.az.internal.runtime.entitymanager.AbstractRoleManager getGrantedStaticAppRoles(Set)
FINER: RETURN [authenticated-role, 
  ApplicationRoleLibrary/Readeruname:
  cn=Writer,cn=Roles,cn=Lib,cn=akapisni_dwps1_
  view1.atzsrg,cn=JPSContext,cn=jpsTestNode,guid:
  411EBF807CD411E0BF887FB1A0F3878F]

11.5.3 Debugging Policy Distribution

The Policy Distribution Component uses the policy management Logger interface. To enable debugging for the Policy Distribution Component, change the logging level of the oracle.jps.policymgmt.level property in the logging configuration file to FINEST. The procedure is documented in Section 11.5.1, "Configuring Logging for Debugging."