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 shows an error related to an unsupported cipher suite:

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.

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.

7.2 General Issues and Workarounds

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

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.

7.2.2 Reauthentication after Session Timeout with OracleAS Single Sign-On and SAML 1.x or WS-Federation

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:

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

7.2.4 Redirection Loops with Oracle Access Manager

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

7.2.5 Truncated Text in Japanese Version of Oracle Universal Installer

The following issue is observed during a Japanese-language installation session:

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:

The workaround is to correct the invalid user attribute in the offending assertion profile, or delete the offending assertion profile.

7.2.7 Signed SAML 1.0 Assertions Can Cause SSO Failures

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:

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.

7.2.8 Encrypting Network Connections

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.

7.2.9 Spurious Certificate Verification Failure in Debug Log

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:

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.

7.2.10 Forced Reauthentication Not Supported with OracleAS Single Sign-On

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.

7.3 Configuration Issues and Workarounds

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

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.

7.3.2 Signing SAML Response with Assertion

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.

7.3.3 Assertions Using SAML 1.x POST Method Fail in Japanese Locale

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.

7.3.4 Using RDBMS as a User Data Store with a Login column ID of type CHAR

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:

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.

7.3.6 SAML 2.0 Metadata AttributeRequesterDescriptor Not Supported

This results in a 500 Internal Server Error in the administration console.

There is no workaround for this issue.

7.3.7 Problems Disabling Protocol Profiles in Administration Console

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.

7.3.8 Metadata Service URLs With Query Parameters Not Supported

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.

7.4 Documentation Errata

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

7.4.1 Incorrect Header in Oracle Identity Federation Online Help

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.

7.4.2 Enhanced Description of Provider Configuration

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:

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.