| Oracle® Application Server Release Notes 10g (10.1.4.0.1) for HP-UX PA-RISC (64-Bit) Part Number B32098-06 |
|
|
View PDF |
| Oracle® Application Server Release Notes 10g (10.1.4.0.1) for HP-UX PA-RISC (64-Bit) Part Number B32098-06 |
|
|
View PDF |
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 (10.1.4.3.0) and Note 743141.1 Oracle Identity Management 10g (10.1.4.3) Patch Set Notes Addendum for information about Oracle Application Server Single Sign-On.
This section describes the following issues and workarounds related to installation and upgrade:
Section 6.1.1, "Directory Considerations During Installation"
Section 6.1.2, "Directory Considerations After Installation"
Section 6.1.3, "Identity Management Grid Control Considerations During Uninstallation"
You must perform the following steps when installing Oracle Application Server 10.1.4.0.1 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:
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.
After installation is complete, you can reconfigure your load balancer to use any routing algorithm that you want.
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 GuideAfter 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:
Open a text editor and create a file with the following contents:
<consoleConfig>
<integration name="oracle_sso_server"
class="oracle.oimcontrol.sso.em.SSOIntegration"/>
</consoleConfig>
Save the file in the following location:
$ORACLE_HOME/j2ee/OC4J_EM/applications/em/em/WEB-INF/config/sso_server_intg.xml
Restart the Management Service server.
This section describes the following general issues and workarounds:
Section 6.2.4, "Clarification Needed for Implementing the IPASAuthInterface.java Package"
Section 6.2.5, "Multiple Single Sign-On Servers Cannot Share a Global User Inactivity Timeout"
Section 6.2.6, "A "Host Unavailable" Entry Appears on Non-English Monitoring Pages"
Section 6.2.7, "Dynamic Global Logout Directives Must Pass the String "Oracle SSO""
Section 6.2.8, "Multilevel Authentication Configuration May or May Not Require a Port Number"
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.
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:
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.
Enter the following:
update orasso.wwsec_person$ set guid = null ; commit;
To test this workaround, log in as the user who was deleted and re-created.
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:
cn=OperationURLs,cn=DAS,cn=Products,cn=OracleContext
Set the value for this attribute to the following:
https://servername:/SSO_HTTPS_PORT
If the default 443 port is used, set the value as follows:
https://servername
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 IPASAuthInterface.java 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."
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 myapplication1.mycompany1.com and myapplication2.mycompany2.com may be unable to access either application.
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.
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:
request.getSession().invalidate();
response.setHeader("Osso-Return-Url",redirectURL);
response.sendError(470, "Oracle SSO");
If any string other than "Oracle SSO" is passed as the parameter to sendError, global logout does not occur.
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:
pa1.mydomain.com\:7777 = HighSecurity pa2.mydomain.com\: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:
http://pa1.mydomain.com/partner application https://pa2.mydomain.com/parnter application
In the policy.properties file, the following root URLs would be used:
pa1.mydomain.com = HighSecurity pa2.mydomain.com = MediumSecurity
This section describes documentation errata. It includes the following topics:
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.
|
 Copyright © 2006, 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|