This appendix describes common problems that you may encounter when configuring and using Oracle Identity Federation, and explains how to solve them.
This section describes common problems and solutions arranged in these topical groups:
This section describes general issues and workarounds. It includes the following topics:
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 plug-in 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 plug-in. 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
SubjectDN header ObNullString
SubjectDN is missing. Assume local user and return Continue
There is no workaround for this problem, other than to use a different web server such as the Oracle HTTP Server or the Sun One Web Server.
Because SAML 1.0 does not fully specify how the XML Signature standard is to be used, implementations of the SAML 1.0 protocol sometimes have difficulty inter-operating: an SP/RP might be unable to verify the XML Digital Signature created by a SAML 1.0 IdP.
Consequently, during a Federation SSO operation between an identity provider and a service provider using SAML 1.0 protocol, errors could be raised on the service provider server during the verification of the SAML response and the SAML assertion.
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.)
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 Federationand the Oracle Database. 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 Oracle Identity Federation needs to connect to an LDAP Server using SSL - with or without Client certificate Authentication - you first need to add the necessary certificates to the Identity and Trust Keystores in the Oracle WebLogic Server Administration Console; this information is provided on the Server/Keystores configuration screen for the managed server where Oracle Identity Federation is running.
When Oracle Identity Federation needs to connect to an LDAP Server using SSL, and you encounter connection errors, make sure that the following are true:
Oracle WebLogic Server managed server needs to be updated to have the correct keystore/certificates, and
the administration server where Fusion Middleware Control is running must also have the correct keystore/certificates
If using an Oracle Internet Directory server, note that in Oracle Internet Directory, SSL with no authentication cannot be disabled, and thus SSL connections to Oracle Internet Directory might be created with no server authentication.
When an RDBMS message store is in use, you may see warnings like these in the log:
[2009-02-05T11:43:34.322-08:00] [wls_oif1] [WARNING] [FED-12032] [oracle.security.fed.jvt.discovery.model.profilestate.RDBMSProfileStateDiscove ryProvider] [tid: Thread-25] [userId: <anonymous>] [ecid: 0000Hx7vp6JESO8nvgZBF119YUEk000004,1:5576] [APP: Oracle Identity Federation#22.214.171.124.0] [arg: java.lang.InterruptedException: sleep interrupted] InterruptedException: thread interrupt occurred during sleep() java.lang.InterruptedException: sleep interrupted
These routine messages are part of normal operation and simply indicate that the RDBMS cleaning threads are stopped.
No action is required.
When the Oracle Identity Federation server is configured to use the SSL port of a proxy OHS, the metadata file appears to be corrupted when attempting to open or load the metadata (using Fusion Middleware Control, on the federation server's security and trust page, metadata tab.
When Oracle Identity Federation is configured for SSL, the Oracle WebLogic Server Administration Server where the Fusion Middleware Control console is running should trust the SSL certificate (or the CA of the certificate) of the Oracle WebLogic Managed Server Managed Server where Oracle Identity Federation is running.
To configure the Oracle WebLogic Server to trust an SSL certificate (or its CA), you must add the necessary certificate as a trusted certificate entry to the JSSE Trust Keystore used by the Administration Server for SSL connections.
Oracle WebLogic Server documentation on how to change the JSSE Trust Keystore for use in SSL connections, if needed.
Java documentation on how to use
keytool to add a certificate as a Trusted Cert Entry in the JSSE Trust Keystore.
After installation, a configuration assistant performs a number of configuration updates to the Oracle Identity Federation server using MBeans. Another task periodically checks to see if the configuration files were changed so that the server can be notified.
A parsing error during this procedure can result in the following type of message in the diagnostic log file:
$DOMAIN_HOME/servers/wls_oif1/logs/wls_oif1-diagnostic.log . [org.xml.sax.SAXParseException: XML document structures must start and end within the same entity.] at javax.xml.bind.helpers.AbstractUnmarshallerImpl.createUnmarshalExcept ion(AbstractUnmarshallerImpl.java:315) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.createUnmar shalException(UnmarshallerImpl.java:514) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0( UnmarshallerImpl.java:215) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(U nmarshallerImpl.java:184) at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnm arshallerImpl.java:137) at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnm arshallerImpl.java:184) at oracle.as.config.persistence.jaxb.JAXBXmlPersistenceManagerImpl.load( JAXBXmlPersistenceManagerImpl.java:156) ... 10 more Caused by: org.xml.sax.SAXParseException: XML document structures must start and end within the same entity. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAX ParseException(ErrorHandlerWrapper.java:195) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalErro r(ErrorHandlerWrapper.java:174) .
Provided that the Oracle Identity Federation server is up and running (
/fed/idp/metadata can be accessed without any errors), the message is harmless and has no effect on the stability of the server. The configuration change occurs as intended, and all the servers are notified of the change.
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.
A schema violation error occurs when performing a Liberty 1.x / SAML 2.0 single sign-on operation, with the federation data store residing in an LDAP server. The
diagnostics.log shows the following error message:
[LDAP: error code 65 -
Failed to find orclfednamevalue in mandatory or optional attribute list.]
This problem is seen if the schema of the federation data store's LDAP server has not been upgraded to include the Oracle Identity Federation attributes and object classes.
Upgrade the LDAP schema either at installation time (with the Advanced Installation mode), or after installation.
Upgrade Schema at Installation
To perform the upgrade at installation time, take these steps:
Choose the Advanced Installation mode.
On the "Select Oracle Identity Federation Advanced Flow Attributes" page, select the "LDAP" option from dropdown for Federation Store. This indicates that the federation records will be stored in an LDAP server whose schema must be upgraded.
On the "Specify LDAP Attributes for Federation Data Store" page, enter the LDAP connection information. The schema will then be upgraded as part of the installation process.
Post-Installation Schema Upgrade
To perform the upgrade post-installation, note that the Oracle Identity Federation installation includes
LDIF files that you can execute using the
ldapmodify tool to upgrade the schema of an LDAP server.
LDIF file to use depends on the type of LDAP server used:
$Oracle_Home/fed/setup/ldap/userFedSchemaOid.ldif if you use Oracle Internet Directory
$Oracle_Home/fed/setup/ldap/userFedSchemaSunOne5.ldif if you use the Sun One Directory Server 5.x
$Oracle_Home/fed/setup/ldap/userFedSchemaSunOne6.ldif if you use the Sun One Directory Server 6.x
$Oracle_Home/fed/setup/ldap/userFedSchemaTivoli.ldif if you use IBM Tivoli
$Oracle_Home/fed/setup/ldap/userFedSchemaAD.ldif if you use Microsoft Active Directory Server. In this case, you need to edit the LDIF file to replace the string
%DOMAIN_DN% with your active directory domain suffix.
An example suffix is
ldapmodify, you can upgrade the LDAP schema with the LDIF file. For example:
ldapmodify -c -D BIND_DN_USERNAME -w PASSWORD -f $Oracle_Home/fed/setup/ldap/userFedSchemaOid.ldif -h LDAP_HOSTNAME -p LDAP_PORT -x
In Fusion Middleware Control, when you configure audit policies for Oracle Identity Federation events, note that even though the EM audit policy page shows both success and failure event types for all of the Oracle Identity Federation events, as a rule most Oracle Identity Federation configuration change events only have SUCCESS status by design.
The following events are the only Oracle Identity Federation events where failures are audited:
When using the Oracle Enterprise Manager Fusion Middleware Control to migrate a configuration data store to RDBMS, a JNDI name must be supplied. You may see the following warning message in the server log during the operation:
<Warning> <oracle.security.fed.controller.web.servlet.OIFApplicationLifeCycleCallBack> <FED-10205> <The JNDI name for RDBMS configuration backend is empty.> <Warning> <oracle.security.fed.controller.web.servlet.OIFApplicationLifeCycleCallBack> <FED-10205> <The JNDI name for RDBMS configuration backend is empty.>
This message can be ignored; however if it persists, check that the correct JNDI name is entered in Fusion Middleware Control.
When Oracle Identity Federation is configured to use a database store for session and message data store, the following error is seen if data for
IDPPROVIDEDNAMEID is over 200 characters long:
ORA-12899: value too large for column "WDO_OIF"."ORAFEDTMPPROVIDERFED"."IDPPROVIDEDNAMEIDVALUE" (actual: 240, maximum: 200)\n]
As a workaround to this problem, alter table
ORAFEDTMPPROVIDERFED to increase the column size for "idpProvidedNameIDValue" to 240.
This section describes issues that you may encounter when Oracle Identity Federation is the service provider (SP), and Oracle Single Sign-On is configured as the identity provider (IdP) at the back end. It contains these topics:
Oracle Identity Federation is configured as a service provider.
The partner application is configured to be protected by Oracle Identity Federation.
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.
The steps required to ensure that the partner application is correctly configured for
mod_osso are outlined here. Detailed information appears in the Oracle Enterprise Single Sign-On Suite Plus Administrator's Guide.
Shut down Oracle HTTP Server and OC4J_SECURITY.
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 Enterprise Single Sign-On Suite Plus 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 Enterprise Single Sign-On Suite Plus Administrator's Guide for details about configuring
mod_osso with virtual hosts.
ssoreg to manually configure
mod_osso and the Oracle Single Sign-On server.
Check that the
osso_APPLICATION_NAME.conf matches the value defined in the virtual host configuration.
See the Oracle Enterprise Single Sign-On Suite Plus Administrator's Guide for details of
ssoreg syntax and parameters, including instructions on how to provide directives for each protected host in the
Restart Oracle HTTP Server (OHS) And
Additional information about integrating Oracle Identity Federation with Oracle Single Sign-On appears in the Oracle Enterprise Single Sign-On Suite Plus Administrator's Guide.
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.
Do not bookmark the login page. Oracle Identity Federation does not support the use of bookmarked login pages.
After using the Firefox browser to upload provider metadata from the Federations page in Fusion Middleware Control, you cannot modify the provider metadata file that you just uploaded until you restart Firefox.
The reason for this is the Live HTTP Header add-on in Firefox. Once you disable this add-on and restart Firefox, you can modify the provider metadata file after you have uploaded the metadata on the Federations page.
The Access Server SDK specifies a certain user under whom the AccessGate runs.
Oracle Identity Federation is installed on the Linux or Solaris platform under a different user.
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 Access Server. Please wait. Error: Permission denied.
This error results from having different owners for the Oracle Identity Federation and Access Server SDK installations.
When Oracle Identity Federation is installed on Linux or Solaris, ensure that the AccessServerSDK files have the same owner and group as the Oracle Identity Federation installation.
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").
Use only ASCII characters in the AccessGate ID for the Oracle Identity Federation AccessGate.
Oracle Identity Federation fails to configure Oracle Access Manager for use as SP integration module when you try to set up this configuration using Fusion Middleware Control. This occurs when operating with an Oracle Access Manager back-end version 10.1.4.2 or earlier.
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 log files:
com.oblix.access.ObAccessException: Env variable LD_ASSUME_KERNEL not set to 2.4.19. at com.oblix.access.ObConfig.jni_initialize(Native Method) ...
The browser also shows an error during this setup (that is, when you try to configure Oracle Access Manager as an SP integration module using Fusion Middleware Control).
Refer to Section 126.96.36.199, "Integrate Oracle Access Manager as an SP Integration Module" which describes how to set
LD_ASSUME_KERNEL in the Oracle WebLogic Server environment.
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.
This problem occurs when multiple Oracle Access Manager providers are using the same cookie domain.
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.
You may see one of these errors when configuring Oracle Identity Federation to integrate with Oracle Access Manager 10g through Fusion Middleware Control:
2009-03-09T21:54:56.354-07:00] [wls_oif1] [INCIDENT_ERROR] [FED-10192] [oracle.security.fed.admin.config.mbeans.OAMConfigUtils] [tid: [ACTIVE].ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <WLS Kernel>] [ecid: 0000HziivsZ7IBT6uBr2EH19hQcU000017,1:5006] [APP: Oracle Identity Federation#188.8.131.52.0] Oracle Access Server SDK could not be initialized
Check the configuration of Oracle Identity Federation with Oracle Access Manager and AccessServerSDK.
You may see this error when Oracle Identity Federation is integrated with Oracle Access Manager 10g and a user attempts to access the OAM-protected resource:
Error: oracle.security.fed.event.EventException: com.oblix.access.ObAccessException: Unprotected resource GET used in an ObAuthenticationScheme or ObUserSession constructor
If this error is encountered, check that the host ID has the Oracle Identity Federation port (for example, port 7499).
Some issues listed in this section may have a system-wide impact on the Oracle Identity Federation server, while others may only impact a specific component such as a particular federation partner.
java.net.SocketException: Too many open files
This error occurs when the file descriptor limit is reached.
Increase the file descriptor limit, which is specified in the
/etc/security/limits.conf configuration file.
If no file descriptor limit is defined, the server uses a default value of 1024.
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.
Accessing WS-Federation protected resources directly is not supported if the SP is using an Oracle Single Sign-On back-end. Users should not bookmark and later attempt to access the resource in this scenario.
When using a Name ID format such as email address (mapped to an attribute value such as 'mail'), the user is initially able to perform SSO, and federation records are generated at the IdP and SP.
However, it is possible that the value for the attribute (such as mail) may change. After the change, the IdP still sends the old Name ID value (in this case, the old email address) in the assertion, causing SSO to fail.
The Oracle Identity Federation administrator should update the federation records to reflect the new attribute values.
This section contains these topics:
When using an LDAP-based data store, users may see the following error in the log when there is heavy login activity at the server:
Internal Error: 500
This is likely due to inadequate tuning of the LDAP store. Make sure that the connection pool for your LDAP server is properly tuned.