This chapter describes issues associated with Oracle Entitlements Server. It includes the following topics:
This section describes general issue and workarounds. It includes the following topic:
Tomcat Security Module Fails To Load Custom Attribute Retriever Class
Finding Default Oracle Entitlements Server Security Module Certificates
Starting Oracle Access Manager When Protected by Entitlements Server Throws Exception
The Attribute Retriver Interface resides in the JPS JARs which are loaded by the Tomcat "shared" class loader. Thus, JARs that contain your Custom Attribute Restriver Interface implementations should also be loaded by the "shared" class loader or a class loader that has a "shared" class loader for its ancestor. Be sure to put the Custom Attribute Retriever JARs in the proper place based on this scenario.
This version of Oracle Entitlements Server allows the creation of duplicate Resource entries in Entitlements and Policies.
The default Oracle Entitlements Server Security Module (client) certificate is stored in your_oes_sm_folder
/oes_sm_instances/
your_oes_sm
/security/identity.jks
and the trusted Certificate Authority (CA) certificates are stored in your_oes_sm_folder
/oes_sm_instances/
your_oes_sm
/security/trust.jks
. Both are JKS certificate stores with the passwords set during the creation of the Security Module instance. The password will be encrypted and stored in standard Oracle Wallet (with autologon). The default Oracle Entitlements Server client keys are generated by itself and signed during the enrollment process.
If the Entitlements Server is started when the database hosting the policy store is down, it will not automatically recover once the database is available. Either of the following will rectify this.
Set the database for automatic recovery by defining the following properties:
Connection Creation Retry Frequency is needed if the database will be down before the Administration Server starts.
Test Connections on Reserve is required if the database goes down after a successful Administration Server start.
Restart the Administration Server once the database is live.
If multiple Role Mapping Policies or Authorization Policies are returned as a result of running the Policy Simulator, the correct object reference is not passed and thus, they are not opened correctly. You will see this after clicking Check Access and selecting the Application Roles and Mapping Policies tab. To workaround this issue and open policy details, search for the policies using the Advanced Search screen.
You will get a runtime exception when starting an instance of Oracle Access Manager protected by Oracle Entitlements Server. The exception can be ignored.
Oracle recommends that all customers be on the latest version of OPatch. Please review My Oracle Support Note 224346.1 Opatch - Where Can I Find the Latest Version of Opatch? and follow the instructions to update to the latest version if necessary. For FMW Opatch usage, please refer to the Oracle Fusion Middleware Patching Guide.
This section describes configuration issues and their workarounds. It includes the following topics:
Use Absolute Paths While Running configureSecurityStore.py With -m Join
Wrong Type Defined For PIP Service Provider After Adding PIP Attribute
Typically, the policy store will recover while its associated database is recovered. If error messages in the WebLogic Server Administration Console document that the data source could not be found in the WebLogic Server, check the data source configuration with WebLogic Developer, retrieve the details of the data source configuration and set the 'Initial Capacity' property to 0; this ensures that the data source will recover while the database starts up.
The Config Security Store fails to create the policy store object when using variables such as ORACLE_HOME and MW_HOME while running wlst.sh
using configureSecurityStore.py
with -m join
. Always use absolute paths for ORACLE_HOME and MW_HOME while running the command for -m join
.
The pip.service.provider
parameter in jps-config.xml
is required for PIP attributes. When a jps-config.xml
file without a service provider entry for the pip.service.provider
parameter is fed to the Administration Console and some PIP attributes are added, a service provider value is automatically added to the pip.service.provider
with its type defined as AUDIT rather than PIP. In this scenario, after saving jps-config.xml
, check for the created service provider and manually change the type from AUDIT to PIP.
This step is not required if the service provider is already present before the Administration Console touches the file. Additionally, the Administration Console will not overwrite a service provider entry that is correctly created. This issue only happens when the Administration Console has to add a service provider because of its absence.
There are no documentation errata for this release.