Skip Headers
Oracle® Fusion Middleware Release Notes
11g Release 1 (11.1.1) for Linux x86

Part Number E10133-05
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

29 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:

29.1 General Issues and Workarounds

This section describes general issues and workarounds. It includes the following topic:

29.1.1 Mandatory Patches for OPSS

This section lists patches required for OPSS:

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.1.2 ASCII Characters in Policy Store

Strings in a policy store cannot contain any special ASCII character in the range [0, 15].

29.1.3 Search Strategy when XML Policy Store Contains Certain ASCII Characters

The following characters:

< "  &  $ ? * , / \ ` :    ( ) ^ ' % +  { } 

are not recommended as part of an Application Role name when using the XML Policy Store.

If it becomes necessary to use one of these characters when creating a role, when you search the XML Policy Store with the ApplicationPolicy.searchAppRoles() API you must ensure that such characters are escaped in the input in order to provide correct results.

For example, if you have an Application Role named "applicationRole^$" it will need to be searched as ApplicationPolicy.searchAppRoles("applicationRole\\^\\$") to find it in the policystore.

As an alternative, you could use a wild card in the search expression without including these special characters - for example:

ApplicationPolicy.searchAppRoles("applicationRole*")

Note:

This is not an issue with the LDAP Policy Store.

29.1.4 Missing Newline Characters in XML Policy Store

In an XML file-based policy store, a new-line character is required between the closing of a <permission> or <principal> tag and the opening of the following one.

Following are examples of strings illustrating incorrect and correct formats.

Incorrect example fragment of policy store:

<permission>
    <class>java.lang.RuntimePermission</class>
    <name>getClassLoader</name>
 </permission> <permission>
      <class>java.io.FilePermission</class>
      <name>/foo</name>
      <actions>read,write</actions>
 </permission> 

Correct example fragment of policy store:

<permission>
    <class>java.lang.RuntimePermission</class>
    <name>getClassLoader</name>
</permission>
<permission>
      <class>java.io.FilePermission</class>
      <name>/foo</name>
      <actions>read,write</actions>
</permission>

29.1.5 Cataloging Oracle Internet Directory Attributes

An Oracle Internet Directory attribute used in a search filter must be indexed.

For detailed instructions on how to manage attribute catalogs and to identify whether an attribute is indexed, see the following sections in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory:

  • Adding an Index to a New Attribute by Using Oracle Directory Services Manager

  • Adding an Index to an Existing Attribute by Using Oracle Directory Services Manager

  • Dropping an Index from an Attribute by Using Oracle Directory Services Manager

  • Indexing an Attribute for Which Data Exists by Using Oracle Directory Services Manager

  • Creating and Dropping Indexes from Existing Attributes Using Catalog

The command ldapmodify , whose syntax is illustrated below, can also be used to index attributes specified in an LDIF file:

>ldapmodify -h <host> -p <port> -D <bind DN> -w <bind password> -v -f <catalogue modify ldif file name>

For example, the above command can be used with the following sample LDIF file to catalog the attributes createtimestamp and modifytimestamp:

dn: cn=catalogs
changetype: modify
add: orclindexedattribute
orclindexedattribute: modifytimestamp
orclindexedattribute: createtimestamp

The following sections detail Oracle Internet Directory attributes that must be indexed. For the patch required for Oracle Internet Directory 10.1.4.3, see Section 29.1.1.1, "Mandatory Patch for Oracle Internet Directory 10.1.4.3".

List of OPSS Attributes Required to Be Cataloged

Each of the following OPSS attributes must be cataloged:

orclrolescope

orclassignedroles

orclApplicationCommonName

orclAppFullName

orclCSFAlias

orclCSFKey

orclCSFName

orclCSFDBUrl

orclCSFDBPort

orclCSFCredentialType

orclCSFExpiryTime

modifytimestamp

createtimestamp

orcljpsassignee

29.1.6 Missing Policies in Policy Store Reassociated to Oracle Internet Directory

Problem

When an XML file-based policy store is reassociated to use Oracle Internet Directory, the re-association may report that it completed successfully. At runtime, however, the system may not behave as expected. Granted code-based policies, that are supposed to be present in the system policy after migration, may be missing. As a result the server may report a stack trace that resembles this stack:

<BEA-000000> <JspServlet: initialization complete>
####<May 4, 2009 8:32:50 AM PDT> <Error> <HTTP> <ap626atg> <WLS_Spaces>
<[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default
(self-tuning)'> <<WLS Kernel>> <> <> <1241451170341> <BEA-101020>
<[ServletContext@20193148[app:webcenter module:/webcenter path:/webcenter
spec-version:2.5]] Servlet failed with Exception
java.security.AccessControlException: access denied
(oracle.security.jps.service.policystore.PolicyStoreAccessPermission
context=APPLICATION,name=webcenter getApplicationPolicy)
        at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
        at
java.security.AccessController.checkPermission(AccessController.java:546)
        at
oracle.security.jps.util.JpsAuth$AuthorizationMechanism$3.checkPermission(JpsAuth.java:348)
        at
oracle.security.jps.util.JpsAuth$Diagnostic.checkPermission(JpsAuth.java:268)
        at
oracle.security.jps.util.JpsAuth$AuthorizationMechanism$6.checkPermission(JpsAuth.java:372)
        at oracle.security.jps.util.JpsAuth.checkPermission(JpsAuth.java:408)
        at oracle.security.jps.util.JpsAuth.checkPermission(JpsAuth.java:431)
        at
oracle.security.jps.internal.policystore.AbstractPolicyStore.checkPolicyStoreAccessPermission(AbstractPolicyStore.java:246)
        at
oracle.security.jps.internal.policystore.ldap.LdapPolicyStore.getApplicationPolicy(LdapPolicyStore.java:281)
        at
oracle.security.jps.internal.policystore.PolicyUtil.getGrantedAppRoles(PolicyUtil.java:898)
        at
oracle.security.jps.internal.policystore.PolicyUtil.getJpsAppRoles(PolicyUtil.java:1354)
        at
oracle.security.jps.wls.JpsWlsSubjectResolver$1.run(JpsWlsSubjectResolver.java:273)
        at
oracle.security.jps.wls.JpsWlsSubjectResolver$1.run(JpsWlsSubjectResolver.java:270)
        at java.security.AccessController.doPrivileged(Native Method)

Here the permission:

oracle.security.jps.service.policystore.PolicyStoreAccessPermission
context=APPLICATION,name=webcenter getApplicationPolicy

is granted to a code base, and the authorization decision is evaluating to false.

Solution

Check the AdminServer diagnostic logs for messages like these:

AdminServer-diagnostic.log:[2009-05-28T02:27:52.249-07:00] [AdminServer]
[NOTIFICATION] [JPS-00072] [oracle.jps.config] [tid: Thread-39] [ecid:
0000I66Z0KH0fplp4sm3Ui1A7_Rl00002s,1:5001] [arg: 11.1.1.1.0] [arg: 11.1.1.0.0] 
Policy schema upgrade not required. Store Schema version 11.1.1.1.0 is compatible 
to the seed schema version 11.1.1.0.0
AdminServer-diagnostic.log:[2009-05-28T02:28:58.012-07:00] [AdminServer]
[NOTIFICATION] [JPS-00078] [oracle.jps.config] [tid: Thread-39] [ecid: 
0000I66Z0KH0fplp4sm3Ui1A7_Rl00002s,1:5001] [arg: 11.1.1.1.0] [arg: 11.1.1.0.0] 
Credential store schema upgrade not required. Store Schema version 11.1.1.1.0 is 
compatible to the seed schema version 11.1.1.0.0

A message of this type suggests that the schema was never seeded during the re-association. If the correct schema is not seeded in the Oracle Internet Directory server, the system will not work as expected. To ensure that the schema is seeded during re-association:

  1. Remove the cn=OPSS container under the cn=OracleSchemaVersion container in the Oracle Internet Directory server.

  2. Start with a clean working instance of an OPSS policy store using the file-based store.

  3. Re-associate this file-based store to the Oracle Internet Directory server.

Check the AdminServer diagnostic logs to confirm that the OPSS LDAP schema was seeded in the LDAP server by looking for this message:

AdminServer-diagnostic.log:[2009-05-29T07:18:18.002-07:00] [AdminServer] [NOTIFICATION] [JPS-00078] [oracle.jps.config] [tid: Thread-12] [ecid: 0000I61Z0MH0fplp4sm3Ui1A7_Ll00002s,1:5001] [arg: 11.1.1.0.0]  Policy schema version set to 11.1.1.0.0

If re-associating to a Release 11g Oracle Internet Directory server, the schema version should read: 11.1.1.1.0

If re-associating to a Release 10.1.4.3 Oracle Internet Directory server, the schema version should read: 11.1.1.0.0

The PolicyStore schema version is set in the Oracle Internet Directory server under this container:

cn=PolicyStore,cn=OPSS,cn=OracleSchemaVersion

Similarly, the CredentialStore schema version is set in the Oracle Internet Directory server under this container:

cn=CredentialStore,cn=OPSS,cn=OracleSchemaVersion

29.1.7 Issues with Audit Reports

The following issues have been observed with the Common Audit Framework reports available in Oracle Business Intelligence Publisher.

Issues with the User Activities Dashboard

Navigate to Common Reports, then User Activities, then Dashboard. The following issues are observed:

  • For hyperlinks corresponding to certain data strings, the event is not displayed correctly. For example, if the data consists of a string containing a percent sign, such as cn=%host%.us.oracle.com, when you click on the corresponding event hyperlink, the event is not correctly displayed on the resulting report since the percent sign is not processed correctly. A similar issue may be seen if there are embedded spaces in the string.

  • When you navigate to a report using the hyperlink corresponding to Authentication Success, Authentication Failures, Authorization Success, or Authorization Failures, no data is displayed.

Issue with the Component Name and Application Name Filters

For these report filters, not all the filter options may be displayed as expected.

For example, on the All Events report, if the report contains data rows for Oracle Internet Directory (OID) as well as rows for Oracle Identity Federation (OIF), the Component Name drop-down should show All, OID, and OIF options; however, it may show only the All and OID filter options. This prevents you from filtering the report with the missing options (OIF in the example).

Solution

Apply the one-off patch for Bug 8524140.

29.2 Configuration Issues and Workarounds

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

29.2.1 Oracle Fusion Middleware Audit Framework

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

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.

Note:

This behavior only occurs when using WLST; if you use Fusion Middleware Control to manage audit configuration, the custom audit settings are cleared when you switch from the custom audit level to a different audit level.

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.2.2 User and Role API Customization

Oracle Fusion Middleware supports providers that enable the User and Role API to interact with custom identity stores.

For details about creating a custom User and Role provider, see the OPSS page in Oracle Technology Network at:

http://www.oracle.com/technology/products/id_mgmt/opss/index.html

29.3 Documentation Errata

This section describes documentation errata. It contains these topics:

29.3.1 WLST Updates

This section contains updates for documentation errata pertaining to WLST commands and usage.

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 Configuring LDAP Policy Stores

The following sections provide guidelines for setting OPSS parameters, properties, and profiling:

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.

Table 29-1 OPSS System Properties for JVM

Property Name Value Description

domain.home

$DOMAIN_HOME

Required for code-based grants that depend on the value of this system property.

This property must be set as a command-line parameter due to JVM bootstrapping restrictions.

jps.authz

ACC

Different from current out-of-the-box setting, which is DEBUG_ACC.

Setting -Djps.auth=ACC reduces runtime and debugging overhead.

jps.policystore.hybrid.mode

false

Different from current out-of-the-box setting, which is true.

Setting -Djps.policystore.hybrid.mode=false reduces runtime overhead.

jps.combiner.optimize

true

Different from current out-of-the-box setting, which is false.

Setting -Djps.combiner.optimize=true improves Java2 authorization performance.

jps.combiner.optimize.lazyeval

true

Different from current out-of-the-box setting, which is false.

Setting -Djps.combiner.optimize.lazyeval=true improves Java2 authorization performance.


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.

Table 29-2 LDAP Policy Store Service Instance Properties

Name Default Recommended Description

oracle.security.jps.policystore.rolemember.cache.type

STATIC

STATIC

Role Member Cache Type.

oracle.security.jps.policystore.rolemember.cache.strategy

FIFO

FIFO

Role Member Cache Strategy.

oracle.security.jps.policystore.rolemember.cache.size

1000

5000

Role Member Cache Size.

oracle.security.jps.policystore.policy.lazy.load.enable

true

true

Enable Policy Lazy Load.

oracle.security.jps.policystore.policy.cache.strategy

PERMISSION_FIFO

PERMISSION_FIFO

Permission Cache Strategy.

oracle.security.jps.policystore.policy.cache.size

1000

1000

Permission Cache Size.

oracle.security.jps.policystore.cache.updateable

true

true

If true, policy cache is incrementally updated for management operations.

oracle.security.jps.policystore.refresh.enable

true

true

To refresh enabling.

oracle.security.jps.policystore.refresh.purge.timeout

43200000

43200000

Forced policy store refresh time in milliseconds.

oracle.security.jps.ldap.policystore.refresh.interval

600000

600000

Policy store refresh polling time in milliseconds.


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.

Table 29-3 OPSS Profilers

Category Logger Name Log Level Profiles

refresh

oracle.security.jps.policystore.refresh.full.profiler

FINE

The time taken by refresh for policies.

refresh

oracle.security.jps.policystore.refresh.partial.profiler

FINE

The time taken by fine-grained various activities during policy refresh.

policy management APIs

oracle.security.jps.policystore.management.profiler

FINE

The time taken by selective policy management APIs (getAllAppRoleEntries, searchAppRoles).

policy runtime APIs

oracle.security.jps.policystore.runtime.profiler

FINE

The time taken by on-demand loading (during cache miss) of direct roles and the granted permissions for a given user.

OPSS Filter and EJB Interceptor

oracle.security.jps.policystore.runtime.profiler

FINE

The time taken to compute the application roles for the give subject by the OPSS filter and the OPSS EJB interceptor.

Category

Logger Name

Log Level

Profiles

refresh

oracle.security.jps.policystore.refresh.full.profiler

FINE

The time taken by refresh for policies.

refresh

oracle.security.jps.policystore.refresh.partial.profiler

FINE

The time taken by fine-grained various activities during policy refresh.

policy management APIs

oracle.security.jps.policystore.management.profiler

FINE

The time taken by selective policy management APIs (getAllAppRoleEntries, searchAppRoles).

policy runtime APIs

oracle.security.jps.policystore.runtime.profiler

FINE

The time taken by on-demand loading (during cache miss) of direct roles and the granted permissions for a given user.

OPSS Filter and EJB Interceptor

oracle.security.jps.policystore.runtime.profiler

FINE

The time taken to compute the application roles for the give subject by the OPSS filter and the OPSS EJB interceptor.


29.3.3 Developing with the Credential Store Framework

This section specifies corrections to Chapter 17, Developing with the Credential Store Framework, of 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.4 Developing with the User and Role API

This section specifies corrections to Chapter 19, Developing with the User and Role API, of the Oracle Fusion Middleware Security Guide.

A Note about Using the User and Role APIs

As a general rule of thumb, authentication should only be performed by authentication providers, not through the User and Role APIs.

Additionally, it is recommended that authentication providers be configured with the connect DN of a user that does not have write privileges.

Additional Information for Example 1: Searching for Users

Section 19.7.1 "Example 1: Searching for Users", shows the following search filter:

.
.
SimpleSearchFilter sf = oidStore.getSimpleSearchFilter(
   UserProfile.NAME, SimpleSearchFilter.TYPE_EQUAL, null);
.
.

When searching for users, you invoke UserProfile, as in the above example. When searching for groups, however, you use RoleProfile instead.

29.3.5 Documentation Errata for the Oracle Fusion Middleware Security Overview

In the Oracle Fusion Middleware Security Overview, Section 4.6 Lockdown contains an incorrect link. The link should reference "Securing Applications" in Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server.

29.3.6 Configuring Single Sign-On in Oracle Fusion Middleware

Oracle Fusion Middleware 11g supports two new single sign-on solutions that applications can use to establish and enforce perimeter authentication:

  • Oracle Access Manager solutions

  • Oracle Single Sign-On (OSSO) solution

This section describes known issues in the chapter that describes these solutions in Oracle Fusion Middleware Security Guide. The following items will be corrected in the book with the next release:

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.

Note:

The phrase No Fusion Middleware Application refers to applications deployed on a stand-alone Oracle WebLogic Server.

The book currently contains the following incorrect details:

Incorrect: No Fusion Middleware Application

Correct: Applications Deployed on a Stand Alone WebLogic Server

Note:

The phrase No Fusion Middleware Application refers to applications deployed on a stand-alone Oracle 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.