Skip Headers
Oracle® Fusion Middleware Release Notes
11g Release 1 (11.1.1) for Microsoft Windows x64 (64-Bit)

Part Number E14774-41
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

25 Oracle Platform Security Services

This chapter describes notes on topics associated with Oracle Platform Security Services (OPSS), in the following sections:

The following documents are relevant to topics included in this chapter:

25.1 Configuration Issues and Workarounds

This section describes configuration issues and their workarounds. It includes the following topics:

25.1.1 Oracle Fusion Middleware Audit Framework

This section describes configuration issues for the Oracle Fusion Middleware Audit Framework. It contains these topics:

25.1.1.1 Configuring Auditing for Oracle Access Manager

Although Oracle Access Manager appears as a component in Oracle Enterprise Manager Fusion Middleware Control, you cannot configure auditing for Oracle Access Manager using Fusion Middleware Control.

25.1.1.2 Audit Reports do not Display Translated Text in Certain Locales

The standard audit reports packaged with Oracle Business Intelligence Publisher support a number of languages for administrators. Oracle Business Intelligence Publisher can start in different locales; at start-up, the administrator can specify the language of choice by setting the preferred locale in Preferences.

Due to this bug, if Oracle Business Intelligence Publisher is started on any of these 3 locales:

  • zh_CN (simplified chinese)

  • zh_TW (traditional chinese)

  • pt_BR (portuguese brazilian)

then users cannot see the report in that locale (the entire report including labels, headers, titles and so on appears in English), while the other locales display the translated text as expected. For example, when Oracle Business Intelligence Publisher is started in zh_CN, the text cannot be seen in zh_CN even though the preferred locale is set to zh_CN; information is displayed in English.

This issue will be fixed in a future release of Oracle Business Intelligence Publisher.

25.1.1.3 Audit Reports Always Display in English

The standard audit reports packaged with Oracle Business Intelligence Publisher support a number of languages.

Due to this bug, report titles and descriptions are displayed in English even when they have been translated.

This issue will be fixed in a future release of Oracle Business Intelligence Publisher.

25.1.1.4 Creating a New Audit Schema

When RCU is run for PS3 it completes the creation of the audit schema and gives the status of the creation as success. However, the STS table is not created because of a typographical issue in the STS.sql script which is invoked by RCU.

Information indicating that the table did not get created can be found only if the iau.log file is inspected or if you specifically look for the created tables.

Due to this issue, for a Release 11g PS3 full install, you must explicitly ensure the STS table is created if you have chosen to create the audit schema and are planning to use it.

You have two options to resolve the issue, depending on whether RCU has already been run for PS3.

Option 1

Use this option if RCU has not yet been run for PS3. The steps are:

  1. Open the following file for editing:

    $RCU_HOME/rcu/integration/iau/scripts/STS.sql 
    
  2. Remove the comma on line number 48 in STS.sql.

  3. Save and close the file.

  4. Open the following file for editing:

    $RCU_HOME/rcu/integration/iau/iau.xml
    
  5. Search for string 11.1.1.3.0 and replace it with the string 11.1.1.4.0

  6. Save and close the file.

  7. Run RCU.

Option 2

Use this option if RCU has already been run for PS3. The steps are:

  1. Open the following file for editing:

    $COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/sql/scripts/STS.sql 
    
  2. Remove the comma on line number 48 in STS.sql.

  3. Save and close the file.

  4. Copy STS.sql to the location from where it is going to be run.

  5. Connect as sysdba and run the following SQL commands:

    sqlplus> connect /as sysdba;
    sqlplus> alter session set current_schema=audit_schema_user;
    sqlplus> @@STS.sql audit_schema_user audit_schema_user_Append
    audit_schema_user_Viewer
    

    replacing audit_schema_user with the name of your audit schema user.

25.1.1.5 Upgrading the Audit Schema

This note describes a required workaround that applies in case (and only in case) you are upgrading your audit schema from PS1 or PS2 to PS3. The following workaround must be executed before running the Patch Set Assistant (PSA).

To implement the workaround, proceed as follows:

  1. Copy

    $COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/sql/scripts/STS.sql
    

    to

    $COMMON_COMPONENTS_HOME/common/sql/iau/upgrade/STS.sql
    
  2. Open the copied file for edit.

  3. Remove the comma in line number 48.

  4. Save and close the file.

  5. Open the following files for edit:

    $COMMON_COMPONENTS_HOME/common/sql/iau/upgrade/ iau111134.sql
    $COMMON_COMPONENTS_HOME/common/sql/iau/upgrade/ iau11114.sql
    
  6. In each of those files:

    • Remove the line ALTER TABLE OAM ADD IAU_ResourceTemplateName VARCHAR(100);

    • Just before the line ALTER TABLE OAM ADD IAU_AdditionalInfo CLOB, insert the following line before the line

      RENAME COLUMN IAU_AdditionalInfo TO IAU_AdditionalInfo_OLD;
      
  7. Save and close both edited files.

  8. At this point you can use PSA.

25.1.2 Trailing '\n' Character in Bootstrap Key

In 11gR1, the process that reassociates XML to LDAP stores creates a bootstrap key with the trailing new line character '\n', or its equivalent code '&#xA'. This key value is written in the file jps-config.xml and stored in the wallet. In both places, the key value contains the trailing character '\n'.

When reusing that same wallet in 11gR1 PS1, upon retrieving the bootstrap key, the system trims out the trailing '\n' character; but the key value in the wallet, however, still contains the trailing character, a situation that leads to errors since the requested and stored key values no longer match.

To resolve this issue, proceed as follows:

  1. Use the WLST command modifyBootStrapCredential to reprovision wallet credentials without trailing '\n'. For details on the command usage, see section 9.5.2.5 in the Oracle Fusion Middleware Security Guide.

  2. Manually edit the file jps-config.xml and remove the trailing characters '&#xA' from any bootstrap key.

This problem arises only in the scenario above, namely, when an 11gR1 wallet is reused in 11gR1 PS1; in particular, when reassociating in an 11gR1 PS1 environment, the above trailing character is not an issue.

25.1.3 Users with Same Name in Multiple Identity Stores

If a user name is present in more than one LDAP repositories and the property virtualize is set to use LibOVD, then the data in only one of those repositories is returned by the User and Role API when that name is queried.

25.1.4 Script listAppRoles Outputs Wrong Characters

On Linux and Windows platforms, when the locale is set to non-UTF8 locales, such as fr_FR_iso88591, the OPSS script listAppRoles may wrongly output the character '?' instead of the expected character.

25.1.5 Propagating Identities over the HTTP Protocol

This section includes the following additions, corrections, and new information in the following sections:

25.1.5.1 Addition to Section Propagating Identities over the HTTP Protocol

The following new information belongs in section 19.3.1.2:

The out of box configuration assumes that the token issuer name and the key alias is based on the WebLogic server name. Note that the key alias server name on WebSphere is set based on the WebSphere server root. For example, if the server root is $T_WORK/middleware/was_profiles/DefaultTopology/was_as/JrfServer then the server name is set to JrfServer. To change the default value, use the procedures explained in section 19.3.12.

25.1.5.2 Correction to Section Client Application Code Sample

The following sample illustrates a client application; note that the file jps-api.jar and OSDT jars osdt_ws_sx.jar, osdt_core.jar, osdt_xmlsec.jar, osdt_saml2.jar must be included the class path for the code sample to compile.

25.1.5.3 Correction to Section Keystore Service Configuration

Assuming that the WebLogic server name is jrfServer_admin, the following command illustrates the creation of the keystore, represented by the generated file default-keystore.jks.

25.1.5.4 Updating the Trust Service Configuration Parameters

The information in this section is new and it explains how to modify the trust service configuration parameters in the file jps-config.xml with a script.

Out-of-the-box the values of the parameters trust.aliasName and trust.issuerName are set to the WebLogic server name. To modify their values to deployment-specific values, use a script like the following:

import sys
 
wlsAdmin = 'weblogic'
wlsPwd ='password_value'
wlUrl='t3://localhost:7001'
issuer= 'issuer'
alias = 'alias'
 
print "OPSS Trust Service provider configuration management script.\n"
 
instance = 'trust.provider'
name = 'trust.provider.embedded'
cfgProps = HashMap()
cfgProps.put("trust.issuerName", issuer)
cfgProps.put("trust.aliasName", alias)
pm = PortableMap(cfgProps);
 
connect(wlsAdmin, wlsPwd, wlUrl)
domainRuntime()
 
params = [instance, name, pm.toCompositeData(None)]
sign = ["java.lang.String", "java.lang.String", "javax.management.openmbean.CompositeData"]
on = ObjectName("com.oracle.jps:type=JpsConfig")
mbs.invoke(on, "updateTrustServiceConfig", params, sign)
mbs.invoke(on, "persist", None, None)
 
print "Done.\n"

25.1.6 Pool Configuration Missing in Identity Store

On the WebSphere Application Server, the out-of-the-box configuration file jps-config.xml is missing an entry for a property of the identity store. When the identity store, added at post-installation, is an LDAP-based identity store, the following property must be manually inserted in the jps-config.xml file within the identity store service instance element:

<property name="CONNECTION_POOL_CLASS" 
          value="oracle.security.idm.providers.stdldap.JNDIPool"/> 

To work around this issue, proceed as follows:

  1. Shut down the server.

  2. Open the file was_profile_dir/config/cells/cell_name/fmwconfig/jps-config.xml for edit, where was_profile_dir and cell_name stand for the profile directory name and cell name on your system.

  3. Insert the missing property CONNECTION_POOL_CLASS into the configuration of the identity store service instance.

  4. Save the file and restart the server.

25.2 Authorization Policy Manager Issues

This section describes issues with the Authorization Policy Manager, in the following sections:

25.2.1 Error Message While Searching Application Roles

If you encounter an error while performing an application role search that includes the message:

An error has occurred. Please view the logs for details

and the error logged includes a PolicyStoreOperatioNotAllowedException similar to the log illustrated in the following fragment (and found in the file apm_server1-diagnostic.log):

[2010-03-02T22:06:29.998-08:00] [apm_server1] [ERROR] [] 
[oracle.security.apm] [tid: [ACTIVE].ExecuteThread: '4' for queue: 
'weblogic.kernel.Default (self-tuning)'] [userId: weblogic] [ecid: 
0000ISYcUY2B1FcpPg1Fid1BXsJn00006W,0] [APP: oracle.security.apm]   
PolicyStoreException while calling searchAppRole[[ 
oracle.security.jps.service.policystore.PolicyStoreOperationNotAllowedExceptio
n: javax.naming.OperationNotSupportedException: [LDAP: error code 53 - Parent 
entry not found in the directory.];... 

then retry the operation, which should then run without errors.

25.2.2 Support for Internet Protocols

Authorization Policy Manager components support the following Internet Protocol versions:

  • Oracle database on IPv4 host

  • Authorization Policy Manager server on IPv4/IPv6 dual-stack host

  • Client (browser) on either IPv4 or IPv6 hosts

25.2.3 Authorization Policy Manager Patch Installation Fails on 64-bit Operating Systems

To work around this issue, in Windows or UNIX/Linux 64-bit operating systems, proceed as follows:

  1. Set the variables ORACLE_HOME and PATH as explained in the README.TXT file included in the patch.

  2. Run OPatch as illustrated in either of the following invocations:

    > OPatch -jre <64-bit java home location> lsinventory
    > OPatch -jdk <64-bit java home location> lsinventory
    

    A successful run returns Opatch succeeded; otherwise, verify that the passed location is valid.

  3. Change directory to the patch location:

    > cd <patch location>
    
  4. Run OPatch as illustrated in either of the following invocations:

    > OPatch -jre <64-bit java home location> apply
    > OPatch -jdk <64-bit java home location> apply
    

25.3 Documentation Errata

This section contains corrections to documentation errors. Topics include:

25.3.1 Updated Instructions for SSL for the Identity Store Service

This note contains clarifications to Section 7.5 "SSL for the Identity Store Service" in the Oracle Fusion Middleware Application Security Guide, part number E10043-10.

Doc Update 1

Update the beginning of Section 7.5 to explain the various scenarios in which the identity store service is used.

7.5 SSL for the Identity Store Service

Connections between the identity store and an LDAP server can be SSL-enabled. This section explains how the connections are configured in the various scenarios. Use the following table to determine the correct procedure to use:

If virtualize flag is set to And the User and Role API is in use And the Identity Directory Service is in use

virtualize=false (that is, virtualize flag is not set)

Specify truststore using JSSE parameters, as explained in Section 8.2.3.

For example:

-Djavax.net.ssl.trustStore=
trust_store_path_name

Use the adapters.jks file as shown in Sections 7.5.2 and 7.5.3.

virtualize=true (that is, virtualize flag is set)

Use the adapters.jks file as shown in Sections 7.5.2 and 7.5.3.

Use the adapters.jks file as shown in Sections 7.5.2 and 7.5.3.


Doc Update 2

Remove the information in Section 7.5.4. It is not needed.

25.3.2 Updated Configuration for Role Category

This note contains the correct configuration of a role category as described in Section 2.8 "The Role Category" in the Oracle Fusion Middleware Application Security Guide, part number E10043-10.

The configuration of the element <role-category> in the jazn-data.xml illustrated in section 2.8 should be replaced with the following:

<app-roles>
  <app-role>
    <name>AppRole_READONLY</name>
    <display-name>display name</display-name>
    <description>description</description>
    <class>oracle.security.jps.service.policystore.ApplicationRole</class>
    <extended-attributes>
      <attribute>
        <name>ROLE_CATEGORY</name>
        <values>
          <value>RC_READONLY</value>
        </values>
      </attribute>
    </extended-attributes>
  </app-role>
</app-roles>
<role-categories>
  <role-category>
    <name>RC_READONLY</name>
    <display-name>RC_READONLY display name</display-name>
    <description>RC_READONLY description</description>
  </role-category>
</role-categories>

The important point about this correction is the following:

  • The members of a role category are not configured within the <role-category> element but within the element <extended-attributes> of the corresponding application role.

25.3.3 Incorrect Spelling of createKeystore option

In section 7.5.2 "One-way SSL in a Multi-LDAP Scenario" in the Oracle Fusion Middleware Application Security Guide, the createKeystore option of the libovdconfig command is misspelled. Change "createKeyStore" to "createKeystore" (lowercase 's') in that section.

25.3.4 Clarification about Supported Policy Stores

Section 2.3.5 "Policy Store and the Policy API" in the Oracle Fusion Middleware Security Overview, Part Number E12889-04, lists Oracle Virtual Directory as an LDAP directory that can serve as a policy store. This is not true. Oracle Virtual Directory is not supported as a policy store.

Remove the sub-bullet "Oracle Virtual Directory" under the "LDAP directories" bullet point in Section 2.3.5.

25.3.5 Migration of Audit Metadata

Add the following to the end of Section 8.6.2 "Migrating with the Script migrateSecurityStore," of the Oracle Fusion Middleware Application Security Guide, part number E10043-12:

Migrating Audit Metadata

You can use the migrateSecurityStore WLST command to migrate audit metadata into the domain security store, or migrate audit metadata into an XML file.

Note that:

  • Audit metadata is separate from audit policy definitions. (See Section 6.5.3 of the Oracle Fusion Middleware Application Security Guide for information on migrating audit policies.)

  • There are two types of audit metadata: system definitions and component definitions.

  • When migrating audit metadata, you can choose whether to overwrite or preserve existing data in the destination store. Based on your choice, migrateSecurityStore follows specific rules to determine how to replace system and component definitions in the destination store, as explained below.

Use the following syntax to migrate audit metadata:

migrateSecurityStore(type="auditStore",
configFile="jps_config_file_location",
src="sourceContext",
dst="destinationContext"
[,overWrite="{true|false}"])

Using this command, you can migrate metadata of the audit service configured in source context into audit service of destination context. The audit metadata in source and destination context can be in XML, LDAP, and DB-based stores.

The parameters are as follows:

  • configFile specifies the location of a configuration file jps-config.xml relative to the directory where the script is run. Typically, this configuration file is created just to be used with the script and serves no other purpose. This file contains two jps-contexts that specify the source and destination stores.

  • src specifies the name of a jps-context in the configuration file passed to the argument configFile. It is the source metadata store.

  • dst specifies the name of another jps-context in the configuration file passed to the argument configFile. It is the destination metadata store.

  • overWrite indicates whether to overwrite existing metadata in the destination store; true = always overwrite existing metadata, false = do not overwrite existing metadata unless specific conditions are met. Optional, default = false. The overWrite flag is interpreted as follows:

    1. System definitions are never overwritten regardless of the value of the flag.

    2. If overwrite=true, component definitions in the destination store are replaced with the definitions in the source store.

    3. If overwrite=false, major and minor versions of the component definition in source and destination store are compared. If they have the same major version, and the minor version in the source component definition is higher, the component definition in the destination store is replaced with the definition in the source store. Otherwise, overwriting is skipped.

25.3.6 User/Role API Requirement for OID Configured User

Add the following to the end of Section 25.3.2 "Setting Up the Environment," of the Oracle Fusion Middleware Application Security Guide, part number E10043-12:

Read Privileges for Provider User (Oracle Internet Directory Only)

For the Oracle Internet Directory provider, the configured user should have privileges to read the "cn=common,cn=products,cn=oraclecontext" container at the root level.

25.3.7 Code Example 1 for CSF API

In Section 24.7.2 "Example 1: Java SE Application with Wallet Store" of the Oracle Fusion Middleware Application Security Guide, part number E10043-12, in the Java Code example, change:

static {
        java.security.Policy.setPolicy(new oracle.security.jps.internal.policystore.JavaProvider());
    }

to:

static {
        java.security.Policy.setPolicy(new oracle.security.jps.internal.policystore.JavaPolicyProvider());
    }