7 Oracle Identity Federation

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

• Section 7.1, "General Issues and Workarounds"

• Section 7.2, "Configuration Issues and Workarounds"

• Section 7.3, "Documentation Errata"

7.1 General Issues and Workarounds

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

• Section 7.1.1, "Credential Re-entry When Accessing a SiteMinder Protected Resource"

• Section 7.1.2, "Reauthentication after Session Timeout with OracleAS Single Sign-On and SAML 1.x or WS-Federation"

• Section 7.1.3, "Attribute Sharing with the Microsoft Internet Information Server"

• Section 7.1.4, "Redirection Loops with Oracle Access Manager"

• Section 7.1.5, "Truncated Text in Japanese Version of Oracle Universal Installer"

• Section 7.1.6, "Unused Assertion Profile With Invalid Attribute Mapping Can Cause SSO Failure"

• Section 7.1.7, "Signed SAML 1.0 Assertions Can Cause SSO Failures"

• Section 7.1.8, "Encrypting Network Connections"

7.1.1 Credential Re-entry When Accessing a SiteMinder Protected Resource

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

7.1.3 Attribute Sharing with the Microsoft Internet Information Server

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

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.

7.1.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.1.5 Truncated Text in Japanese Version of Oracle Universal Installer

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

1. Start Oracle Universal Installer.

2. Choose the "Oracle Identity Federation 10g" installation option.

3. Proceed to the "Select Installation Method" page.

The text describing the first radio button ("Basic"), is truncated.

7.1.6 Unused Assertion Profile With Invalid Attribute Mapping Can Cause SSO Failure

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:

RDBMSBridge.authenticate(): ERROR - SQL Exception thrown by JDBC: java.sql.SQLException: ORA-00904: "<attribute name>": invalid identifier

With the LDAP data store, the user will receive an Identity Federation error with ID TSE007, and the federation.log file will show an error:

RESPONDER: ERROR User directory entry for <userDN> does not have the <assertion attribute> attribute <user attribute>. (RSE027)

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

7.1.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:

RECEIVER: ERROR: An invalid SAML Response was received: XML SIGNER: ERROR: Invalid signature or altered contents

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.1.8 Encrypting Network Connections

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.

7.2 Configuration Issues and Workarounds

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

• Section 7.2.1, "Administration Console Is Not Accessible After Changing Transient Data Store"

• Section 7.2.2, "Signing SAML Response with Assertion"

• Section 7.2.3, "Assertions Using SAML 1.x POST Method Fail in Japanese Locale"

• Section 7.2.4, "Using RDBMS as a User Data Store with a Login column ID of type CHAR"

7.2.1 Administration Console Is Not Accessible After Changing Transient Data Store

You may be unable to access the Oracle Identity Federation administration console in this situation:

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

2. 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:

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

2. Navigate to OC4J_FED - > Administration - > Security.

3. In the Users list, click the jazn.com/oif_db entry.

4. Enter the correct password to access the RDBMS.

5. Apply, and restart the OC4J_FED instance.

7.2.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.2.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.2.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:

1. Log in to the Enterprise Manager console of your Oracle Identity Federation instance and navigate to OC4J_FED - > Administration - > Data Sources.

2. Create a new data source using the following example as a guide:

   Name:                 myDS
   Data Source Class:    oracle.jdbc.pool.OracleDataSource
   JDBC URL:             jdbc:oracle:thin:@stahs08.us.oracle.com:1521:ORCL
   JDBC Driver:          oracle.jdbc.driver.OracleDriver
   Username:            CUSTDATA
   Password:            PASSWORD
   Location:            jdbc/RDBMSUserDataSource
   
   

3. Apply the changes.

4. Restart the OC4J_FED instance.

Note: Do not enter any information in the Transactional(XA) Location and EJB Location fields.

7.3 Documentation Errata

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

• Section 7.3.1, "Incorrect Header in Oracle Identity Federation Online Help"

• Section 7.3.2, "Usage of Command-line Configuration Assistants"

7.3.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.3.2 Usage of Command-line Configuration Assistants

This note relates to the following sections of the Oracle Identity Federation Administrator's Guide:

8.2.2 Command-Line Configuration Assistant to Change the Transient Data Store

8.2.3 Command-Line Configuration Assistant for Uninstallation

The document states that these configuration assistants take passwords on the command line as parameters. This practice is not secure and should be avoided.

Both these tools will prompt the user for LDAP and/or RDBMS passwords when they are not entered on the command line. For example, you can execute the uninstall tool with these parameters:

jdk/bin/java -jar fed/lib/uninstall.jar -uninstall -oh $ORACLE_HOME -removefed true -ldap false -ldaptype oid -ldapurl ldap://my.ldap.com -ldapusername USERNAME -db false

The tool will then display the following, prompting you for an LDAP password:

Parsing parameters
Verifying parameters
Enter password for LDAP Username "USERNAME":

Note that the following parameter for the Command-Line Configuration Assistant to Change the Transient Data Store (Section 8.2.2.1 of the document) is not required:

-dbpwd <PASSWORD> - This is the RDBMS password. Required if an RDBMS is used for the transient data store.

The following parameters for the Command-Line Configuration Assistant for Uninstallation (Section 8.2.3.1 of the document) are not required:

-ldappwd - This is the password of the LDAP user.

-dbpwd password - The RDBMS password. Required if db is true

Both tools allow users to specify the passwords on the command line, but this practice is strongly discouraged. If you pass the passwords as parameters on the command line, a warning message will be displayed:

Caution: It is insecure practice to enter passwords on the command line. Please consult the latest product documentation for secure usage of this utility.

Future releases of Oracle Identity Federation will remove support for allowing passwords on the command line, and will only prompt for passwords.