This chapter contains information on managing audit tasks and migrating policies from different types of stores. It contains the following sections:
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.
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
Start the $DOMAIN
domain using the following command.
$DOMAIN/startWeblogic.sh
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
Restart the domain.
After enabling the providers, see Section A.2.4, "WebLogic Server Security Module" for the configuration parameters.
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.
Note:
Oracle Entitlements Server will audit decisions resulting from policies configured by itself, Oracle Platform Security Services or any combination thereof.
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 |
|
Application Management |
|
Grant Management |
|
PermissionSetManagement |
|
PolicyDomainManagement |
|
PolicyManagement |
|
ResourceManagement |
|
Role Management |
|
RolePolicyManagement |
|
Authorization |
|
ConfigurationBindingManagement |
|
ConfigurationManagement |
|
PolicyDistributionManagement |
|
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), |
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.
This section contains information regarding migrating policies from one type of store to another. It contains procedures for the following:
Following is the procedure to migrate policies from an XML-based policy store to an LDAP-based directory.
Modify jps-config.xml
as described in this sub procedure.
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>
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>
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>
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.
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.
Following is the procedure to migrate policies from an LDAP-based directory to an XML-based policy store.
Modify jps-config.xml
as described in this sub procedure.
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>
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>
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>
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.
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.
Following is the procedure to migrate policies from an XML-based policy store to a database.
Modify jps-config.xml
as described in this sub procedure.
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>
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>
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>
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.
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.
Following is the procedure to migrate policies from a database to an XML-based policy store.
Modify jps-config.xml
as described in this sub procedure.
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>
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>
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>
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.
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.
Oracle Entitlements Server offers caching capabilites. The cache settings are configured in the jps-config.xml
file. The following sections contain the appropriate information.
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 |
---|---|---|
|
Optional parameter that specifies whether the policy decision cache should be enabled. |
true (default) false |
|
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) |
|
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%) |
|
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) |
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.
The following sections contain information on how to debug Authorization Policies created using Oracle Entitlements Server as well as the Policy Distribution Component.
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.
Note:
The java.util.logging
package provides the classes and interfaces of the platform's core logging facilities.
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
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."
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.
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"
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}
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.
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
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.
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
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, }}
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]
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."