A Troubleshooting Oracle Identity Federation

A.1.1.1 Requester ID in SAML 1.x Artifacts

Problem

When using the SAML 1.x Artifact mode, and the requester ID on the Domain page contains a colon ":", single sign-on using the artifact profile fails with this error at the service provider:

ERROR - RESPONDER: ERROR Unknown requester <domain name>

This problem is due to the use of the colon character, which is invalid in this context.

Solution

When specifying the requester ID for each domain, make sure that the string does not contain a ":" character.

A.1.1.2 Logout Displays No Return Page

Problem

When invoking the Oracle Identity Federation logout URL, the sign-off operation is performed, but the server does not display a result page; instead, it displays the last page visited by the browser, and the operation appears to have aborted even though logout was successful.

Solution

The logout service takes a returnurl parameter, which is required for correct operation. This problem occurs if no returnurl parameter is specified when invoking the Oracle Identity Federation logout URL. To avoid the problem, specify the returnurl parameter to point to the result page.

A.1.1.3 No JSESSIONID cookie Error

Problem

This problem is seen in a load-balancing configuration:

1. The IdP has two load-balanced Oracle Identity Federation instances.

2. A SAML 1.x SSO request of this type is issued:

   http://stitiasfw2.us.oracle.com:80/shareid/saml/ObSAMLTransferService?TARGET=http://target.us.oracle.com:80/test.html&DOMAIN=some-host.us.oracle.com&METHOD=POST

3. You log in with valid user credentials.

4. The following error results:

   ERROR - LOCAL LOGIN: ERROR: No JSESSIONID cookie in a POST request.

Solution

Ensure that the URLs in MyDomain at the load-balanced provider, and in the load-balanced domain at the other provider, have the hostname and address of the load-balancer, and not the hostname and address of one of the load-balanced Oracle Identity Federation instances.

A.1.2.1 Incorrect Login Page Appears

Problem

The following setup produces an incorrect login page:

1. Oracle Identity Federation is configured as a service provider.

2. The partner application is configured to be protected by Oracle Identity Federation.

3. When a user tries to access the protected resource, the Oracle Single Sign-On login page appears instead of the intended Oracle Identity Federation login page.

This problem can occur if the partner application is incorrectly configured for mod_osso, causing the user to be prompted for local authentication.

Solution

The steps required to ensure that the partner application is correctly configured for mod_osso are outlined here. Detailed information appears in the Oracle Application Server Single Sign-On Administrator's Guide.

1. Shut down Oracle HTTP Server and OC4J_SECURITY.

2. Edit the Oracle HTTP Server configuration file, ORACLE_HOME/Apache/Apache/conf/httpd.conf, located in the Oracle Application Server Infrastructure directory:

   • Add the osso_module to the server's loaded modules using the AddModule (Windows) and LoadModule (Windows, Linux) directives. See the Oracle Application Server Single Sign-On Administrator's Guide for an example.

   • Add a virtual host to create a new partner application listener that will be protected by mod_osso. See the Oracle Application Server Single Sign-On Administrator's Guide for details about configuring mod_osso with virtual hosts.

3. Run ssoreg to manually configure mod_osso and the Oracle Single Sign-On server.

   
   

   Note: Check that the osso_APPLICATION_NAME.conf matches the value defined in the virtual host configuration. See the Oracle Application Server Single Sign-On Administrator's Guide for details of ssoreg syntax and parameters, including instructions on how to provide directives for each protected host in the httpd.conf file.

   
   

4. Restart Oracle HTTP Server (OHS) And OC4J_SECURITY.

Additional information about integrating Oracle Identity Federation with Oracle Single Sign-On appears in the Oracle Application Server Single Sign-On Administrator's Guide.

A.1.2.2 Bookmarked Login Pages

Problem

Attempting to log in by means of a bookmarked login page returns an error. This is seen when a user follows this sequence:

• Perform a single sign-on (SSO) operation using SAML 2.0, Liberty, or WS-Federation protocols.

• On the login page, bookmark the page.

• Open a new browser instance and go to the bookmarked login page. Log in with valid user credentials.

The user will receive an error and SSO will fail.

Solution

Do not bookmark the login page. Oracle Identity Federation does not support the use of bookmarked login pages.

A.1.2.3 Error When Reissuing SAML 1.x URL After Timeout

Problem

This problem occurs when the service provider back-end is using OracleAS Single Sign-On. It occurs in this situation:

1. A SAML 1.x transfer URL is issued.

2. After waiting for the duration of the session timeout at the SP (set in OracleAS Single Sign-On and the Oracle Identity Federation administration console), reissue the same transfer URL in the same browser instance and log in again.

3. An internal server error is seen, or unusual redirection behavior may be observed.

When a resource is protected by OracleAS Single Sign-On and configured to use Oracle Identity Federation authentication, the only protocols that the OracleAS Single Sign-On server can initiate for authentication are Liberty 1.x and SAML 2.0. Consider a user who is authenticated using SAML 1.x or WS-Federation protocols, and who obtains access to such a resource. When its session times out, OracleAS Single Sign-On will redirect the user to Oracle Identity Federation for authentication using Liberty 1.x or SAML 2.0, which may result in server errors if the protocols are not configured, or unexpected redirection as the user is redirected to an IdP different from the SAML 1.x or WS-Federation login.

Solution

The immediate workaround is to close the browser instance and reissue the SAML 1.x SSO request in a new browser instance.

For a permanent solution, configure OracleAS Single Sign-On so that, when a user is authenticated by SAML 1.x/WS-Fed protocols, and accesses a resource protected by OracleAS Single Sign-On, when the session times out, the user is redirected back to OracleAS Single Sign-On for local authentication:

1. Open the Oracle_Home/sso/conf/policy.properties file.

2. Protect all the partner applications with the default OracleAS Single Sign-On server authentication plugin.

3. Configure the SASSO authentication plugin to have a higher security level than the OracleAS Single Sign-On server plugin.

A.1.3.1 AccessGate Permission Error

Problem

The following setup produces an AccessGate configuration error:

1. The Access Server SDK specifies a certain user under whom the AccessGate runs.

2. Oracle Identity Federation is installed on the Linux or Solaris platform under a different user.

3. When you apply the AccessGate configuration page for the Oracle Access Manager user data store, you receive the error:

   AccessGate configuration failed. Reason: Preparing to connect to AccessServer. Please wait. Error: Permission denied.

This error results from having different owners for the Oracle Identity Federation and Access Server SDK installations.

Solution

When Oracle Identity Federation is installed on Linux or Solaris, ensure that the AccessServerSDK files, installed at ORACLE_HOME/fed/shareid, have the same owner and group as the Oracle Identity Federation installation.

A.1.3.2 Non-ASCII AccessGate ID

Problem

If you attempt to configure an Oracle Access Manager User Data Store with an AccessGate, and the AccessGate ID contains non-Latin characters (for example, "ÆÖ2"), you get the error:

AccessGate configuration failed. Reason: Preparing to connect to Access Server. Please wait. Client authentication failed, please verify your AccessGate ID.

The problem also occurs when the AccessGate ID contains non-ASCII Latin-1 characters (for example, "Ådmïn").

Solution

Use only ASCII characters in the AccessGate ID for the Oracle Identity Federation AccessGate.

A.1.3.3 Setting LD_ASSUME_KERNEL Value

Problem

The Oracle Identity Federation instance (OC4J_FED) crashes when operating with an Oracle Access Manager back-end.

This problem may be due to an incorrect setting for the LD_ASSUME_KERNEL environment variable. This variable must be set to 2.4.19, because the Access Server SDK supports the Linux threading model and not the native posix thread library (NPTL).

For example, if LD_ASSUME_KERNEL is not set, you may see this type of error in the Oracle Identity Federation federation.log and federation-error.log files:

06/06/15 10:05:22: ERROR ShareIDLogger
- ObRareqService: EXCEPTION during initialization: (SVX001)
com.oblix.access.ObAccessException: 
Env variable LD_ASSUME_KERNEL not set to 2.4.19.
      at com.oblix.access.ObConfig.jni_initialize(Native Method)
      ...

An "internal server error" message may also be displayed at the user's browser.

Solution

Refer to "Integrate Oracle Identity Federation and Oracle Access Manager". Step 3 describes how to set LD_ASSUME_KERNEL using the AccessServerSDK installer.

A.1.3.4 Using the Same Cookie Domain for Two Back-ends

Problem

If your configuration involves two providers with Oracle Access Manager back-ends (IdP and SP2, for example), and both instances are using the same cookie domain, you may see an error when attempting single sign-on. The error message in the log file looks like this:

06/05/21 01:24:40: ERROR - COREID BRIDGE: ERROR The session token loggedoutcontinue is invalid: com.oblix.access.ObAccessException: Session token passed to the ObUserSession constructor is null or invalid. (NBE006)

This problem occurs when multiple Oracle Access Manager providers are using the same cookie domain.

Solution

You can resolve the issue by changing the Oracle Access Manager instances to use different cookie domains, or by using a different back-end (such as an LDAP back-end) at the IdP.

A.1.4.1 File Descriptors on Linux

Problem

You may experience intermittent Oracle Identity Federation server crashes with this error message in the federation-error.log file:

java.net.SocketException: Too many open files

This error occurs when the file descriptor limit is reached.

Solution

Increase the file descriptor limit, which is specified in the /etc/security/limits.conf configuration file.

In this example, the file descriptor limit is being set to a value of 16K:

soft nofile 16384 hard nofile 16384

Reboot the machine after changing the value.

A.1.5.1 404 Error when Using Oracle SmartMarks

Problem

The following configuration produces a 404 error when using Oracle SmartMarks:

1. Set up Oracle SmartMarks at source and destination sites; that is, enable Oracle SmartMarks in domain entries and enter the transfer query string in the source domain at the destination site.

2. Issue a SAML 1.x transfer URL. For example:

   http://ref1.refcompany.com:80/shareid/saml/ObSAMLTransferService?DOMAIN=titanium.refcompany.com&TARGET=https://sometarget.refcompany.com:2008/test.html&METHOD=POST

3. Close the browser and open a new browser instance.

4. Attempt to access the protected resource directly:

   https://sometarget.refcompany.com:2008/test.html

5. Enter valid credentials (username and password) when redirected to the source site for authentication.

After logging in, you get a 404 error instead of access to the protected resource.

This problem may occur due to the use of an incorrect transfer query string.

Solution

Check that the transfer query string does not include the actual target after the TARGET= keyword.

For example, this is an incorrect transfer query string:

DOMAIN=platinumob.refcompany.com&METHOD=POST&TARGET=https://sometarget.refcompany.com:2008/test.html

And this is the correct transfer query string:

DOMAIN=titanium.refcompany.com&METHOD=POST&TARGET=

A.1.5.2 Incorrect Identity Provider for SAML 1.x or WS-Federation

Problem

A user changes identity providers (for example, quits Company A and joins Company B) but is redirected to the old identity provider for an SP-initiated SSO with SAML 1.x or WS-Federation.

Solution

The user should clear any ObSAMLDomain cookies set in the browser.

A.1.5.3 Bookmarking a WS-Federation Protected Resource

Problem

If a user bookmarks a WS-Federation protected resource, and the service provider is using an OracleAS Single Sign-On back-end, the user will receive an error when later trying to access the bookmark.

Solution

Accessing WS-Federation protected resources directly is not supported if the SP is using an OracleAS Single Sign-On back-end. Users should not bookmark and later attempt to access the resource in this scenario.

A.1.6.1 Cannot Log in to the Administration Console

Problem

This problem is seen when Oracle Identity Federation server is integrated with Oracle Single Sign-On.

When performing a federated single sign-on using Oracle Identity Federation, where the user authenticates using OracleAS Single Sign-On, it is not possible to access the Oracle Identity Federation administration or monitoring console; access is denied, and authentication fails.

The Oracle Identity Federation consoles are protected by the JAZN module. This problem can be caused by a role conflict between OracleAS Single Sign-On and the JAZN module.

Solution

There are two possible solutions: for an immediate resolution, access the Administration or Monitoring console in a clean browser instance. For a durable solution, configure the administration and monitoring consoles to be protected by OracleAS Single Sign-On.

Take these steps to protect the consoles using OracleAS Single Sign-On:

1. Log on to the Oracle Enterprise Manager 10g Application Server Control Console.

2. At the console, navigate to OC4J_FED - > Applications - > fed or fedmon - > General.

3. Select "Use JAZN LDAP User Manager" which contains the Oracle Internet Directory location.

4. Click Apply.

5. Go to OC4J_FED - > Applications - > fed or fedmon - > Security.

6. Click Map Role To Principals.

7. Select user(s) or group(s) from the LDAP server that will have access to the console.

8. Click Apply.

9. Restart the OC4J_FED instance.

A user attempting to access the console will now be redirected to the OracleAS Single Sign-On server for authentication.