Skip Headers
Oracle® Application Server Release Notes
10g ( for Linux on POWER

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

Go to previous page
Go to next page
View PDF

6 Oracle Application Server Single Sign-On

This chapter provides information about known issues and workarounds for Oracle Application Server Single Sign-On (OracleAS Single Sign-On). The following topics are included:

In addition to these release notes, please also see Patch Notes 10g ( and Note 743141.1 Oracle Identity Management 10g ( Patch Set Notes Addendum for information about Oracle Application Server Single Sign-On.

6.1 Installation, Installation and Upgrade Issues

This section describes the following issues and workarounds related to installation and upgrade:

6.1.1 Directory Considerations During Installation

You must perform the following steps when installing Oracle Application Server Identity Management infrastructure components in an environment that uses an Identity Management High Availability (IMHA) Oracle Internet Directory LDAP cluster with a load balancing router. Failure to perform these steps can cause issues during installation.

This should also be the case for all Identity Management mid-tier installations in a distributed configuration.

To install when using an IMHA Oracle Internet Directory LDAP cluster with a load balancer or virtual server:

  1. Prior to starting the installation, ensure that the load balancing router or Oracle Internet Directory virtual server sends all traffic to just one active Oracle Internet Directory instance for the duration of the installation process.

    For example, you can configure for affinity (IP-based) routing to ensure that traffic from one IP address is always routed to the same destination.

  2. After installation is complete, you can reconfigure your load balancer to use any routing algorithm that you want.

6.1.2 Directory Considerations After Installation

After you install and configure an OracleAS Cluster (Identity Management) environment, Application Server Control incorrectly indicates that some of the Identity Management components are down and not available. To remedy this problem, stop and then start the Application Server Control.

See Also:

"Starting and Stopping the Application Server Control" in the Oracle Application Server Administrator's Guide

6.1.3 Identity Management Grid Control Considerations During Uninstallation

After uninstalling the Identity Management Grid Control plug-in for Oracle Management Service (Management Service), you must create a new configuration file in the Management Service Oracle home directory. Failure to create this file can cause problems after uninstalling the plug-in. The file enables Oracle Enterprise Manager 10g Grid Control (Grid Control) to find the configuration class for specific single sign-on monitoring pages. These pages are used for default Grid Control Management Service installations that do not have Identity Management Grid Control 10.1.4IM.

To avoid issues after uninstalling the Identity Management Grid Control Management Service plug-in:

  1. Open a text editor and create a file with the following contents:

       <integration name="oracle_sso_server"
  2. Save the file in the following location:

  3. Restart the Management Service server.

6.2 General Issues

This section describes the following general issues and workarounds:

6.2.1 Oracle Directory Manager Is no Longer Supported

Appendix B, "Obtaining the Single Sign-On Schema Password" in the Oracle Application Server Single Sign-On Administrator's Guide states that you can find the password using either the command-line tool ldapsearch or Oracle Directory Manager. However, Oracle Directory Manager is no longer supported.

Use the command-line tool ldapsearch to find the single sign-on schema password.

6.2.2 Deleting and Recreating a User Causes an Error When Accessing an External Application

If an administrator drops, then re-creates a user's entry in the Oracle Portal, the user can receive an error when accessing an external application. Dropping and re-creating the user causes the ORASSO.WWSEC_PERSON$ table to have a different value for the user's GUID than the GUID that is returned by an OracleAS Single Sign-On login to Oracle Internet Directory.

The error is as follows:

There is a conflict with your assigned user name. There is a user entry with this name, but with a different globally unique identifier, 
which must be resolved before you can log on with this name. Please inform your administrator. (WWC-41742).

The following is a workaround for this issue:

  1. Log in to SQLPLUS as an ORASSO user.

    See Appendix B, "Obtaining the Single Sign-On Schema Password" in the Oracle Application Server Single Sign-On Administrator's Guide for information on using the command-line tool ldapsearch. Note that Oracle Directory Manager is no longer supported.

  2. Enter the following:

    update orasso.wwsec_person$ set guid = null ;

To test this workaround, log in as the user who was deleted and re-created.

6.2.3 You Must Change the Value for the ORCLDASURLBASE Attribute in Oracle Internet Directory After Enabling SSL

After you enable single sign-on for HTTPS, you also must change the value for the ORCLDASURLBASE attribute in Oracle Internet Directory. You can find this attribute in the following location:


Set the value for this attribute to the following:


If the default 443 port is used, set the value as follows:


6.2.4 Clarification Needed for Implementing the Package

In the section on "Integrating with Third-Party Access Management Systems Using Integration APIs" in the Oracle Application Server Single Sign-On Administrator's Guide, there is information on the package. This section needed to mention that the p2store token needs to be sent back from the single sign-on server. The redirection URL must be appended to the URL in the getUserCredentialPage() function.

The following note will be added to the next version of this manual:

"To implement this interface, you must modify your code to redirect the user to the OracleAS Single Sign-On login URL. This is the URL that the third-party application is protecting. You must also append the URL in getUserCredentialPage() to include the site2pstoretoken."

6.2.5 Multiple Single Sign-On Servers Cannot Share a Global User Inactivity Timeout

The global user inactivity timeout is a feature that enables applications to force you to reauthenticate if you have been idle for a preconfigured amount of time. This timeout is a useful feature for sensitive applications that require a shorter user inactivity timeout than the single sign-out session timeout.

However, this timeout value can cause problems in a cookie domain that contains other applications that are protected by a different single sign-on server. For example, if the timeout is configured for the cookie domain ".com", a user who accesses and may be unable to access either application.

6.2.6 A "Host Unavailable" Entry Appears on Non-English Monitoring Pages

This bug applies only to the monitoring pages for single sign-on in Grid Control.In browsers that are configured for non-English languages (for example, ja, zh_CN, zh_TW, ko_KR, or fr), an entry labeled "HOST Unavailable" is displayed in the general section of the Single Sign-On Service monitoring home page. This string appears in the language configured for the browser. The "HOST Unavailable" entry is a link. If you click this link, the browser displays the message, "Error finding target UNAVAILABLE from the repository. The target does not exist or you may not have the access to the target."

You can safely ignore this error and its associated link.

6.2.7 Dynamic Global Logout Directives Must Pass the String "Oracle SSO"

If you use mod_osso for dynamic directive-based global logout, you must pass the string "Oracle SSO" as the response error message. The following is an example of a properly constructed directive:

response.sendError(470, "Oracle SSO"); 

If any string other than "Oracle SSO" is passed as the parameter to sendError, global logout does not occur.

6.2.8 Multilevel Authentication Configuration May or May Not Require a Port Number

In the current OracleAS Single Sign-On Administrators Guide section on multilevel authentication, the instructions indicate that you must include a port number when configuring an authentication level. However, if default ports are being used in the URL, you can omit the port number.

The following is the correct Step 2 of the procedure for configuring multilevel authentication:

Assign authentication levels to the root URLs of the two partner applications:\:7777 = HighSecurity\:7777 = MediumSecurity

Be sure to include the backslash after the domain name.

If the URL of the partner application being called uses the default SSL or non-SSL port, the port is not specified in the URL. If this is the case, when defining the root URL of the partner application you do not have to include /:port.

For example, suppose the following URLs are called for a partner application: application application

In the file, the following root URLs would be used: = HighSecurity = MediumSecurity

6.3 Documentation Errata

This section describes documentation errata. It includes the following topics:

6.3.1 Incomplete Information in "Developing Applications for Single Sign-On" Chapter of Oracle Identity Management Application Developer's Guide

Table 9-1, User Attributes Passed to Partner Applications, mentions that the Remote-User header is recommended for pre-9.0.4 applications only. It does not explain why. The reason is that the Remote-User header is unique only within a domain. In release 9.0.4 and later, OracleAS Single Sign-On supports multiple domains, so you should use a header that is unique across domains, such as Osso-User-Guid.