29 Oracle Platform Security Services

29.1.1.1 Mandatory Patch for Oracle Internet Directory 10.1.4.3

If using Oracle Internet Directory 10.1.4.3 with OPSS, a mandatory one-off patch for bug number 8351672 is recommended on top of Oracle Internet Directory 10.1.4.3. Download the patch for your platform from Oracle Support at http://myoraclesupport.oracle.com.

To ensure optimal performance, the following Oracle Internet Directory tuning is recommended:

ldapmodify -D cn=orcladmin -w <password> -v <<EOF 
dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclinmemfiltprocess
orclinmemfiltprocess: (objectclass=orcljaznpermission)
orclinmemfiltprocess: (objectclass=orcljazngrantee)
EOF

29.1.1.2 DSA unwilling to perform Error when Using Oracle Internet Directory 10.1.4.3 as Policy Store

Problem

When using Oracle Internet Directory 10.1.4.3 as a policy store, the use of special characters like '*', '(', ')', '\' in the RFC 2252/2253 filter results in error 53 (DSA unwilling to perform).

Solution

The patch for Bug 7711351 must be applied to Oracle Internet Directory 10.1.4.3.

29.2.1.1 Custom Configuration is Retained when the Audit Level Changes

When auditing is configured at the custom audit level, and you subsequently use WLST to switch to a different (non-custom) audit level, the custom audit settings are retained unless you explicitly remove those custom settings.

An example illustrates this behavior:

1. Custom audit level is set for a component's policy. An audit filter is specified as part of the configuration.

2. At run-time, audit data is collected according to the specified filter.

3. The component's audit policy is now changed from custom audit level to, say, the low audit level using the WLST setauditpolicy command. However, the filter that was set up as part of the custom audit level persists in the audit configuration.

4. Audit data is now collected based on the low audit level, not the custom level.

5. The component's audit policy is changed back to custom level. An additional filter is added; this filter is appended to the originally configured filter. Unless the original filter is explicitly deleted, it remains part of the configuration.

6. At run-time, audit data is collected based on all prevailing filters at the custom level.

29.2.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.

29.2.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 always displayed in English even when they are translated.

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

29.3.1.1 Granting Policies to Anonymous and Authenticated Roles with WLST Commands

Several WLST commands require the specification of the principal name and the principal class for a role involved in the operation.

For example, the following invocation adds a principal to the role with application stripe myApp and name myAppRole:

grantAppRole.py -appStripe myApp -appRoleName myAppRole 
                -principalClass myPrincipalClass -principalName myPrincipal

When in such commands the principal refers to the authenticated role or the anonymous role, the principal names and principal classes are fixed and must be one of the following pairs:

• Authenticated role

  • Name: authenticated-role

  • Class: oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl

• Anonymous role

  • Name: anonymous-role

  • Class: oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl

The list of WLST commands that required principal name and class specification are the following:

• grantAppRole

• revokeAppRole

• grantPermission

• revokePermission

• listPermissions

29.3.1.2 Application Stripe for Versioned Applications in WLST Commands

Several WLST commands require the specification of an application stripe. By default, the application stripe is the application name, if the application is not versioned. When the application is versioned, however, the application name and the application stripe are not identical.

For example, the name of a versioned application with name myApp and version 1 is displayed myApp(v1.0) in Oracle Fusion Middleware Control pages, but the application stripe of this application is myApp#v1.0.

In general, an application with display name appName(vers) has application stripe appName#vers. It is this last string that should be passed as the application stripe in WLST commands, as illustrated in the following invocation:

>listAppRoles myApp#v1.0

The list of WSLT commands that can use stripe specification are the following:

• createAppRole

• deleteAppRole

• grantAppRole

• revokeAppRole

• listAppRoles

• listAppRoleMembers

• grantPermission

• revokePermission

• listPermissions

• deleteAppPolicies

29.3.2.1 OPSS System Properties for JVM

Table 29-1 lists some recommended special settings for OPSS system properties. These are typically specified in the script that starts Oracle WebLogic Server.

29.3.2.2 LDAP Policy Store Property Configuration for Maximum performance

Table 29-2 lists the properties that are required to be present in an LDAP policy store service instance. The properties of an instance can be specified and modified with the script described in section E.1 in Oracle Fusion Middleware Security Guide.

29.3.2.3 Profiling LDAP Policy Store APIs

Table 29-3 lists loggers to profile the timing of several LDAP policy store runtime APIs. These profilers are specified with Oracle Fusion Middleware Control pages, as explained in section I.1.1.4 in the Oracle Fusion Middleware Security Guide.

29.3.3.1 Updates to Example 1: JavaSE Application with Wallet Store

In section 17.7.2, "Example 1: JavaSE Application with Wallet Store", in the example jazn-data.xml, change the name elements as follows:

Change:

<name>*context=SYSTEM,mapName=pc_map,keyName=**</name>

to:

<name>context=SYSTEM,mapName=pc_map,keyName=*</name>

Change:

<name>*context=SYSTEM,mapName=gc_map,keyName=gc_key*</name>

to:

<name>context=SYSTEM,mapName=gc_map,keyName=gc_key</name>

29.3.3.2 Updates to Example 2: JavaEE Application with Wallet Store

In section 17.7.3, "Example 2: JavaEE Application with Wallet Store", in the example jazn-data.xml, change the codesource element to include the deployed application name as follows:

Change:

<codesource>   <url>file:${domain.home}/servers/${weblogic.Name}/tmp/_WL_user/-</url></codesource>

to:

<codesource>
   <url>file:${domain.home}/servers/${weblogic.Name}
   /tmp/_WL_user/myTestApp/-</url>
</codesource>

29.3.6.1 Converting Oracle Access Manager Certificates to Java Keystore Format

Skip this task; it is no longer required.

29.3.6.2 Establishing Trust Between Oracle HTTP Server and Oracle WebLogic Server

This task in the section "Configuring Oracle Access Manager Identity Assertion for Single Sign-On" is the same whether you are using Oracle Access Manager or Oracle Application Server for single sign-on. Therefore, it will be renamed as follows:

"Establishing Trust Between Oracle WebLogic Server and Other Entities"

In the WebLogic Administration Console, there is no General tab or View Domain-Wide Security Settings link. As a result, steps 2, 3, and 4 in the following procedure will be corrected as shown here to reflect the actual navigation path and tab names in the WebLogic Administration Console:

To configure a connection filter to allow requests from the host of the 11g Oracle HTTP Server

1. Log in to the Oracle WebLogic Administration Console.

2. Click Domain under Domain Configurations.

3. Click the Security tab, click the Filter tab.

4. Click the Connection Logger Enabled attribute to enable the logging of accepted messages for use when debugging problems relating to server connections.

5. Specify the connection filter to be used in the domain:

   • Default Connection Filter: In the Connection Filter attribute field, specify weblogic.security.net.ConnectionFilterImpl.

   • Custom Connection Filter: In the Connection Filter attribute field, specify the class that implements the network connection filter, which should also be specified in the CLASSPATH for Oracle WebLogic Server.

6. Enter the appropriate syntax for the connection filter rules.

7. Click Save.

8. Restart the Oracle WebLogic Server.

9. Proceed to "Configuring the Authentication Scheme, Policy Domain, and WebGate Profile for the Identity Asserter".

29.3.6.3 Establishing Trust Between Oracle WebLogic Server and Other Entities

This topic is the same whether you are using OSSO or Oracle Access Manager. In the WebLogic Administration Console, there is no General tab or View Domain-Wide Security Settings link. As a result, steps 2, 3, and 4 in the following procedure will be corrected as shown here to reflect the actual navigation path and tab names in the WebLogic Administration Console:

To configure a connection filter to allow requests from the host of the 11g Oracle HTTP Server

1. Log in to the Oracle WebLogic Administration Console.

2. Click Domain under Domain Configurations.

3. Click the Security tab, click the Filter tab.

4. Click the Connection Logger Enabled attribute to enable the logging of accepted messages for use when debugging problems relating to server connections.

5. Specify the connection filter to be used in the domain:

   • Default Connection Filter: In the Connection Filter attribute field, specify weblogic.security.net.ConnectionFilterImpl.

   • Custom Connection Filter: In the Connection Filter attribute field, specify the class that implements the network connection filter, which should also be specified in the CLASSPATH for Oracle WebLogic Server.

6. Enter the appropriate syntax for the connection filter rules.

7. Click Save.

8. Restart the Oracle WebLogic Server.

9. Proceed to "To create a form authentication scheme, policy domain, and access polices with OAMCfgTool".

29.3.6.4 Configuring mod_weblogic

The topic "Confirming mod_weblogic for Oracle Access Manager Identity Asserter", states:

If the mod_weblogic configuration is not present in the Web server httpd.conf file, requests cannot be proxied from the HTTP server to Oracle WebLogic Server.

The information will be changed as follows:

With Oracle HTTP Server 11g, the mod_weblogic configuration is present in mod_wl_ohs.conf by default, and the path of this file is included in httpd.conf. If the mod_weblogic configuration is not present then you must make edit httpd.conf.

29.3.6.5 Using OAMCfgTool to Create an Authentication Scheme

The following changes will be made:

• In Step 1, the actual location of OAMCfgTool on Oracle Technology might be different than the one states.

• A new step 2 will be added to ensure that you have the appropriate JDK installed before running OAMCfgTool:

To create a form authentication scheme, policy domain, and access polices with OAMCfgTool

1. ... (step unchanged)

2. Confirm that JDK 1.6 (or the latest version) is installed and configured.

3. ... (step unchanged)

29.3.6.6 Configuring Providers for the Authenticator in a WebLogic Domain

The following change will be made in the procedure "To configure providers for the Oracle Access Manager Authenticator in a WebLogic domain", Step 4, e: OAM Authenticator, Advanced Configuration:

The password shared by AccessGate and Access Server for simple communication modes is named Simple mode pass phrase, as described in Table 10–7.

29.3.6.7 Public URL Patterns

When using OAMCfgTool to create access policies for the Oracle Access Manager Identity Asserter, the URL pattern in the policy for a public URI should be /.../public/.../. However, the URL pattern might not be set in the policy.

This has no impact on functionality. However, this might cause confusion because of statements in the chapter.

29.3.6.8 OAMCfgTool and Password Entry

Oracle Fusion Middleware Security Guide, chapter "Configuring Single Sign-On in Oracle Fusion Middleware", section "About Using OAMCfgTool" will be updated with the following information for the next release:

• By default, OAMCfgTool will prompt for required passwords on the command line in a secure way if you do not enter them. For example:

  Enter app_agent_password:
  Enter ldap_userpassword: 
  Enter oam_aaa_passphrase: 
  Processed input parameters 
  

• A -noprompt option is available to avoid the password prompt

29.3.6.9 Oracle Access Manager Solution with No Fusion Middleware: Applications Deployed on a Stand-Alone Oracle WebLogic Server

If you are configuring the Oracle Access Manager solution for an application on a stand-alone WebLogic Server (without Oracle Fusion Middleware), the chapter "Configuring Single Sign-On in Oracle Fusion Middleware" in the Oracle Fusion Middleware Security Guide instructs you to acquire certain required files from the Oracle Technology Network.

The book currently contains the following incorrect details:

Incorrect: No Fusion Middleware Application

Correct: Applications Deployed on a Stand Alone WebLogic Server

Correct Locations of OAMCfgTool and Provider for Stand-Alone Oracle WebLogic Server:

When you are deploying applications on a stand-alone WebLogic Server (without Oracle Fusion Middleware), retrieve the following items as indicated here:

• OAMCfgTool: Oracle Access Manager 10g (10.1.4.3) Server media:

  oamcfgtool<version>.zip   
  

• oamAuthnProvider.zip: Oracle Access Manager 10g (10.1.4.3) WebGate for Oracle HTTP Server 11g media:

  oamAuthnProvider<version number>.zip 
  

Incorrect OAMCfgTool Location for Stand-Alone Oracle WebLogic Server:

No Fusion Middleware Application: ... Obtain OAMCfgTool, as follows.

1. Log in to Oracle Technology Network at: ...

2. Locate the OAMCfgTool ZIP file with Oracle Access Manager 10g (10.1.4.3) WebGate for Oracle HTTP Server 11g:

   oamcfgtool<version>.zip  
   

Correct OAMCfgTool Location for Stand-Alone Oracle WebLogic Server:

No Fusion Middleware Application: ... Obtain OAMCfgTool, as follows.

1. Log in to Oracle Technology Network at: ...

2. Locate OAMCfgTool on Oracle Access Manager 10g (10.1.4.3) Server media:

   oamcfgtool<version>.zip
   

29.3.6.10 Known Issues: Oracle Access Manager Provider JAR Files and OAMCfgTool

For other known issues, see this topic in chapter 10 of the Oracle Fusion Middleware Security Guide.

29.3.6.11 Oracle SSO Failure - Unable to process request

Problem

You receive a message stating:

Oracle SSO Failure - Unable to process request
Either the requested URL was not specified in terms of a fully-qualified host
name or Oracle HTTP Server single sign-on is incorrectly configured.
Please notify your administrator. 

Solution

Modify the Oracle HTTP Server httpd.conf file to include a port number in the ServerName and restart the Web server. For example:

From: ServerName host.domain.com

To: ServerName host.domain.com:port

29.3.6.12 SSO Users Specified in "Users to Always Audit" Must Be Uppercase

When you specify SSO users in the Oracle HTTP Server audit configuration, "Users to Always Audit" section, the SSO user name must be specified in uppercase characters.

A comma-separated list of users can be specified to force the audit framework to audit events initiated by these users. Auditing occurs regardless of the audit level or filters that have been specified. This is true for all authentication types.

For more information, see section "Managing Audit Policies" in chapter "Configuring and Managing Auditing" in the Oracle Fusion Middleware Security Guide.

29.3.6.13 OSSO Solution for Applications Deployed on a Stand Alone WebLogic Server

The Oracle Fusion Middleware Security Guide describes how to configure single sign-on (SSO) for applications that are deployed on Oracle Fusion Middleware Oracle WebLogic Server. However, details for applications that are deployed on a stand-alone Oracle WebLogic Server are provided here only.

Differences between the two environments include:

• Oracle Fusion Middleware with OSSO: The required OSSO Identity Asserter (ossoiap.jar) is provided automatically when you install Oracle Fusion Middleware: Oracle Identity Management, Oracle SOA Suite, or Oracle WebCenter is required.

  Note:

  Oracle Fusion Middleware with OSSO enables you to use either the Oracle HTTP Server 10g or 11g Web server.

• Stand-Alone Oracle WebLogic Server with OSSO: The required OSSO Identity Asserter (ossoiap.jar) must be acquired from the Oracle Web Tier, as described here.

  Note:

  Stand-Alone Oracle WebLogic Server with OSSO requires Oracle HTTP Server 11g Web server.

Whether you use OSSO for Oracle Fusion Middleware applications or other applications, the Identity Asserter performs the same functions as those illustrated and described in "Using the OSSO Identity Asserter" in the chapter "Configuring Single Sign-On in Oracle Fusion Middleware" of the Oracle Fusion Middleware Security Guide.

Also included in the following note are additional, optional details you can use to configure and test Single Logout for session invalidation and synchronization between the SSO cookie and the JSESSIONID cookie. Required files must also be acquired from the Oracle Web Tier, as described here.

Task overview: Deploying and configuring the OSSO Identity Asserter for applications on a stand-alone WebLogic Server

1. Install Oracle WebLogic Server 10.3.1 and other required components as follows:

   1. Perform Step 1, a-d as described in the "Task overview: Deploying and configuring the OSSO Identity Asserter" in "New Users of the OSSO Identity Asserter" in the Oracle Fusion Middleware Security Guide.

   2. Skip Step 1e and instead deploy your application.

2. Create a WebLogic security domain with the weblogin domain extension template that is supplied with Oracle WebLogic Server and can be used from $WLS_HOME/common/bin/config.sh.

3. Configure mod_weblogic to forward requests to Oracle WebLogic Server, as explained in "Configuring mod_weblogic" in "New Users of the OSSO Identity Asserter" in the Oracle Fusion Middleware Security Guide.

4. Register and configure the module mod_osso with the 10g SSO Server as a partner application, as described in "New Users of the OSSO Identity Asserter" in the Oracle Fusion Middleware Security Guide:

   1. Perform steps described in "Registering Oracle HTTP Server mod_osso with OSSO Server 10.1.4".

   2. Perform steps described in "Configuring mod_osso to Protect Web Resources".

5. Add Authentication Providers to the appropriate security domain as follows:

   1. Acquire the OSSO Identity Asserter (ossoiap.jar from the Oracle Web Tier at:

      $ORACLE_INSTANCE/modules/oracle.ossoiap_11.1.1/ossoiap.jar  
      

   2. Copy ossoiap.jar into $WLS_HOME/wlserver_10.x/server/lib/mbeantype, then restart the Oracle WebLogic Server.

   3. Configure providers as described in "Adding Providers to a WebLogic Domain for OSSO" in "New Users of the OSSO Identity Asserter" in the Oracle Fusion Middleware Security Guide:

6. Configure the Oracle WebLogic Connection Filtering mechanism to create access control lists and accept requests from the hosts where Oracle HTTP Server and the front-end Web server are running, as explained in "Establishing Trust Between Oracle WebLogic Server and Other Entities" in "New Users of the OSSO Identity Asserter" in the Oracle Fusion Middleware Security Guide.

   Note:

   Test the secured application to ensure that it is working with the default authenticator using the Oracle WebLogic Server host and port.

7. Configure the application authentication method for the OSSO Identity Asserter (all web.xml files in the application EAR file must include CLIENT-CERT in the element auth-method), as explained in Configuring the Application for the OSSO Identity Asserter" in "New Users of the OSSO Identity Asserter" in the Oracle Fusion Middleware Security Guide.

   Note:

   Test the application with users authenticated by OSSO while accessing the application with the Oracle HTTP Server host and port.

8. Optional: You can configure and test Single Logout [Session Invalidation and synchronization between the SSO cookie and JSESSIONID cookie] as follows:

   See Also:

   "Synchronizing the User and SSO Sessions: SSO Synchronization Filter" in New Users of the OSSO Identity Asserter" in the Oracle Fusion Middleware Security Guide for details on SSOFilter

   1. Acquire ssofilter.jar and configure Oracle WebLogic Server to use it as follows:

      1. Acquire ssofilter.jar from the Oracle Web Tier at:

      $ORACLE_INSTANCE/modules/oracle.ssofilter_11.1.1/ssofilter.jar  
      

      2. Copy it to an appropriate directory in Oracle Middleware home: WLS_INSTALL/Oracle/Middleware/modules directory, for example.

      3. Add the absolute path of ssofilter.jar to the Oracle WebLogic Server classpath (by editing the setDomainEnv.sh script POST_CLASSPATH variable or CLASSPATH variable).

   2. Deploy system-filters.war as a system filter, as follows:

      1. Acquire system-filters.war from the Oracle Web Tier at:

      $ORACLE_INSTANCE/modules/oracle.jrf_11.1.1/system-filters.war 
       
      

      2. Copy system-filters.war to an appropriate directory in Oracle Middleware home: WLS_INSTALL/Oracle/Middleware/modules directory, for example.

      3. Deploy system-filters.war as an application library: From the WebLogic Administration Console, click Deployment, select New, and choose the location of file.

      4. Restart the Oracle WebLogic Server, if asked.

   3. Enable Logs to verify that the SSOFilter is working, as follows:

      1. From the WebLogic Administration Console, click Domain, Environment, Servers, AdminServer.

      2. Click the Logging tab.

      3. From the Advanced drop-down, select "Minimum Severity to Log" as "Debug".

      4. From the Advanced drop-down, "Message destinations", select LogFile: Severity Level as "Debug".

      5. Save changes and restart the Oracle WebLogic Server.

   4. Confirm that the SSOFilter is loaded as a system filter:

      1. Open the AdminServer.log file in DomainHome/Servers/AdminServer/log/AdminServer.log.

      2. Search for "SSOFilter" and confirm that you can see <Debug> messages, which indicate SSOFilter initialization nd confirm a filter load

   5. Test the filter functionality to confirm that the SSO and JSESSIONID cookie are cleaned up after user logout and that attempts to access the application after logout require another login.

      Note:

      You must have OSSO Identity Asserter configured in the WebLogic security domain, otherwise the filter will automatically disable during its initialization.

   6. Test logout with applications to confirm that the session is ends cleanly.