Oracle® Application Server Release Notes 10g (10.1.4) for Linux x86 Part Number B28193-08 |
|
|
View PDF |
This chapter describes issues associated with Oracle Identity Federation. It includes the following topics:
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 Identity Federation.
This section describes installation and upgrade issues. It includes the following topic:
Problem
During Oracle Identity Federation installation, the configuration assistant fails if you specify an SSL-enabled port to use in upgrading the LDAP schema for the Oracle Identity Federation data store.
The problem is seen under these conditions:
You are performing the installation on one of these platforms:
AIX 5L-based Systems (64-Bit),
IBM zSeries-based Linux, or
Linux on Power
On the "Select Configuration Options" page of the installer, you check the "Federation Data in LDAP Server" box, to specify that the LDAP schema should be upgraded during installation.
On the "Specify Federation Data Store" page of the installer, you check the box labeled "Select if this Port is an SSL Port", directing the installer to use the LDAP SSL port for the connection when doing the LDAP schema upgrade.
The Oracle Identity Federation Configuration Assistant fails at this stage of the installation. The failure is manifested in the install*Actions*.log
as well as the $ORACLE_HOME/fed/log/federation-install.log.
The install*Actions*.log
shows an error like this:
Opening connection to the LDAP server Error while interacting with the LDAP server: javax.naming.NamingException: Cannot connect to any LDAP Servers The Federation Configuration Assistant failed A log of the Federation Configuration Assistant is available at /project/as10/qa /fed_ssl/fed/log/federation-install.log java -jar install.jar <params> where params are: -oh ORACLE_HOME The ORACLE_HOME directory. Required -transient type The type of transient data store (rdbms or memory). Required -dbtnsname tnsname The RDBMS TNS name. Required if rdbms used for transient data store -dbusername username The RDBMS username. Required if rdbms used for transient data store -dbpwd password The RDBMS password. Required if rdbms used for transient data store -uselocalconfig <true|false> Indicates whether or not RDMBS config data will be overwritten
The $ORACLE_HOME/fed/log/federation-install.log s
hows an error related to an unsupported cipher suite:
07/10/25 14:09:47: ERROR oracle.security.fed.model.util.ldap.LDAPConnectionManager - javax.naming.CommunicationException: strsun03.us.oracle.com:636 [Root exception is java.lang.IllegalArgumentException: Unsupported ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA]
The problem is caused when the Oracle Identity Federation Configuration Assistant attempts to use some ciphersuites that are not supported by the JDK shipped on these platforms.
Solution
Oracle has issued a one-off patch set to fix the problem. With this fix, the installer first executes a query to get the supported ciphersuites, so that the Oracle Identity Federation Configuration Assistant attempts to use only that set of ciphersuites.
To apply this OracleAS 10.1.4.0.1 Oracle Identity Federation installation one-off patchset, download the zip file for the patch set. Follow the instructions in the README file included in the patchset.
The fix can be applied in either a corrective or a preventive mode:
If you encounter the Oracle Identity Federation Configuration Assistant failure described above, apply the one-off patchset and re-try the configuration assistant.
To avoid the Oracle Identity Federation Configuration Assistant failure altogether, apply the patchset immediately after the root.sh
popup window appears during installation.
After applying the patchset, run root.sh
as usual, then continue on with your installation. Your configuration assistants will then be executed, and the Oracle Identity Federation Configuration Assistant should run without any errors.
This section describes general issues and workarounds. It includes the following topics:
Section 8.2.1, "Credential Re-entry When Accessing a SiteMinder Protected Resource"
Section 8.2.3, "Attribute Sharing with the Microsoft Internet Information Server"
Section 8.2.4, "Redirection Loops with Oracle Access Manager"
Section 8.2.5, "Truncated Text in Japanese Version of Oracle Universal Installer"
Section 8.2.6, "Unused Assertion Profile With Invalid Attribute Mapping Can Cause SSO Failure"
Section 8.2.7, "Signed SAML 1.0 Assertions Can Cause SSO Failures"
Section 8.2.9, "Spurious Certificate Verification Failure in Debug Log"
Section 8.2.10, "Forced Reauthentication Not Supported with OracleAS Single Sign-On"
As of this release, if a user enters credentials to access a resource protected by SiteMinder, and subsequently tries to perform a single sign-on with the same browser using protocols supported by Oracle Identity Federation, the user is prompted to enter credentials a second time.
This issue concerns a scenario where Oracle Identity Federation is used as a service provider, OracleAS Single Sign-On is the user data store and an OracleAS Single Sign-On session is created for a federated user using SAML 1.x or WS-Federation. When that session expires, the service provider's Oracle Identity Federation server tries to reauthenticate the session using SAML 2.0. If SAML 2.0 is not enabled on the service and identity providers, the reauthentication will fail, typically with a 500 Internal Server Error.
This problem can be avoided by configuring OracleAS Single Sign-On. Open the ORACLE_HOME/sso/conf/policy.properties
file and protect all the partner applications with the default SSO server authentication plugin; configure the SASSO authentication plugin to have a higher security level than the OracleAS Single Sign-On server plugin.
With this configuration, when a user authenticated by SAML 1.x or WS-Federation protocol accesses a resource protected by OracleAS Single Sign-On, and the session times out, the user will be redirected to the OracleAS Single Sign-On server for local authentication instead of seeing an error from Oracle Identity Federation or an incorrect IdP.
The attribute sharing feature cannot be used with Microsoft Internet Information Servers (IIS) with Oracle Access Manager WebGate agents installed. For this feature an authentication plugin sets an HTTP header with the SubjectDN from the client's X.509 certificate, and an authorization plugin retrieves the header to initiate a SAML attribute query. However, because of the way the IIS WebGate performs SSL client certificate authentication, the SubjectDN header cannot be retrieved by the authorization plugin. In this case the following error is reported at the user's browser:
Oracle Access Manager Operation Error Access to the URL <targetURL> has been denied for user <OblixAnonymous user DN>.
Also, the following error messages are written to the OBACCESS_INSTALL/access/oblix/config/logs/authz_attribute_plugin_log.txt
file:
SubjectDN header ObNullString
and
SubjectDN is missing. Assume local user and return Continue
When Oracle Identity Federation is used as an identity provider with the Oracle Access Manager user data store, a user initiating additional SAML 1.x or WS-Federation single sign-ons might experience a redirection loop at the browser.
This occurs if the Oracle Access Manager AccessGate configured for Oracle Identity Federation has an Idle Session Timeout less than the Maximum user session time. In this case, if the user waits for the idle session timeout to elapse and then initiates another SSO, the redirection loop will occur.
This can be avoided by setting the Oracle Identity Federation AccessGate's Idle Session Timeout equal to or greater than the Maximum user session timeout (which is the default setting).
The following issue is observed during a Japanese-language installation session:
Start Oracle Universal Installer.
Choose the "Oracle Identity Federation 10g" installation option.
Proceed to the "Select Installation Method" page.
The text describing the first radio button ("Basic"), is truncated.
If Oracle Identity Federation is used as an identity provider with an LDAP or RDBMS user data store, a configured SAML 1.x assertion profile with a non-existent user attribute will cause all single sign-ons (SSOs) using the SAML 1.x and WS-Federation profiles to fail, even if they do not use the invalid profile.
When a user logs into an Oracle Identity Federation identity provider with the LDAP or RDBMS user data store, Oracle Identity Federation attempts to retrieve all user attributes in all configured assertion profiles. If any of the attributes are invalid, the SSO will fail.
With the RDBMS data store, the user will receive a 500 Internal Server Error
. If debug logging is enabled, the federation.log
file will show the following error:
RDBMSBridge.authenticate(): ERROR - SQL Exception thrown by JDBC: java.sql.SQLException: ORA-00904: "<attribute name>": invalid identifier
With the LDAP data store, the user will receive an Identity Federation error with ID TSE007
, and the federation.log
file will show an error:
RESPONDER: ERROR User directory entry for <userDN> does not have the <assertion attribute> attribute <user attribute>. (RSE027)
The workaround is to correct the invalid user attribute in the offending assertion profile, or delete the offending assertion profile.
Because SAML 1.0 does not fully specify how the XML Signature standard is to be used, Oracle Identity Federation cannot - within the context of a SAML response - correctly generate a signed SAML 1.0 assertion, nor verify a received signed SAML 1.0 assertion. Consequently, signatures on SAML 1.0 assertions used for the Artifact and POST SSO profiles are incorrect. If a user attempts to perform a single sign-on (SSO) using a SAML 1.x assertion profile with assertion singing enabled, and SAML 1.1 is not enabled for MyDomain or the destination domain, the service provider/destination site may not be able to verify the signature on the SSO assertion, causing the SSO to fail. If the destination site uses Oracle Identity Federation, the federation.log
file will show:
RECEIVER: ERROR: An invalid SAML Response was received: XML SIGNER: ERROR: Invalid signature or altered contents
The workaround is to use the SAML 1.1 protocol instead of SAML 1.0. (In fact, one of the reasons for the SAML 1.1 revision was to allow better use of XML Signatures.)
Note:
Signed assertions are not required, nor are they commonly used, for the SAML 1.x SSO profiles.By default, JDBC does not encrypt network connections between Oracle Identity Federation and the Oracle9i Database Server. Sites can optionally use Oracle Advanced Security to encrypt these connections.
In configuring Oracle Identity Federation to use Oracle Internet Directory or other LDAP servers to authenticate users, a site may choose whether to use SSL to connect to the LDAP server. If you do not use SSL, unencrypted passwords may be sent over network connections between Oracle Identity Federation and the LDAP server.
When a signing certificate issued by a third-party CA is installed in the keystore for the SAML 1.x/WS-Federation part of Oracle Identity Federation, and debug logging is enabled, a spurious error is reported:
XML SIGNATURE: cert verify check: FAILED - java.security.SignatureException: Signature does not match.
The certificate verification being performed is appropriate only for self-signed certificates. This error does not affect the operation of Oracle Identity Federation and the log message can be ignored.
Oracle Identity Federation does not support the ability to force re-challenging the user for credentials when integrated with OracleAS Single Sign-On. This means that Oracle Identity Federation cannot support use cases where reauthentication must be forced.
For example, if an SP sends an AuthnRequest with ForceAuthn="true"
to an Oracle Identity Federation IdP, and Oracle Identity Federation is integrated with OracleAS Single Sign-On, the ForceAuthn
flag is ignored.
This section describes configuration issues and workarounds. It includes the following topics:
Section 8.3.1, "Administration Console Is Not Accessible After Changing Transient Data Store"
Section 8.3.3, "Assertions Using SAML 1.x POST Method Fail in Japanese Locale"
Section 8.3.4, "Using RDBMS as a User Data Store with a Login column ID of type CHAR"
Section 8.3.5, "Some Peer Providers Are Not Displayed in Administration Console"
Section 8.3.6, "SAML 2.0 Metadata AttributeRequesterDescriptor Not Supported"
Section 8.3.7, "Problems Disabling Protocol Profiles in Administration Console"
Section 8.3.8, "Metadata Service URLs With Query Parameters Not Supported"
You may be unable to access the Oracle Identity Federation administration console in this situation:
The command-line configuration assistant is executed to change the RDBMS database used for the transient data store. The command format is as follows:
java -jar install.jar -transient rdbms <parameters>
After the command is executed, the Oracle Identity Federation administration console is not accessible, and the federation logs or the OPMN logs show errors like the following:
Invalid username/password
This issue is seen when switching the Oracle Identity Federation transient store from one database to another, using a different username/password combination, or when using the same database but with different credentials.
This problem arises because Oracle Identity Federation is already set up for RDBMS transient data store, but when the command-line configuration assistant is executed, the database password does not get reset; this results in the invalid username/password error when trying to perform any Oracle Identity Federation operations.
Use these steps to work around the problem:
Log on to the Oracle Enterprise Manager 10g Grid Control Console.
Navigate to OC4J_FED - > Administration - > Security.
In the Users list, click the jazn.com/oif_db entry.
Enter the correct password to access the RDBMS.
Apply, and restart the OC4J_FED instance.
When an Oracle Identity Federation IdP is configured to send signed both Response messages and Assertions, only the Assertions are signed.
This affects SSO and attribute sharing profiles for the Liberty 1.x and SAML 2.0 protocols. This does not affect profiles where a Response message does not contain an Assertion.
In the Japanese locale, assertions using the SAML 1.x POST method fail with this error:
ERROR: The SAML Response was not signed by the expected authority (RVE013)
The problem is due to the translated strings for OU and ST in the Signing Certificate Subject DN and the Signing Certificate Issuer DN.
As a workaround to this problem, the OU and ST values need to be replaced with the equivalent English strings. You can obtain the English value of the strings from the Issuer and Subject DN in the MyDomain configuration.
The instructions in the Oracle Identity Federation Administrator's Guide (Section 5.4.2.1, Configuring an RDBMS as the User Data Store) for using an Oracle database as the repository for the user data store omit additional steps required when the database table has a Login ID column of type CHAR
. These steps are necessary to account for the automatic padding applied in Oracle RDBMS for CHAR
data (which is not done for VARCHAR2
data).
Take the following steps to create a data source for an Oracle database table when the Login ID column is of type CHAR
:
Log in to the Enterprise Manager console of your Oracle Identity Federation instance and navigate to OC4J_FED - > Administration - > Data Sources.
Create a new data source using the following example as a guide:
Name: myDS Data Source Class: oracle.jdbc.pool.OracleDataSource JDBC URL: jdbc:oracle:thin:@stahs08.us.oracle.com:1521:ORCL JDBC Driver: oracle.jdbc.driver.OracleDriver Username: CUSTDATA Password: PASSWORD Location: jdbc/RDBMSUserDataSource
Apply the changes.
Restart the OC4J_FED instance.
Note:
Do not enter any information in the Transactional(XA) Location and EJB Location fields.n the administration console (Server Configuration > Circle of Trust page and Identity Federation > Trusted Providers page), the only three types of entities displayed are:
Identity Provider
Service Provider
Affiliation
If a provider's SAML 2.0 metadata does not contain either an SPSSODescriptor
, IdPSSODescriptor
, or AffiliationDescriptor
, then it is not placed into any of these three categories.
For example, if a peer provider has just an AttributeAuthorityDescriptor
in its metadata, it will not be displayed in the CoT page after loading. However, such a provider will still work properly at runtime, to the extent that the protocols published in its metadata are supported.
An XML parsing error occurs when SAML 2.0 metadata containing an AttributeRequesterDescriptor
element is loaded.
This results in a 500 Internal Server Error
in the administration console.
There is no workaround for this issue.
Disabling a protocol profile in the administration console (for example, Server Configuration > Identity Provider > SAML 2.0 > Enable Protocol Profiles) only controls which profiles get published in the generated metadata. At runtime, requests for those profiles would proceed as usual.
There is no workaround for this issue.
If metadata loaded for a peer provider contains service URLs (for example, AssertionConsumerService) that include query parameters, Oracle Identity Federation fails to correctly redirect to those URLs during runtime execution of the protocol profiles.
This section describes documentation errata. It includes the following topics:
Section 8.4.1, "Incorrect Header in Oracle Identity Federation Online Help"
Section 8.4.2, "Enhanced Description of Provider Configuration"
Section 8.4.3, "Update to Section 4.2.6.2 Creating a Custom Authentication Engine"
Online help pages in Oracle Identity Federation are incorrectly labeled with the title "Oracle Help for the Web 2.0 Beta". The correct title should be "Oracle Identity Federation Administration Help" for the Administration Console, and "Oracle Identity Federation Monitoring Help" for the Monitoring Console.
In the Oracle Identity Federation Administrator's Guide, the sections titled "Identity Provider - Global Settings" and "Service Provider - Global Settings" provide instructions on how to configure an identity provider (IdP) or a service provider (SP) for the IdP Discovery Profile using common domain cookies.
In the 10.1.4.0.1 release document (Part Number B25355-01), the section numbers are:
5.3.3.1 "Identity Provider - Global Settings" and
5.3.3.4 "Service Provider - Global Settings"
These instructions are insufficient for provider configuration; replace them with the following text:
5.3.3.1 Identity Provider - Global Settings
...
Common Domain URL
When the providers in a Circle of Trust have agreed upon a common domain for the IdP introduction cookie, each participating Identity Provider must have a cookie writing service hosted in the common domain.
An Oracle Identity Federation IdP runs the service on the /fed/idp/intro path; the HTTP server must be configured to listen for a host:port in the common domain. Once this is done, the common domain URL can be constructed.
For example, if the agreed-upon common domain is .cdc.example.org, and the Oracle Identity Federation IdP is hosted on idp.mycorp.com, then the IdP's HTTP server could be configured to listen on mycorpidp.cdc.example.org:7778. Then the Common Domain URL for the IdP's cookie-writing service would be:
http://mycorpidp.cdc.example.org:7778/fed/idp/intro
Set this value only if you checked Common Domain Enabled.
5.3.3.4 Service Provider - Global Settings
...
Common Domain Enabled
When an identity federation network contains multiple identity providers, a service provider needs to have a way to determine the identity provider(s) in use by a principal. This can be achieved by having all the IdPs and SPs in the federation network agree on a cookie domain, and sending to the user's browser a cookie written in this domain; the cookie lists all the IdPs where the user has logged in. Such a domain is known as a common domain, and the cookie identifying the IdPs is called a common domain cookie or IdP introduction cookie.
Check Common Domain Enabled to specify that this SP should read the introduction cookie to discover the IdP to use for authentication.
Common Domain URL
When the providers in a Circle of Trust have agreed upon a common domain for the IdP introduction cookie, each participating Service Provider must have a cookie reading service hosted in the common domain.
An Oracle Identity Federation SP runs the service on the /fed/sp/introsso path; the HTTP server must be configured to listen for a host:port in the common domain. Once this is done, the Common Domain URL can be constructed.
For example, if the agreed-upon common domain is .cdc.example.org, and the Oracle Identity Federation SP is hosted on sp.mycorp.com, then the SP's HTTP server could be configured to listen on mycorpsp.cdc.example.org:7778. Then the Common Domain URL for the SP's cookie-reading service would be:
http://mycorpsp.cdc.example.org:7778/fed/sp/introsso
Set this value only if you checked Common Domain Enabled.
In Section 4.2.6.2, Creating a Custom Authentication Engine, of the Oracle Identity Federation Administrator's Guide for 10g (10.1.4.0.1), part number B25355-02, after following the instructions you are unable to complete login. The browser gives you the error message:
"500 Internal Server Error"
The Oracle Identity Federation federation.log
file and the federation-error.log
file show the following error:
ERROR - LOCAL LOGIN: ERROR: No JSESSIONID cookie in a POST request.
The steps in Section 4.2.6.2 of the guide are incomplete. To resolve the issue:
Apply the steps listed in Knowledge Base Note 345167.1.
Note:
The patch mentioned in the note is already included in version 10g (10.1.4), so if you are running version 10g (10.1.4) or higher, you only need to set the -Doracle.useSessionIDFromCookie=true flag as shown in the document.Restart the Oracle Identity Federation instance
To access Knowledge Base Note 345167.1
Go to My Oracle Support and login as usual:
https://support.oracle.com
Click Knowledge (upper-left corner).
In the Search Knowledge Base field (upper right corner), enter 345167.1
. Click the magnifying glass icon.
Click the title on the results page that states "HTTP Session Info lost between two web applications when common "cookie-path" (e.g. "/") for JSESSIONID [ID 345167.1]" to read the note.