Oracle® Fusion Middleware Release Notes 11g Release 1 (11.1.1) for Microsoft Windows (32-Bit) E10132-25 |
|
![]() Previous |
![]() Next |
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:
Oracle Fusion Middleware Security Guide
Oracle Fusion Middleware Security Overview
Oracle Fusion Middleware Administrator's Guide
Oracle Fusion Middleware Administrator's Guide for Authorization Policy Manager
This section describes configuration issues and their workarounds. It includes the following topics:
This section describes configuration issues for the Oracle Fusion Middleware Audit Framework. It contains these topics:
Section 40.1.1.1, "Configuring Auditing for Oracle Access Manager"
Section 40.1.1.2, "Audit Reports do not Display Translated Text in Certain Locales"
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.
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.
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.
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:
Open the following file for editing:
$RCU_HOME/rcu/integration/iau/scripts/STS.sql
Remove the comma on line number 48 in STS.sql
.
Save and close the file.
Open the following file for editing:
$RCU_HOME/rcu/integration/iau/iau.xml
Search for string 11.1.1.3.0
and replace it with the string 11.1.1.4.0
Save and close the file.
Run RCU.
Option 2
Use this option if RCU has already been run for PS3. The steps are:
Open the following file for editing:
$COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/sql/scripts/STS.sql
Remove the comma on line number 48 in STS.sql
.
Save and close the file.
Copy STS.sql
to the location from where it is going to be run.
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.
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:
Copy
$COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/sql/scripts/STS.sql
to
$COMMON_COMPONENTS_HOME/common/sql/iau/upgrade/STS.sql
Open the copied file for edit.
Remove the comma in line number 48.
Save and close the file.
Open the following files for edit:
$COMMON_COMPONENTS_HOME/common/sql/iau/upgrade/ iau111134.sql $COMMON_COMPONENTS_HOME/common/sql/iau/upgrade/ iau11114.sql
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;
Save and close both edited files.
At this point you can use PSA.
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 '
'. 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:
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.
Manually edit the file jps-config.xml
and remove the trailing characters '
' 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.
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.
This section describes issues and workarounds with Authorization Policy Manager, in the following sections:
Section 40.2.1, "Error Message While Searching Application Roles"
Section 40.2.2, "Some Errors/Warnings in Authorization Policy Manager Display Server Locale"
Section 40.2.4, "Authorization Policy Manager Patch Installation Fails on 64-bit Operating Systems"
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.
Errors and warnings in Authorization Policy Manager display the server locale and not the browser locale. There is no workaround to this issue.
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
To work around this issue, in Windows or UNIX/Linux 64-bit operating systems, proceed as follows:
Set the variables ORACLE_HOME and PATH as explained in the README.TXT file included in the patch.
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.
Change directory to the patch location:
> cd <patch location>
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
This section contains corrections for documentation errors. Topics include:
In Section 7.3.1 "What is Configured?" of the Oracle Fusion Middleware Security Guide, change the title of the discussion just below Table 7-1 from "Front-end Parameters" to "Connection/Back-end Parameters".