| Oracle® Identity Federation Administrator's Guide 10g (10.1.4.0.1) B25355-02 |
|
 Previous |
 Next |
| Oracle® Identity Federation Administrator's Guide 10g (10.1.4.0.1) B25355-02 |
|
Previous |
Next |
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:
Reauthentication after Session Timeout with OracleAS Single Sign-On and SAML 1.x or WS-Federation
Attribute Sharing with the Microsoft Internet Information Server
Truncated Text in Japanese Version of Oracle Universal Installer
Unused Assertion Profile With Invalid Attribute Mapping Can Cause SSO Failure
Problem
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.
Solution
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 theOracleAS Single Sign-On server for local authentication instead of seeing an error from Oracle Identity Federation or an incorrect IdP.
Problem
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
Solution
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.
Problem
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.
Solution
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.
Problem
If Oracle Identity Federation is used as an identity provider with an 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 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.
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
Solution
The workaround is to correct the invalid user attribute in the offending assertion profile, or delete the offending assertion profile.
Problem
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
Solution
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 Federationand 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.
This section describes server configuration issues:
Administration Console Is Not Accessible After Changing Transient Data Store
Assertions Using SAML 1.x POST Method Fail in Japanese Locale
Problem
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.
Solution
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.
Problem
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.
Solution
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.
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.
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.
Problem
This problem is seen in a load-balancing configuration:
The IdP has two load-balanced Oracle Identity Federation instances.
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
You log in with valid user credentials.
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.
Problem
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 $Oracle_Home/fed/log/federation.log shows the following error message:
javax.naming.directory.SchemaViolationException: [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.
Solution
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 Configuration Options" page, check the "Federation Data in LDAP Server" box. This indicates that the federation records will be stored in an LDAP server whose schema must be upgraded.
On the "Specify 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.
The 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/userFedSchemaIPlanet.ldif if you use the Sun One Directory Server
$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 dc=mydomain,dc=mycompany,dc=com.
Using 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
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:
Problem
The following setup produces an incorrect login page:
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.
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.
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 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.
Run ssoreg to manually configure mod_osso and the Oracle Single Sign-On server.
|
Note:
|
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.
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.
Problem
This problem occurs when the service provider back-end is using OracleAS Single Sign-On. It occurs in this situation:
A SAML 1.x transfer URL is issued.
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.
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:
Open the Oracle_Home/sso/conf/policy.properties file.
Protect all the partner applications with the default OracleAS Single Sign-On server authentication plugin.
Configure the SASSO authentication plugin to have a higher security level than the OracleAS Single Sign-On server plugin.
This section describes issues that you may encounter when configuring Oracle Access Manager components at the back end. It contains these topics:
Problem
The following setup produces an AccessGate configuration error:
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 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.
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.
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.
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.
This section describes issues related to the configuration of the operating system of the machine where Oracle Identity Federation is installed:
|
Note: 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. |
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.
|
Note: 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.
When searching for information in an Active Directory environment that is configured for LDAP referrals, the referrals fail if the host being referred to is in a different domain than the Active Directory server.
Problem
When a user requests a resource, at times verification of the user's identity can fail due to an inability to validate the user's identity in the directory. This error can occur in an Active Directory environment when the user's browser runs on a non-Windows computer, or if the user's browser runs on a Windows computer that is not in the Active Directory server domain.
This problem can arise due to LDAP referral chasing. An LDAP referral occurs when a domain controller does not have the section of the directory tree where a requested object resides. The domain controller refers the client to another destination so that the client can conduct a DNS search for another domain controller. If the client is configured to chase referrals, the search can continue.
For the scenario where the user has a Windows-based computer, an issue can occur with LDAP referrals if the client's domain controller does not have a trust relationship with the Active Directory domain controller.
Solution
If you encounter this issue, add the entry for the Active Directory host's address in the following list:
WINDOWS_HOME_DIRECTORY\system32\drivers\etc\hosts
On Windows XP, the list is located here:
C:\WINDOWS\system32\drivers\etc\host
On a Unix-based system, add this entry to the /etc/hosts file, using the format:
IP_address_of_AD_host AD_host_name
where AD_host_name is the host name specified in the referral, for example:
123.123.123.123 my2003ad.com
This section describes various runtime and single sign-on issues that you may encounter when using Oracle Identity Federation:
Problem
The following configuration produces a 404 error when using Oracle SmartMarks:
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.
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
Close the browser and open a new browser instance.
Attempt to access the protected resource directly:
https://sometarget.refcompany.com:2008/test.html
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=
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.
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.
This section contains issues related to the Oracle Identity Federation 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:
Log on to the Oracle Enterprise Manager 10g Application Server Control Console.
At the console, navigate to OC4J_FED - > Applications - > fed or fedmon - > General.
Select "Use JAZN LDAP User Manager" which contains the Oracle Internet Directory location.
Click Apply.
Go to OC4J_FED - > Applications - > fed or fedmon - > Security.
Click Map Role To Principals.
Select user(s) or group(s) from the LDAP server that will have access to the console.
Click Apply.
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.
