Skip Headers
Oracle® Fusion Middleware Release Notes
11g Release 1 (11.1.1) for Linux x86

Part Number E10133-31
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

23 Oracle Identity Federation

This chapter describes issues associated with Oracle Identity Federation. It includes the following topics:

23.1 General Issues and Workarounds

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

23.1.1 Database Table for Authentication Engine must be in Base64 Format

When using a database table as the authentication engine, and the password is stored hashed as either MD5 or SHA, it must be in base64 format.

The hashed password can be either in the base64-encoded format or with a prefix of {SHA} or {MD5}. For example:

{SHA}qUqP5cyxm6YcTAhz05Hph5gvu9M= 

23.1.2 Considerations for Oracle Identity Federation HA in SSL mode

In a high availability environment with two (or more) Oracle Identity Federation servers mirroring one another and a load balancer at the front-end, there are two ways to set up SSL:

  • Configure SSL on the load balancer, so that the SSL connection is between the user and the load balancer. In that case, the keystore/certificate used by the load balancer has a CN referencing the address of the load balancer.

    The communication between the load balancer and the WLS/Oracle Identity Federation can be clear or SSL (and in the latter case, Oracle WebLogic Server can use any keystore/certificates, as long as these are trusted by the load balancer).

  • SSL is configured on the Oracle Identity Federation servers, so that the SSL connection is between the user and the Oracle Identity Federation server. In this case, the CN of the keystore/certificate from the Oracle WebLogic Server/Oracle Identity Federation installation needs to reference the address of the load balancer, as the user will connect using the hostname of the load balancer, and the Certificate CN needs to match the load balancer's address.

    In short, the keystore/certificate of the SSL endpoint connected to the user (load balancer or Oracle WebLogic Server/Oracle Identity Federation) needs to have its CN set to the hostname of the load balancer, since it is the address that the user will use to connect to Oracle Identity Federation.

23.1.3 Database Column Too Short error for IDPPROVIDEDNAMEIDVALUE

Problem

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]

Workaround

Alter table ORAFEDTMPPROVIDERFED to increase the column size for "idpProvidedNameIDValue" to 240.

23.2 Configuration Issues and Workarounds

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

23.2.1 WLST Environment Setup when SOA and OIF are in Same Domain

If your site contains Oracle SOA Suite and Oracle Identity Federation in the same domain, the WLST setup instructions in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation are insufficient for WLST to correctly execute Oracle Identity Federation commands.

This can happen if you install an IdM domain, then extend it with an Oracle SOA install; the SOA installer changes the ORACLE_HOME environment variable. This breaks the Oracle Identity Federation WLST environment, as it relies on the IdM value for ORACLE_HOME.

Take these steps to enable the use of WLST commands:

  1. Execute the instructions described in Section 9.1.1, Setting up the WLST Environment, in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.

  2. Copy OIF-ORACLE_HOME/fed/script/*.py to WL_HOME/common/wlst.

  3. Append the CLASSPATH environment variable with OIF-ORACLE_HOME/fed/scripts.

23.2.2 Oracle Virtual Directory Requires LSA Adapter

To use Oracle Virtual Directory as an Oracle Identity Federation user store or an authentication engine, you must configure a Local Storage Adapter, and the context root must be created as required at installation or post-install configuration time.

For details about this task, see the chapter Creating and Configuring Oracle Virtual Directory Adapters in the Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

23.2.3 Settings for Remote WS-Fed SP Must be Changed Dynamically

On the Edit Federations page, the Oracle Identity Federation (OIF) settings for remote WS-Fed service provider contain a property called SSO Token Type; you can choose to either inherit the value from the IdP Common Settings page or override it here. The number of properties shown in 'OIF Settings' depends on the value of SSO Token Type.

If you choose to override SSO Token Type with a different value (for example, by changing from SAML2.0 to SAML1.1), the number of properties shown in 'OIF Settings' does not change until you click the Apply button.

Also, if you have overridden the value for Default NameID Format to 'Persistent Identifier' or 'Transient/One-Time Identifier', then changed the SSO Token Type value from 'SAML2.0' to 'SAML1.1' or 'SAML1.0', you will notice that the value for Default NameID Format is now blank. To proceed, you must reset this property to a valid value from the list.

23.2.4 Required Property when Creating a WS-Fed Trusted Service Provider

When you create a WS-Fed Trusted Service Provider, you must set the value for the 'Use Microsoft Web Browser Federated Sign-On' property with these steps:

  1. In Fusion Middleware Control, navigate to Federations, then Edit Federations.

  2. Choose the newly create WS-Fed Trusted Service Provider and click Edit.

  3. In the 'Trusted Provider Settings' section, set the value for Use Microsoft Web Browser Federated Sign-On by checking or unchecking the check-box.

  4. Click Apply.

23.2.5 Federated Identities Table not Refreshed After Record Deletion

When the federation store is XML-based, a record continues to be displayed in the federated identities table after it is deleted.

The following scenario illustrates the issue:

  1. The federation data store is XML.

  2. Perform federated SSO, using "map user via federated identity".

  3. In Fusion Middleware Control, locate the Oracle Identity Federation instance, and navigate to Administration, then Identities, then Federated Identities.

  4. Click on the created federation record and delete it.

After deletion, the federated record is still in the table. Further attempts at deleting the record result in an error.

The workaround is to manually refresh the table by clicking Search.

23.2.6 Default Authentication Scheme is not Saved

Problem

This problem is seen when you configure Oracle Access Manager in Fusion Middleware Control as a Service Provider Integration Module. It is not possible to set a default authentication scheme since the default is set to a certain scheme (say OIF-password-protected) but the radio button is disabled.

Solution

Take these steps to set the preferred default authentication scheme:

  1. Check the Create check-box for the scheme that is currently set as the default but disabled.

  2. Check the Create check-box(es) for the authentication scheme(s) that you would like to create.

  3. Click the radio button of the scheme that you wish to set as the default.

  4. Uncheck the Create check-box of the scheme in Step 1 only if you do not want to create the scheme.

  5. Provide all the required properties in the page.

  6. Click the Configure Oracle Access Manager button to apply the changes.

The default authentication scheme is now set to the one that you selected.

Note:

In addition, when trying to remove any authentication scheme, ensure that you do not remove the default scheme; if you must remove the scheme, change the default to another authentication scheme before you remove the scheme.

23.2.7 Configuring 10g to Work with 11g Oracle Identity Federation using Artifact Profile

In the SAML 1.x protocol, for a 10g Oracle Identity Federation server to work with an 11g Oracle Identity Federation server using the Artifact profile, you need to set up either basic authentication or client cert authentication between the two servers.

For instructions, see:

23.3 Documentation Errata

This section describes documentation errata for the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation, part number E13400-01. It includes the following topics:

Note:

For documentation errata and other release notes relating to the integration of Oracle Identity Federation with Oracle Access Manager 11g , see the chapter for "Oracle Access Manager."

23.3.1 Different Passwords for Keystore and Private Key not Supported

Oracle Identity Federation only supports configuring one password for signing and encryption keystores, and uses that password to open both the keystore and the private key. This means that if a keystore is configured with different store password and key password, an error will occur when Oracle Identity Federation tries to access the private key.

To avoid this error, ensure that the private key password for the configured key alias is the same as the keystore password.

Note:

In Oracle Identity Federation 11g Release 1 (11.1.1), if you change the key password to match the keystore password, you must remove the old keystore/wallet from the configuration.

23.3.2 Documentation Erratum for Deploying Oracle Identity Federation

In Section 3.2.2.2, "Integrate Oracle Single Sign-On with OHS", replace the following set of instructions:

Copy $AS_INST/config/OHS/$OHS_NAME/disabled/mod_osso.conf to $AS_INST/config/OHS/$OHS_NAME/moduleconf. All files in the moduleconf directory are read when OHS is started.

Open the $AS_INST/config/OHS/$OHS_NAME/moduleconf/mod_osso.conf file and set the OssoConfigFile directive to reference the Oracle Single Sign-On configuration file that was created and then copied to the OHS config directory:

OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/oif.server.com.osso.conf

with the following text:

Copy $AS_INST/config/OHS/$OHS_NAME/disabled/mod_osso.conf to $AS_INST/config/OHS/$OHS_NAME/moduleconf. All files in the moduleconf directory are read when OHS is started.

Open the $AS_INST/config/OHS/$OHS_NAME/moduleconf/mod_osso.conf file. Set the OssoConfigFile directive to reference the Oracle Single Sign-On configuration file that was created and then copied to the OHS config directory:

OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/ ${COMPONENT_NAME}/oif.server.com.osso.conf

Add the /fed/user/authnosso URL to be protected by Oracle SSO Server, through the Location element.

Then the mod_osso.conf example would look like this:

LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so
 
<IfModule mod_osso.c>
    OssoIpCheck off
    OssoIdleTimeout off
    OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/
    ${COMPONENT_NAME}/oif.server.com.osso.conf
 
    <Location /fed/user/authnosso>
       require valid-user
       AuthType Osso
    </Location>
</IfModule> 

23.3.3 Documentation Erratum for Configuring Security and Trust

In Section 5.10.3, "Security and Trust - Trusted CAs and CRLs", change the following sentence:

"When the certificate validation store is enabled, Oracle Identity Federation uses it to validate the certificates needed to verify the signatures on incoming messages."

to read:

"When the certificate validation store is enabled, Oracle Identity Federation uses it to validate the certificates needed to verify the signatures on incoming SAML/WS-Federation messages."

23.3.4 Additional Steps for SSL Configuration

In Section 8.2.2, "Configuring Oracle Identity Federation as an SSL Client," add the following subsection, which shows the steps needed to ensure that Fusion Middleware Control can continue to manage the Oracle Identity Federation server after SSL is enabled for the Admin server and the managed server hosting Oracle Identity Federation:

Ensuring that Fusion Middleware Control can Manage an Oracle Identity Federation Target

Take these steps:

  1. Locate $INSTANCE_HOME/EMAGENT/EMAGENT/sysman/emd/targets.xml.

    Change the protocol for the 'serviceURL' property to the correct protocol. If you have more than one Oracle Identity Federation target (besides host and oracle_emd), you need to modify the 'serviceURL' for each target.

  2. Locate $INSTANCE_HOME/EMAGENT/EMAGENT/sysman/config/emd.properties.

    If necessary, update the protocol for 'REPOSITORY_URL' to the correct protocol. The EM Agent uses this property to connect to Fusion Middleware Control.

  3. Stop the EM Agent using the command:

    $INSTANCE_HOME/bin/opmnctl stopproc ias-component=EMAGNET
    
  4. Secure the EM Agent using the command:

    $INSTANCE_HOME/EMAGENT/EMAGENT/bin/emctl secure fmagent -admin_host
    <host> -admin_port <port> -admin_user <username> [-admin_pwd <pwd>]
    
  5. Restart the EM Agent using the command:

    $INSTANCE_HOME/bin/opmnctl startproc ias-component=EMAGNET
    

23.3.5 ParseException Message in Diagnostic Log

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.

23.3.6 Forcing Re-authentication when Integrated with Oracle Access Manager

Add the following note in Section 3.2.3, "Deploying Oracle Identity Federation with Oracle Access Manager":

Note:

Oracle Identity Federation does not support the ability to force re-challenging the user for credentials when integrated with the Oracle Access Manager 10g authentication engine, so 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 Oracle Access Manager, the ForceAuthn flag is ignored.

23.3.7 Supported Version of Oracle Access Manager 10g

For integration with Oracle Access Manager 10g server, Oracle Identity Federation supports Oracle Access Manager Version 10.1.4.3.

In Section 3.2.3.2 Integrate Oracle Access Manager as an Authentication Engine, under the Verify Requirements heading, change the first step to verify component versions to read:

  1. Verify that the Oracle Access Manager server is at Version 10.1.4.3.

23.3.8 Additional Steps for OpenID Configuration

Section 5.4.4 Configure OpenID IdP Properties describes how to enable the out-of-the-box Oracle Identity Federation OpenID provider.

You can also configure an external OpenID provider so that Oracle Identity Federation acts as the relying party (RP/SP) and an external resource acts as the OpenID provider (OP). Google and Yahoo are examples of external OpenID providers.

The following steps describe how to configure an external OpenID provider:

  1. Log in to Oracle Enterprise Manager Fusion Middleware Control.

  2. Navigate to the Oracle Identity Federation instance.

  3. Select Administration, then Federations.

  4. Click Add to add a new OpenID provider.

  5. In the pop-up box, select "Add provider manually".

  6. Enter the provider ID using a URL in this format:

    http://node123.us.example.com:7777/fed/idp
    
  7. For protocol version, select "OpenID2.0".

  8. For provider type, select "Identity Provider".

  9. Click OK to create the provider.

  10. Edit the new provider. Enter the provider's discovery URL in this format:

    http://node123.us.example.com:7777/fed/idp
    

    or enter the provider's OpenID endpoint URL if the IdP does not support OpenID discovery.

  11. Click Apply to commit the edits.

23.3.9 Documentation Erratum for Oracle Identity Federation MBeans

In Section A.5.2 "Access Oracle Identity Federation MBeans", the MBean names are stated in Table A-1 and the sample code as "Oracle Identity FederationConfigMBean" which should be corrected to read "OIFConfigMBean"..