Skip Headers
Oracle® Identity Federation Administrator's Guide
10g (10.1.4.0.1)

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

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

6 Configuring Oracle Identity Federation

This chapter explains how to use the Oracle Identity Federation administration console to configure and maintain server properties and federation data. It contains these sections:

6.1 Data Maintained by Oracle Identity Federation

The Oracle Identity Federation administrator acquires the data needed to manage and operate the server from a variety of sources, including third parties (other providers' administrators), agreements with the third parties, and from local configuration decisions. The administrator is responsible for loading and maintaining this information in the federation server.

Broadly speaking, the federation server maintains two categories of configuration details:

6.1.1 Server Configuration Data

Each Oracle Identity Federation instance maintains two types of configuration data:

  • Protocol data, including:

    • properties of the server instance as a whole, including the hostname and port, whether SSL is enabled, the PKCS #12 wallet location, and so on

    • how the server instance supports its enabled federation protocols when acting as an identity provider, including session time-outs, re-authentication time-outs, the default provider ID, and so on

    • how the server instance supports its enabled federation protocols when acting as a service provider. The data maintained in this case is very similar to the data stored when the server acts as an identity provider

  • Circle of Trust data, consisting of information about peer providers that are members of the Circle of Trust to which this server instance belongs. Circle of Trust configuration data includes such parameters as:

    • name ID formats to use for assertions

    • attributes to send along with an authentication request

    • signing requirements for assertions and authentication requests

    • preferred bindings

    • validity periods of assertions and artifacts

    • other time-related parameters such as the allowable time difference between servers that are not synchronized.

    • account linking parameters

Configuration Settings and Provider Metadata

Note that relationships may exist between configuration settings and the provider metadata that the server generates. Some settings do not affect the metadata while others do. For example, changing the Session Timeout value does not affect the metadata, but changing the SOAP Port will require the administrator to re-publish his metadata to the other providers in his circle of trust. Likewise, the administrator must be aware of changes to peer providers' metadata.

Here is a list of properties that affect metadata:

  • Server Properties

    • Server Hostname

    • Server Port

    • SOAP Port

    • IdP Enabled

    • SP Enabled

    • SSL Enabled

    • Signing PKCS #12 Wallet

    • Encryption PKCS #12 Wallet

  • Global IdP Properties

    • ProviderID

    • Liberty 1.1 Enabled

    • Liberty 1.2 Enabled

    • SAML 2.0 Enabled

  • Global SP Properties

    • ProviderID

    • Liberty 1.1 Enabled

    • Liberty 1.2 Enabled

    • SAML 2.0 Enabled

  • Liberty 1.1 IdP Properties

    • Enable Profiles/Bindings

    • Federation Termination Enabled

    • Register NameID Enabled

  • Liberty 1.2 IdP Properties

    • Enable Protocol Profiles

    • Federation Termination Enabled

    • Register NameID Enabled

  • SAML 2.0 IdP Properties

    • Enable Protocol Profiles

    • Federation Termination Enabled

    • Register NameID Enabled

    • Attribute Responder Enabled

  • Liberty 1.1 SP Properties

    • Enable Profiles/Bindings

    • Federation Termination Enabled

    • Register NameID Enabled

  • Liberty 1.2 SP Properties

    • Enable Protocol Profiles

    • Federation Termination Enabled

    • Register NameID Enabled

  • SAML 2.0 SP Properties

    • Enable Protocol Profiles

    • Federation Termination Enabled

    • Register NameID Enabled

The metadata URLs for the various protocols are as follows:

  • IdP SAML 2.0 - http(s)://hostname:port/fed/idp/metadatav20

  • IdP Liberty 1.2 - http(s)://hostname:port/fed/idp/metadatav12

  • IdP Liberty 1.1 - http(s)://hostname:port/fed/idp/metadatav11

  • SP SAML 2.0 - http(s)://hostname:port/fed/sp/metadatav20

  • SP Liberty 1.2 - http(s)://hostname:port/fed/sp/metadatav12

  • SP Liberty 1.1 - http(s)://hostname:port/fed/sp/metadatav11

See Also:

For information about SAML 1.x and WS-Federation service URLs, see "Exchanging SAML 1.x and WS-Federation Configuration Data with Peers"

6.1.2 User Federation Data

An LDAP directory stores each user's identity federation data. In addition to the user's basic reference information, there are records for each unique identity federation associated with the user. A federation record is defined by:

  • the remote provider

  • the name identifier type (for example, an e-mail address or a DN)

  • the protocol (for example, SAML 2.0)

This means that a user can have multiple identity federation records for the same remote provider, so long as the combination of these three attributes provides uniqueness. For example, the user's first record could be identified by a combination of ProviderX/myemail1/SAML 2.0, and the second record by ProviderX/myemail2/SAML 2.0.

Synchronization

As mentioned earlier, the federation records for a user are stored independently, and rely on a unique user attribute (such as a DN or a username) to link to the main user record.

An event that changes a user's unique attribute value - for example, if an employee moves to a new office location and her DN is updated - requires that the user's federations be dropped and re-established.

Deprovisioning

Likewise, if a user record is deleted, the federation data remains. This means that the administrator must be sure to delete the user's federation data when the user is deprovisioned.

Caution:

Failure to delete the federation data in this situation can introduce a potential security problem. For example, consider a scenario where a new user is subsequently provisioned with the same unique attribute value - for example, the same DN or username; that user would inherit the previous user's account linkages if they had been left around.

The federation data can be deleted:

6.2 Administration Console Overview

The administration console of Oracle Identity Federation is a web-based graphical interface that enables the administrator to administer, configure, and maintain both server properties and user federation data.

6.3 Basic Server Configuration

This section explains how to edit and update Oracle Identity Federation properties. It contains these sections:

6.3.1 Server Configuration Tab

Use the Server Configuration tab of the Administration Console to choose a category of Oracle Identity Federation properties to configure.

This screen is fully described in the text.

Select one of these configuration actions:

  • Edit general server properties

  • Edit global properties for a server acting as Identity Provider (IdP)

  • Edit global properties for a server acting as Service Provider (SP)

  • Edit protocol-specific properties and attribute responder mappings for a Liberty 1.1, Liberty 1.2, or SAML 2.0 compliant Service Provider (SP)

  • Edit protocol-specific properties for a Liberty 1.1, Liberty 1.2, or SAML 2.0 compliant Identity Provider (IdP)

  • Edit Circle of Trust (COT) provider information

6.3.2 Editing Server Properties

Use this page to edit Oracle Identity Federation properties.

Note:

Any changes to these settings will require a server restart.
This screen is fully explained in the text.

You can configure the following parameters:

Server Hostname

This is the host name of the Oracle Identity Federation instance.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Server Port

This is the port where Oracle Identity Federation listens.

Note:

  • This setting only dictates what server port will be specified in the IdP and SP metadata when the metadata is generated. If there are several HTTP or HTTPS ports enabled for the OC4J instance in which Oracle Identity Federation is running, a user or peer provider can access Oracle Identity Federation through any of those ports, not just the port you specify here.

  • This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

SOAP Port

This is the port where Oracle Identity Federation listens for SOAP messages.

Note:

  • This setting only dictates what SOAP port will be specified in the IdP and SP metadata when the metadata is generated. If there are several HTTP or HTTPS ports enabled for the OC4J instance in which Oracle Identity Federation is running, a user or peer provider can access Oracle Identity Federation through any of those ports, not just the port you specify here.

  • This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Session Timeout

This parameter is used to determine the period, in seconds, for which an authenticated session is active. If the session remains inactive beyond the active period, the user must re-authenticate. The default value is 7200 seconds.

How this parameter is used depends on the server's role and the nature of the session in question.

Scenario 1: User Authenticated Locally

The user can be authenticated locally when:

  • Oracle Identity Federation acts as an IdP

  • Oracle Identity Federation is an SP, and the user needs to be prompted for its credentials because a new federation is being created

In this case, the expiration time of the authenticated session is set to the value of the Session Timeout parameter.

Scenario 2: Existing Federation

When Oracle Identity Federation is acting as an SP with an existing federation, the server receives a SAML assertion from the IdP containing user and authentication information. The assertion may include a ReauthenticateOnOrAfter attribute, indicating to Oracle Identity Federation that the user should be re-authenticated after the period specified by the attribute.

In this case, the Oracle Identity Federation server acting as SP sets the expiration time of the authenticated session to: the Session Timeout parameter or the ReauthenticateOnOrAfter assertion attribute, whichever is less.

Note:

When Oracle Identity Federation uses Oracle Access Manager as its user data store, the Session Timeout has no effect on the user session. With Oracle Access Manager, the session timeout is determined by the configuration of the AccessGates protecting accessed resources.

Session Data Cleanup Interval

If Oracle Identity Federation is configured to use a relational database repository, this is the frequency with which the server cleans expired sessions from the database.

Note:

If this is a negative number, the server will never perform the cleanup.

Identity Provider Enabled

Checking this box enables the server instance as an Identity Provider (IdP).

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Service Provider Enabled

Checking this box enables the server instance as a Service Provider (SP).

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

SSL Enabled

Checking this box enables Secure Sockets Layer (SSL) encryption, allowing the server to listen in HTTPS mode.

Note:

  • This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

  • This property only tells Oracle Identity Federation that the port on which the server is listening is SSL enabled; setting this property does not configure the SSL framework. Refer to these documents for details of how to enable SSL:

    "Enabling SSL" in the Oracle Application Server Quick Administration Guide

    "Configuring SSL" in the Oracle HTTP Server Administrator's Guide

Force SSL

Checking this box forces communications with the server to be conducted in HTTPS mode. If true, Oracle Identity Federation checks an incoming connection to ensure that it is done over SSL. If it is not, the server redirects the user to a URL supporting SSL; the URL is built with the hostname and port properties and the requested URL.

Logging Debug Enabled

Checking this box enables debug mode for Oracle Identity Federation and logs all operations.

If you do not check this box, debug mode is disabled, and only errors and incoming/outgoing Liberty and SAML messages are logged.

Certificate Validation Enabled

Check this box to enable validation of signing certificates using Certificate Revocation Lists (CRLs).

Fields for Signing Wallet

Use the following fields to assign a PKCS #12 signing certificate for the server instance:

  • Signing PKCS #12 Wallet - This is the signing wallet in PKCS #12 format.

    Note:

    This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.
  • Update wallet from file - You can choose an operating system file containing the wallet.

  • Signing PKCS #12 Password - Enter the password that was used to encrypt the private key.

Fields for Encryption Wallet

Use the following fields to assign a PKCS #12 encryption certificate for the server:

  • Encryption PKCS #12 Wallet - This is the encryption wallet in PKCS #12 format.

    Note:

    This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.
  • Update wallet from file - You can choose an operating system file containing the wallet.

  • Encryption PKCS #12 Password - Enter the password that was used to encrypt the private key.

  • Default Encryption Algorithm - Select one of the available encryption algorithms:

    • AES-128 CBC

    • AES-192 CBC

    • AES-256 CBC

    • Triple DES CBC

The buttons at the bottom of the page perform the following functions:

  • Update - saves changes made to server configuration properties.

  • Cancel - restores the screen to its original values without saving any changes.

6.3.3 Editing Global Properties

This section explains how to accomplish the following tasks:

6.3.3.1 Identity Provider - Global Settings

Use this page to specify global Identity Provider (IdP) properties for the SAML 2.0 and Liberty 1.x protocols for the server instance.

This screen is fully explained in the text.

You can configure the following parameters:

Provider ID (URI)

This is the URI for the Oracle Identity Federation instance. If it is a URL, it need not point to an actual resource.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Liberty 1.1 Enabled

Check this box to indicate that the server is enabled for Liberty 1.1.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Liberty 1.2 Enabled

Check this box to indicate that the server is enabled for Liberty 1.2.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

SAML 2.0 Enabled

Check this box to indicate that the server is enabled for SAML 2.0.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Force User Consent

Check this box to force consent for setting up a new federation. If this box is checked, a user who is redirected to the federation server will explicitly have to accept or deny account linking in order to proceed.

User Consent URL

The user is redirected to this URL if user consent is required. You must design a consent page for this purpose.

The server passes a number of query parameters to this URL:

Table 6-1 Parameters Passed to User Consent URL (IdP Global)

Parameter Description

providerid

The peer provider id.

description

The description of the peer provider id.

returnurl

The URL to which the user should be directed once a consent decision has been made.

refid

Passed as a query parameter to the returnurl. Oracle Identity Federation require this parameter in order to resume the operation the server had been performing prior to redirection to the consent URL.


When the consent URL page directs the user back to the return URL (by way of a link, form submission, or other means) it must pass two query parameters: the refid parameter described in the table, and a consent parameter indicating if consent was granted by the user (values are true or false).

Here is an example of a consent page:

<%
    String prefix = request.getContextPath();
    String redirectURL = request.getParameter("returnurl");
    String refID = request.getParameter("refid");
    String providerID = request.getParameter("providerid");
    String desc = request.getParameter("description");
%>
<HTML>
<BODY>
Do you consent to create a federation with <%=providerID%> (<%=desc%>):<br>
<form method="POST" action="<%=redirectURL%>">
    <input type="checkbox" name="userconsent" value="true"/>I agree<br>
    <input type="submit" value="OK" />
    <input type="hidden" name="refid"  value="<%=refID%>"/>
</form>
</BODY>
</HTML>

Artifact Timeout

This is the validity time, in seconds, of an artifact object created by the Oracle Identity Federation. The default is 300 seconds.

Request Timeout

This is the validity time, in seconds, of an outgoing request from the Oracle Identity Federation. The default is 120 seconds.

Assertion Validity

This is the time, in seconds, during which an assertion issued by the identity provider is valid. An assertion is considered invalid if processed outside the validity period. The default is 300 seconds.

Reauthenticate After

This is the time, in seconds, after which the service provider must re-authenticate the user. Assertions containing an authentication statement by the identity provider are only valid for this period, after which the user is to be considered non-authenticated. The default is 3600 seconds.

Note:

This feature is applicable to OracleAS Single Sign-On authentication. For a limitation on forced reauthentication, see "Deploying Oracle Identity Federation with OracleAS Single Sign-On".

Server Clock Drift

This is the allowable time difference, in seconds, between Oracle Identity Federation, when acting as identity provider, and its peer servers. The default is 600 seconds.

Descriptor Validity

This is the time, in days, during which the server's published IdP metadata is considered valid. Peer servers can reload the metadata within this period. Enter the descriptor validity in days. The default value is 30 days.

Default Binding

Specifies the preferred binding to use, when possible, in sending messages to peer providers. Valid values are:

  • HTTP Redirect

  • HTTP POST

  • SOAP

Default SSO Response Binding

Specifies the preferred binding for the identity provider to use, when possible, in sending an unsolicited assertion to the service provider. Valid values are:

  • Artifact

  • HTTP POST

Common Domain Enabled

When an identity federation network contains multiple identity providers, a service provider needs to have a way to determine the identity provider(s) in use by a principal. This is achieved by utilizing a domain that is common to IdPs and SPs in the federation network, and sending to the user's browser a cookie, written in this domain, that lists all the IdPs where the user is logged in. Such a domain is known as a common domain, and the cookie identifying the IdPs is called a common domain cookie or introduction cookie.

Check Common Domain Enabled to specify that this IdP should set the introduction cookie. After every local authentication, Oracle Identity Federation redirects the user to the common domain, where the server can add its identifier to the introduction cookies at the user's browser.

Common Domain URL

When an identity federation network contains multiple identity providers, a domain common to all providers is a way for a service provider to determine the identity provider(s) in use by a principal. After every authentication, a cookie on the user's browser (written in this domain) is updated with the IdPs identifier; the cookie lists all the user's IdPs and can be read by the service provider.

Enter the URL where Oracle Identity Federation will read and set the IdP introduction cookie. The server listens on this URL, accepts requests, and updates the introduction cookie in the user's browser.

Set this value only if you checked Common Domain Enabled.

Common Domain Name

This is the common domain used for the IdP introduction cookie. It will be set as a cookie parameter on the introduction cookie. The value must begin with a dot (.) and must be of the form .domain.suffix. The default value is .DOMAIN_TO_BE_SET.

Cookie Lifetime

This is the lifetime, in days, of a Common Domain cookie issued by the IdP. If this field is set to 0 (default), the Common Domain Cookie will be a session cookie.

Messages to Send Signed

Click Select to display a list of federation protocol message types and specify the messages that Oracle Identity Federation sends, in IdP mode, that it must sign.

Messages to Require Signed

Click Select to display a page which lists the federation protocol message types and specify the messages that Oracle Identity Federation receives, in IdP mode, that it requires to be signed.

The buttons at the bottom of the page perform the following functions:

  • Update - saves changes made to Global IdP configuration properties.

  • Cancel - Restores the screen to its original values without saving any changes.

6.3.3.2 Identity Provider - Select Messages to Send Signed

This page displays a list of federation protocol message types for messages sent by Oracle Identity Federation in Identity Provider mode. Use this page to specify which messages the server should sign. The messages are displayed along with their transport bindings.

This screen is fully explained in the text.

Available Messages

Messages in this list will be sent unsigned.

Selected Messages

Messages in this list will be sent signed.

Actions

Buttons on the page provide these actions:

  • Move - Moves the selected message types to the Selected Messages list. Use the control key to select multiple message types.

  • Move All - Moves all messages currently in the Available Messages list to the Selected Messages list.

  • Remove - Moves the selected message types from the Selected Messages list to the Available Messages list. Use the control key to select multiple message types.

  • Remove All - Moves all messages currently in the Selected Messages list to the Available Messages list.

You can also double-click on a message type to move it from one list to the other.

The buttons at the bottom of the page perform the following functions:

  • Update - saves changes made to the page for signed/unsigned messages.

  • Cancel - Returns to the Identity Provider - Global Settings page without saving any changes.

6.3.3.3 Identity Provider - Select Messages to Require Signed

This page displays a list of federation protocol message types for messages received by Oracle Identity Federation in Identity Provider mode. Use this page to specify which types of messages the server requires to be signed. The messages are displayed along with their transport bindings.

This screen is fully explained in the text.

Available Messages

Messages in this list are not required to be signed.

Selected Messages

Messages in this list are required to be signed.

Actions

Buttons on the page provide these actions:

  • Move - Moves the selected message types to the Selected Messages list. Use the control key to select multiple message types.

  • Move All - Moves all messages currently in the Available Messages list to the Selected Messages list.

  • Remove - Moves the selected message types from the Selected Messages list to the Available Messages list. Use the control key to select multiple message types.

  • Remove All - Moves all messages currently in the Selected Messages list to the Available Messages list.

You can also double-click on a message type to move it from one list to the other.

The buttons at the bottom of the page perform the following functions:

  • Update - saves changes made to the page for signed/unsigned messages.

  • Cancel - Returns to the Identity Provider - Global Settings page without saving any changes.

6.3.3.4 Service Provider - Global Settings

Use this page to specify global Service Provider (SP) properties for the SAML 2.0 and Liberty 1.x protocols for the server instance.

This screen is fully explained in the text.

You can configure the following parameters:

Provider ID (URI)

This is the URI for the Oracle Identity Federation instance. If it is a URL, it need not point to an actual resource.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Liberty 1.1 Enabled

Check this box to indicate that the server is enabled for Liberty 1.1.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Liberty 1.2 Enabled

Check this box to indicate that the server is enabled for Liberty 1.2.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

SAML 2.0 Enabled

Check this box to indicate that the server is enabled for SAML 2.0.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Force User Consent

Check this box to force consent for setting up a new federation. If this box is checked, a user who is redirected to the federation server will explicitly have to accept or deny account linking in order to proceed.

User Consent URL

If the user must consent to setting up a new federation, this is the URL to which the user is redirected. You must design a consent page for this purpose.

The server passes a number of query parameters to this URL:

Table 6-2 Parameters Passed to User Consent URL (SP Global)

Parameter Description

providerid

The peer provider id.

description

The description of the peer provider id.

returnurl

The URL to which the user should be directed once a consent decision has been made.

refid

Passed as a query parameter to the returnurl. Oracle Identity Federation require this parameter in order to resume the operation the server had been performing prior to redirection to the consent URL.


When the consent URL page directs the user back to the return url (by way of a link, form submission, or other means) it must pass two query parameters: the refid parameter described in the table, and a consent parameter indicating if consent was granted by the user (values are true or false).

Use this field only if Force User Consent is checked.

Here is an example of a consent page:

<%
    String prefix = request.getContextPath();
    String redirectURL = request.getParameter("returnurl");
    String refID = request.getParameter("refid");
    String providerID = request.getParameter("providerid");
    String desc = request.getParameter("description");
%>
<HTML>
<BODY>
Do you consent to create a federation with <%=providerID%> (<%=desc%>):<br>
<form method="POST" action="<%=redirectURL%>">
    <input type="checkbox" name="userconsent" value="true"/>I agree<br>
    <input type="submit" value="OK" />
    <input type="hidden" name="refid"  value="<%=refID%>"/>
</form>
</BODY>
</HTML>

Ignore Unknown Conditions

A condition is an extension point in the XML schema. Custom conditions can be defined according to specific needs - for example, to denote that assertion X is conditional in a given time zone. Such conditions may not be amenable to evaluation, and checking this box allows the server to ignore a condition it does not recognize in a received message.

Request Timeout

This is the validity time, in seconds, of an outgoing request from Oracle Identity Federation.

Server Clock Drift

This is the allowable time difference, in seconds, between Oracle Identity Federation, when acting as identity provider, and its peer servers.

Descriptor Validity

This is the time, in days, during which the server's published SP metadata is considered valid. Peer servers can reload the metadata within this period. Enter the descriptor validity in days. The default value is 30 days.

Allow Federation Creation

Use this field if your server instance, when operating as a service provider, should allow federation when initiating single sign-on with its peer identity providers in the federated network. Check this box to allow federation to be set up between the providers.

Default Binding

Specifies the preferred binding to use, when possible, in sending messages to peer providers. Valid values are:

  • HTTP Redirect

  • HTTP POST

  • SOAP

Default SSO Request Binding

Specifies the preferred binding for the service provider to use, when possible, in sending authentication requests to the identity provider. Valid values are:

  • HTTP Redirect

  • HTTP POST

Default SSO Response Binding

Specifies the preferred binding for the identity provider to use, when possible, in sending an unsolicited assertion to the service provider. Valid values are:

  • Artifact

  • HTTP POST

Default SSO Identity Provider

Enter the default IdP to use in performing the single sign-on operation. Choose from the list of configured identity providers, or blank for none.

Note:

Oracle Identity Federation provides a second mechanism to allow a service provider to select the IdP that will receive an authentication request to initiate single sign-on: the URL that is requested from the partner application to initiate single sign-on can include a query parameter, providerid, that specifies the desired IdP. This mechanism is useful when there are multiple IdP's in the circle of trust.

Anonymous User Identifier

This field allows the SP to provide services without knowing the identity of the consumer. It is used to identify a user when using Liberty 1.2 onetime/anonymous identifier or SAML 2.0 transient name ID in a Single Sign-On operation. Oracle Identity Federation receives an assertion containing an anonymous identifier; in order to create an authenticated session for that user in the IdM framework, an account needs to be associated with that session. The Anonymous User Identifier references the account to be used for such operations.

These steps are necessary to complete the configuration of the anonymous user identifier:

  1. On the Circle Of Trust tab, select an IdP and click Update to go to Edit Trusted Provider. Uncheck Default Authn Request NameID Format [2], and from the drop-down box, select Transient/One-Time Identifier.

  2. Uncheck NameID Formats and click Select. On Edit Trusted Provider: Select NameID Formats:

    • Check Enable for Transient/One time Identifier.

    • For Default Assertion NameID Format [1], select Transient/One-Time Identifier.

  3. Return to Service Provider - Global Settings, and in the Anonymous User Identifier field, enter the username to use for anonymous login. This is the account that the anonymous user will use to "log in" to the system.

Common Domain Enabled

When an identity federation network contains multiple identity providers, a domain common to all providers is a way for a service provider to determine the identity provider(s) in use by a principal.

Check this box to indicate that common domain is enabled for the federation network.

Common Domain URL

Enter the URL to which Oracle Identity Federation will redirect the user to read the IdP introduction cookie and initiate a single sign-on session with the last recognized IdP where the user logged in. The server listens on this URL, accepts requests, and reads the introduction cookies sent by the user's browser.

Messages to Send Signed

Click Select to display a list of federation protocol message types and specify the messages that Oracle Identity Federation sends that it must sign.

Messages to Require Signed

Click Select to display a page which lists the federation protocol message types and specify the messages that Oracle Identity Federation receives that it requires to be signed.

The buttons at the bottom of the page perform the following functions:

  • Save - saves changes made to Service Provider configuration properties.

  • Reset - restores the screen to its original values without saving any changes.

6.3.3.5 Service Provider - Select Messages to Send Signed

This page displays a list of federation protocol message types for messages sent by Oracle Identity Federation in Service Provider mode. Use this page to specify which messages the server should sign. The messages are displayed along with their transport bindings.

This screen is fully explained in the text.

Available Messages

Messages in this list will be sent unsigned.

Selected Messages

Messages in this list will be sent signed.

Actions

Buttons on the page provide these actions:

  • Move - Moves the selected message types to the Selected Messages list. Use the control key to select multiple message types.

  • Move All - Moves all messages currently in the Available Messages list to the Selected Messages list.

  • Remove - Moves the selected message types from the Selected Messages list to the Available Messages list. Use the control key to select multiple message types.

  • Remove All - Moves all messages currently in the Selected Messages list to the Available Messages list.

You can also double-click on a message type to move it from one list to the other.

The buttons at the bottom of the page perform the following functions:

  • Apply - saves changes made to the page for signed/unsigned messages.

  • Cancel - Returns to the Service Provider - Global Settings page without saving any changes.

6.3.3.6 Service Provider - Select Messages to Receive Signed

This page displays a list of federation protocol message types for messages received by Oracle Identity Federation in Service Provider mode. Use this page to specify which types of messages the server requires to be signed. The messages are displayed along with their transport bindings.

This screen is fully explained in the text.

Available Messages

Messages in this list are not required to be signed.

Selected Messages

Messages in this list are required to be signed.

Actions

Buttons on the page provide these actions:

  • Move - Moves the selected message types to the Selected Messages list. Use the control key to select multiple message types.

  • Move All - Moves all messages currently in the Available Messages list to the Selected Messages list.

  • Remove - Moves the selected message types from the Selected Messages list to the Available Messages list. Use the control key to select multiple message types.

  • Remove All - Moves all messages currently in the Selected Messages list to the Available Messages list.

You can also double-click on a message type to move it from one list to the other.

The buttons at the bottom of the page perform the following functions:

  • Apply - saves changes made to the page for signed/unsigned messages.

  • Cancel - returns to the Service Provider - Global Settings page without saving any changes.

6.3.4 Editing Protocol-specific IdP Properties

This section describes how to edit and update the protocol-specific Identity Provider (IdP) properties in Oracle Identity Federation. It contains these sub-sections:

6.3.4.1 Identity Provider - Liberty 1.1 Properties

Use this page to maintain IdP properties in the Liberty 1.1 protocol for the Oracle Identity Federation instance.

This figure is explained in surrounding text.

The page provides these options:

Enable Protocol Profiles

Click Select to choose the protocol profiles and transport bindings that you wish to enable for this federation server instance in IdP mode for Liberty 1.1.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Federation Termination Enabled

Check this box to enable the federation termination capability.

See "Federation Termination Profile" for an explanation of this feature.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Register NameID Enabled

Check this box to enable name ID registration.

See "Name Identifier Profiles" for an explanation of this feature.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Use Global Value - Select All

Several IdP properties specific to Liberty 1.1 can be specified on the page. Check this box to specify that global IdP property settings will override the following local settings:

  • Artifact Timeout

  • Request Timeout

  • Assertion Validity

  • Reauthenticate After

  • Server Clock Drift

  • Default Binding

  • Default SSO Response Binding

Use Select All in this way:

  • Check the box to specify that global identity provider property settings override the local settings of all the listed properties.

  • Uncheck the box to ensure that the local settings of all the properties override global settings.

To specify that the local setting of a given property overrides the global setting, uncheck the box for that property.

Artifact Timeout

This is the validity time, in seconds, of an artifact object created by the Oracle Identity Federation. The default is 300 seconds.

Request Timeout

This is the validity time, in seconds, of an outgoing request from the Oracle Identity Federation. The default is 120 seconds.

Assertion Validity

This is the time, in seconds, during which an assertion issued by the identity provider is valid. An assertion is considered invalid if processed outside the validity period. The default is 300 seconds.

Reauthenticate After

Assertions containing an authentication statement by the identity provider are only valid for a specific time, after which the user is considered non-authenticated. This is the time, in seconds, after which the service provider must re-authenticate the user. The default is 3600 seconds.

Note:

This feature is applicable to OracleAS Single Sign-On authentication. For a limitation on forced reauthentication, see "Deploying Oracle Identity Federation with OracleAS Single Sign-On".

Server Clock Drift

This is the time, in seconds, during which an assertion issued by the identity provider is valid. An assertion is considered invalid if processed outside the validity period. The default is 300 seconds.

Default Binding

Specifies the preferred binding to use, when possible, in sending messages to peer providers. Valid values are:

  • HTTP Redirect

  • HTTP POST

  • SOAP

Default SSO Response Binding

Specifies the preferred binding for the identity provider to use, when possible, in sending an unsolicited assertion to the service provider. Valid values are:

  • Artifact

  • HTTP POST

The buttons at the bottom of the page perform the following functions:

  • Save - saves changes made to Identity Provider configuration properties.

  • Reset - restores the screen to its original values without saving any changes.

6.3.4.2 Enable Liberty 1.1 Identity Provider Profiles

Use this page to select the Liberty 1.1 IdP profiles and bindings for the Oracle Identity Federation instance.

This screen is described in the text.

Available Profiles

Profiles and bindings in this list are disabled for the federation server instance.

Selected Profiles

Profiles and bindings in this list are enabled for the federation server instance.

Actions

Buttons on the page provide these actions:

  • Move - Moves the selected profiles/bindings to the Selected Profiles list. Use the control key to select multiple profiles/bindings.

  • Move All - Moves all profiles/bindings currently in the Available Profiles list to the Selected Profiles list.

  • Remove - Moves the selected profiles/bindings from the Selected Profiles list to the Available Profiles list. Use the control key to select multiple profiles/bindings.

  • Remove All - Moves all profiles/bindings currently in the Selected Profiles list to the Available Profiles list.

The buttons at the bottom of the page perform the following functions:

  • Update - saves changes made to the profiles/bindings.

  • Cancel - returns you to the Identity Provider - Liberty 1.1 Properties page without saving any changes.

6.3.4.3 Identity Provider - Liberty 1.2 Properties

Use this page to maintain IdP properties in the Liberty 1.2 protocol for the Oracle Identity Federation instance.

This screen is described in the text.

The page provides these options:

Assertion NameID Formats

Click Select to choose the Liberty 1.2 protocol NameID formats that you wish to enable for this federation server instance in IdP mode.

Enable Protocol Profiles

Click Select to choose the Liberty 1.2 protocol profiles and transport bindings that you wish to enable for this federation server instance in IdP mode.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Federation Termination Enabled

Check this box to enable the federation termination capability.

See "Federation Termination Profile" for an explanation of this feature.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Register NameID Enabled

Check this box to enable name ID registration.

See "Name Identifier Profiles" for an explanation of this feature.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

The subsequent fields affect global properties.

Use Global Value - Select All

Several IdP properties specific to Liberty 1.2 can be specified on the page. Check this box to specify that global IdP property settings will override the following local settings:

  • Artifact Timeout

  • Request Timeout

  • Assertion Validity

  • Reauthenticate After

  • Server Clock Drift

  • Default Binding

  • Default SSO Response Binding

Use Select All in this way:

  • Check the box to specify that global IdP property settings override the local settings of all the above properties.

  • Uncheck the box to ensure that the local settings of all the properties override global settings.

To specify that the local setting of a given property overrides the global setting, uncheck the box for that property.

Artifact Timeout

This is the validity time, in seconds, of an artifact object created by Oracle Identity Federation. The default is 300 seconds.

Request Timeout

This is the validity time, in seconds, of an outgoing request from the Oracle Identity Federation. The default is 120 seconds.

Assertion Validity

This is the time, in seconds, during which an assertion issued by the identity provider is valid. An assertion is considered invalid if processed outside the validity period. The default is 300 seconds.

Reauthenticate After

When the IdP creates an assertion containing an authentication statement, it sets a time limit for the validity of the authentication. This is the time, in seconds, after which the peer service provider should re-authenticate the user. The default is 3600 seconds.

Note:

This feature is applicable to OracleAS Single Sign-On authentication. For a limitation on forced reauthentication, see "Deploying Oracle Identity Federation with OracleAS Single Sign-On".

Server Clock Drift

This is the allowable time difference, in seconds, between Oracle Identity Federation, when acting as identity provider, and its peer servers. The default is 600 seconds.

Default Binding

Specifies the preferred binding to use, when possible, in sending messages to peer providers. Valid values are:

  • HTTP Redirect

  • HTTP POST

  • SOAP

Default SSO Response Binding

Specifies the preferred binding for the identity provider to use, when possible, in sending an unsolicited assertion to the service provider. Valid values are:

  • HTTP POST

  • SOAP

The buttons at the bottom of the page perform the following functions:

  • Save - saves changes made to Identity Provider configuration properties.

  • Reset - restores the screen to its original values without saving any changes.

6.3.4.4 Enable Liberty 1.2 Identity Provider Profiles

Use this page to select the Liberty 1.2 IdP profiles and bindings for the Oracle Identity Federation instance.

This screen is described in the text.

Available Profiles

Profiles and bindings in this list are disabled for the federation server instance.

Selected Profiles

Profiles and bindings in this list are enabled for the federation server instance.

Actions

Buttons on the page provide these actions:

  • Move - Moves the selected profiles/bindings to the Selected Profiles list. Use the control key to select multiple profiles/bindings.

  • Move All - Moves all profiles/bindings currently in the Available Profiles list to the Selected Profiles list.

  • Remove - Moves the selected profiles/bindings from the Selected Profiles list to the Available Profiles list. Use the control key to select multiple profiles/bindings.

  • Remove All - Moves all profiles/bindings currently in the Selected Profiles list to the Available Profiles list.

The buttons at the bottom of the page perform the following functions:

  • Apply - saves changes made to Service Provider configuration properties.

  • Cancel - restores the screen to its original values without saving any changes.

6.3.4.5 Select Liberty 1.2 Identity Provider NameID Formats

Use this page to select the Liberty 1.2 IdP NameID formats for the Oracle Identity Federation instance.

This figure is described in the text.

On this page, you can:

  • enable one or more of the listed assertion NameID formats

  • choose a default Assertion NameID format

The buttons at the bottom of the page perform the following functions:

  • Apply - saves changes made to the list of enabled NameID formats.

  • Cancel - restores the screen to its original values without saving any changes.

6.3.4.6 Identity Provider - SAML 2.0 Properties

Use this page to maintain IdP properties in the SAML 2.0 protocol for the Oracle Identity Federation instance.

This figure is explained in surrounding text.
This figure is explained in surrounding text.

The page provides these options:

Assertion NameID Formats

Click Select to choose the assertion NameID formats that you wish to enable for this federation server instance in IdP mode for SAML 2.0.

Enable Protocol Profiles

Click Select to choose the protocol profiles and transport bindings that you wish to enable for this federation server instance in IdP mode for SAML 2.0.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Federation Termination Enabled

Check this box to enable the federation termination capability.

See "Federation Termination Profile" for an explanation of this feature.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Register NameID Enabled

Check this box to enable name ID registration.

See "Name Identifier Profiles" for an explanation of this feature.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Auto Account Linking Enabled

Check this box to enable the auto account linking feature. When the IdP receives an authentication request containing a non-opaque nameid (for example, email address, X.500 name, and so on), it will look for a user with a matching nameid among its user accounts and automatically create a federation between the two user accounts if a federation does not already exist.

Send Encrypted Assertion

Check this box to enable Oracle Identity Federation to send encrypted assertions to peer providers.

Send Encrypted NameIDs

Check this box to enable Oracle Identity Federation to send encrypted name identifiers to peer providers.

Send Encrypted Attributes

Check this box to enable Oracle Identity Federation to send encrypted attributes to peer providers.

Attribute Responder Enabled

Check this box to enable attribute responder.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Use Global Value - Select All

Several IdP properties specific to SAML 2.0 can be specified on the page. Check this box to specify that global IdP property settings will override the following local settings:

  • Artifact Timeout

  • Request Timeout

  • Assertion Validity

  • Reauthenticate After

  • Server Clock Drift

  • Default Binding

  • Default SSO Response Binding

Use Select All in this way:

  • Check the box to specify that global IdP property settings override the local settings of all the above properties.

  • Uncheck the box to ensure that the local settings of all the properties override global settings.

To specify that the local setting of a given property overrides the global setting, uncheck the box for that property.

Artifact Timeout

This is the validity time, in seconds, of an artifact object created by the Oracle Identity Federation. The default is 300 seconds.

Request Timeout

This is the validity time, in seconds, of an outgoing request from the Oracle Identity Federation. The default is 120 seconds.

Assertion Validity

This is the time, in seconds, during which an assertion issued by the identity provider is valid. An assertion is considered invalid if processed outside the validity period. The default is 300 seconds.

Reauthenticate After

This is the time, in seconds, after which the service provider must re-authenticate the user. Assertions containing an authentication statement by the identity provider are only valid for this period, after which the user is to be considered non-authenticated. The default is 3600 seconds.

Note:

This feature is applicable to OracleAS Single Sign-On authentication. For a limitation on forced reauthentication, see "Deploying Oracle Identity Federation with OracleAS Single Sign-On".

Server Clock Drift

This is the allowable time difference, in seconds, between Oracle Identity Federation, when acting as identity provider, and its peer servers.

Default Binding

Specifies the preferred binding to use, when possible, in sending messages to peer providers. Valid values are:

  • HTTP Redirect

  • HTTP POST

  • SOAP

Default SSO Response Binding

Specifies the preferred binding for the identity provider to use, when possible, in sending an unsolicited assertion to the service provider. Valid values are:

  • Artifact

  • HTTP POST

The buttons at the bottom of the page perform the following functions:

  • Update - saves changes made to Identity Provider configuration properties.

  • Cancel - restores the screen to its original values without saving any changes.

6.3.4.7 Enable SAML 2.0 Identity Provider Profiles

Use this page to maintain IdP profiles and bindings for the SAML 2.0 protocol.

This screen is explained in the text.

Available Profiles

Profiles and bindings in this list are disabled for the federation server instance in IdP mode.

Selected Profiles

Profiles and bindings in this list are enabled for the federation server instance in IdP mode.

Actions

Buttons on the page provide these actions:

  • Move - Moves the selected profiles/bindings to the Selected Profiles list. Use the control key to select multiple profiles/bindings.

  • Move All - Moves all profiles/bindings currently in the Available Profiles list to the Selected Profiles list.

  • Remove - Moves the selected profiles/bindings from the Selected Profiles list to the Available Profiles list. Use the control key to select multiple profiles/bindings.

  • Remove All - Moves all profiles/bindings currently in the Selected Profiles list to the Available Profiles list.

The buttons at the bottom of the page perform the following functions:

  • Apply - saves changes made to Identity Provider profile selections.

  • Cancel - restores the screen to its original values without saving any changes.

6.3.4.8 Select SAML 2.0 Identity Provider NameID Formats

Use this page to maintain assertion name identifier formats for the SAML 2.0 protocol.

This screen is explained in the text.

Check the corresponding box to enable the desired format(s) that the Oracle Identity Federation instance will use as the SAML 2.0 name identifier value in IdP mode. The formats are as follows:

Table 6-3 SAML 2.0 IdP NameID Formats

NameID Format Default

X.509 Subject Name

DN

Email Address

e-mail

Windows Domain Qualified Name

empty

Kerberos Principal Name

empty

Persistent Identifier

 

Transient/One-Time Identifier

 

Default Assertion NameID Format

This is the SAML 2.0 assertion name identifier format to use when none is specified for the federation server in IdP mode.

The buttons at the bottom of the page perform the following functions:

  • Apply - saves changes made to IdP NameID configuration properties.

  • Cancel - returns you to Edit SAML 2.0 Identity Provider Properties without saving any changes.

6.3.5 Editing Protocol-specific SP Properties

This section describes how to edit and update the protocol-specific Service Provider (SP) properties in Oracle Identity Federation. It contains these sub-sections:

6.3.5.1 Service Provider - Liberty 1.1 Properties

Use this page to maintain Service Provider properties for the Liberty 1.1 protocol.

This screen is fully explained in the text.

The page provides these options:

Enable Protocol Profiles

Click Select to choose the protocol profiles and transport bindings that you wish to enable for this federation server instance in SP mode for Liberty 1.1.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Federation Termination Enabled

Check this box to enable the federation termination capability.

See "Federation Termination Profile" for an explanation of this feature.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Register NameID Enabled

Check this box to enable name ID registration.

See "Name Identifier Profiles" for an explanation of this feature.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Subsequent fields apply to global properties.

Use Global Value - Select All

Several SP properties specific to Liberty 1.1 can be specified on the page. Check this box to specify that global SP property settings will override the following local settings:

  • Ignore Unknown Conditions

  • Artifact Timeout

  • Request Timeout

  • Server Clock Drift

  • Default Binding

  • Default SSO Request Binding

  • Default SSO Response Binding

  • Default SSO Identity Provider

Use Select All in this way:

  • Check the box to specify that global service provider property settings override the local settings of all the listed properties.

  • Uncheck the box to ensure that the local settings of all the properties override global settings.

To specify that the local setting of a given property overrides the global setting, uncheck the box for that property.

Ignore Unknown Conditions

A condition is an extension point in the XML schema. Custom conditions can be defined according to specific needs - for example, to denote that assertion X is conditional in a given time zone. Such conditions may not be amenable to evaluation, and checking this box allows the server to ignore a condition it does not recognize.

Request Timeout

This is the validity time, in seconds, of an outgoing request from Oracle Identity Federation. The default is 120 seconds.

Server Clock Drift

This is the allowable time difference, in seconds, between Oracle Identity Federation, when acting as service provider, and its peer servers. The default is 600 seconds.

Default Binding

Specifies the preferred binding to use, when possible, in sending messages to peer providers. Valid values are:

  • HTTP Redirect

  • HTTP POST

  • SOAP

Default SSO Request Binding

Specifies the preferred binding for the service provider to use, when possible, in sending authentication requests to the identity provider. Valid values are:

  • HTTP Redirect

  • HTTP POST

Default SSO Response Binding

Specifies the preferred binding for the identity provider to use, when possible, in sending an unsolicited assertion to the service provider. Valid values are:

  • Artifact

  • HTTP POST

Default SSO Identity Provider

This is the default IdP to use in performing the single sign-on operation. Select a provider from the list of available IdPs.

The buttons at the bottom of the page perform the following functions:

  • Save - saves changes made to Service Provider configuration properties.

  • Reset - restores the screen to its original values without saving any changes.

6.3.5.2 Enable Liberty 1.1 Service Provider Profiles

Use this page to maintain Liberty 1.1 protocol profiles and bindings for Oracle Identity Federation in a service provider role.

This screen is explained in the text.

Available Profiles

Profiles and bindings in this list are disabled for the federation server instance.

Selected Profiles

Profiles and bindings in this list are enabled for the federation server instance.

Actions

Buttons on the page provide these actions:

  • Move - Moves the selected profiles/bindings to the Selected Profiles list. Use the control key to select multiple profiles/bindings.

  • Move All - Moves all profiles/bindings currently in the Available Profiles list to the Selected Profiles list.

  • Remove - Moves the selected profiles/bindings from the Selected Profiles list to the Available Profiles list. Use the control key to select multiple profiles/bindings.

  • Remove All - Moves all profiles/bindings currently in the Selected Profiles list to the Available Profiles list.

The buttons at the bottom of the page perform the following functions:

  • Apply - saves changes made to Service Provider profiles/bindings.

  • Cancel - returns you to Service Provider Liberty 1.1 Properties without saving any changes.

6.3.5.3 Service Provider - Liberty 1.2 Properties

Use this page to maintain Oracle Identity Federation properties as Service Provider in the Liberty 1.2 protocol.

This screen is fully explained in the text.
This screen is fully explained in the text.

The page provides these options:

Enable Protocol Profiles

Click Select to choose the protocol profiles and transport bindings that you wish to enable for this federation server instance in SP mode for Liberty 1.2.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Federation Termination Enabled

Check this box to enable the federation termination capability.

See "Federation Termination Profile" for an explanation of this feature.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Register NameID Enabled

Check this box to enable name ID registration.

See "Name Identifier Profiles" for an explanation of this feature.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Default Authn Request NameID Format

Use the list box to select a default name ID format for authentication requests. Choices are:

  • Persistent identifier

  • Transient/one-time identifier

  • Unspecified

If set to Unspecified, the IdP will determine the format.

Subsequent fields relate to global SP settings.

Use Global Value - Select All

Several SP properties specific to Liberty 1.2 can be specified on the page. Check this box to specify that global SP property settings will override the following local settings:

  • Ignore Unknown Conditions

  • Artifact Timeout

  • Request Timeout

  • Server Clock Drift

  • Default Binding

  • Default SSO Request Binding

  • Default SSO Response Binding

  • Default SSO Identity Provider

Use Select All in this way:

  • Check the box to specify that global service provider property settings override the local settings of all the listed properties.

  • Uncheck the box to ensure that the local settings of all the properties override global settings.

To specify that the local setting of a given property overrides the global setting, uncheck the box for that property.

Ignore Unknown Conditions

A condition is an extension point in the XML schema. Custom conditions can be defined according to specific needs - for example, to denote that assertion X is conditional in a given time zone. Such conditions may not be amenable to evaluation, and checking this box allows the server to ignore a condition it does not recognize.

Request Timeout

This is the validity time, in seconds, of an outgoing artifact request from Oracle Identity Federation. The default is 120 seconds.

Server Clock Drift

This is the allowable time difference, in seconds, between Oracle Identity Federation, when acting as service provider, and its peer servers. The default is 600 seconds.

Default Binding

Specifies the preferred binding to use, when possible, in sending messages to peer providers. Valid values are:

  • HTTP Redirect

  • HTTP POST

  • SOAP

Default SSO Request Binding

Specifies the preferred binding for the service provider to use, when possible, in sending authentication requests to the identity provider. Valid values are:

  • HTTP Redirect

  • HTTP POST

Default SSO Response Binding

Specifies the preferred binding for the identity provider to use, when possible, in sending an unsolicited assertion to the service provider. Valid values are:

  • Artifact

  • HTTP POST

Default SSO Identity Provider

This is the default IdP to use in performing the single sign-on operation. Select a provider from the list of available IdPs.

The buttons at the bottom of the page perform the following functions:

  • Save - saves changes made to Service Provider configuration properties.

  • Reset - restores the screen to its original values without saving any changes.

6.3.5.4 Enable Liberty 1.2 Service Provider Profiles

Use this page to maintain Oracle Identity Federation profiles and bindings for the Liberty 1.2 protocol.

This screen is described in the text.

Available Profiles

Profiles and bindings in this list are disabled for the federation server instance.

Selected Profiles

Profiles and bindings in this list are enabled for the federation server instance.

Actions

Buttons on the page provide these actions:

  • Move - Moves the selected profiles/bindings to the Selected Profiles list. Use the control key to select multiple profiles/bindings.

  • Move All - Moves all profiles/bindings currently in the Available Profiles list to the Selected Profiles list.

  • Remove - Moves the selected profiles/bindings from the Selected Profiles list to the Available Profiles list. Use the control key to select multiple profiles/bindings.

  • Remove All - Moves all profiles/bindings currently in the Selected Profiles list to the Available Profiles list.

The buttons at the bottom of the page perform the following functions:

  • Apply - saves changes made to Service Provider profiles/bindings.

  • Cancel - returns you to Service Provider Liberty 1.2 Properties without saving any changes.

6.3.5.5 Service Provider - SAML 2.0 Properties

Use this page to maintain Oracle Identity Federation properties in service provider mode under the SAML 2.0 protocol.

This screen is fully explained in the text.
This screen is fully explained in the text.

The page provides these options:

Enable Protocol Profiles

Click Select to choose the protocol profiles and transport bindings that you wish to enable for this federation server instance in service provider mode for SAML 2.0.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Federation Termination Enabled

Check this box to enable the federation termination functionality.

See "Federation Termination Profile" for an explanation of this feature.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Register NameID Enabled

Check this box to enable the name ID registration functionality.

See "Name Identifier Profiles" for an explanation of this feature.

Note:

This property affects server metadata. When updating this property, distribute the updated metadata to all providers in your circle of trust.

Attribute Requester Enabled

Check this box to indicate that the SAML attribute sharing profile is enabled.

Default Authn Request NameID Format

Use the list box to select a default name ID format for authentication requests. Choices are:

  • X.509 Subject Name

  • Email Address

  • Windows Domain Qualified Name

  • Kerberos Principal Name

  • Persistent identifier

  • Transient/one-time identifier

  • Unspecified

Account Linking NameID Formats

Click Select to maintain auto account linking name identifier formats for the SAML 2.0 SSO protocol.

Auto Account Linking Enabled

When the service provider receives an authentication assertion from a peer identity provider, and the federation referenced in the assertion does not exist, the SP needs to locally authenticate the user to create the federation and perform the account linking operation.

If you check this box to enable the auto account linking feature, the SP will use the non-opaque name ID (e-mail, X.509, and so on) contained in the assertion to locate the user and automatically authenticate and perform the account linking steps.

Notes:

  • Only the name identifier formats configured under Account Linking NameID Formats will be used for auto account linking.

  • If the lookup operation returns two or more users, the SP will prompt the user for authentication.

Send Encrypted NameIDs

Check this box to enable Oracle Identity Federation to send encrypted name identifiers to peer providers.

Send Encrypted Attributes

Check this box to enable Oracle Identity Federation to send encrypted attributes to peer providers.

Use Global Value - Select All

Several service provider properties applicable to SAML 2.0 can be specified on the page:

  • Ignore Unknown Conditions

  • Artifact Timeout

  • Request Timeout

  • Server Clock Drift

  • Default Binding

  • Default SSO Request Binding

  • Default SSO Response Binding

  • Default SSO Identity Provider

Use Select All in this way:

  • Check the box to specify that global service provider property settings override the local settings of all the listed properties.

  • Uncheck the box to ensure that the local settings of all the properties override global settings.

To specify that the local setting of a given property overrides the global setting, uncheck the box for that property.

Ignore Unknown Conditions

A condition is an extension point in the XML schema. Custom conditions can be defined according to specific needs - for example, to denote that assertion X is conditional in a given time zone. Such conditions may not be amenable to evaluation, and checking this box allows the server to ignore a condition it does not recognize.

Request Timeout

This is the validity time, in seconds, of an outgoing request from the Oracle Identity Federation.

Server Clock Drift

This is the allowable time difference, in seconds, between Oracle Identity Federation, when acting as service provider, and its peer servers.

Default Binding

Specifies the preferred binding to use, when possible, in sending messages to peer providers. Valid values are:

  • HTTP Redirect

  • HTTP POST

  • SOAP

Default SSO Request Binding

Specifies the preferred binding for the service provider to use, when possible, in sending authentication requests to the identity provider. Valid values are:

  • HTTP Redirect

  • HTTP POST

Default SSO Response Binding

Specifies the preferred binding for the identity provider to use, when possible, in sending an unsolicited assertion to the service provider. Valid values are:

  • Artifact

  • HTTP POST

Default SSO Identity Provider

This is the default identity provider to use in performing the single sign-on operation. Select a provider ID from among the choices presented in the list box.

The buttons at the bottom of the page perform the following functions:

  • Save - saves changes made to SAML 2.0 Service Provider profiles/bindings.

  • Reset - restores the screen to its original values without saving any changes.

6.3.5.6 Enable SAML 2.0 Service Provider Profiles

Use this page to maintain SP profiles and bindings for the SAML 2.0 protocol.

This screen is described in the text.

Available Profiles

Profiles and bindings in this list are disabled for the federation server instance in SP mode.

Selected Profiles

Profiles and bindings in this list are enabled for the federation server instance in SP mode.

Actions

Buttons on the page provide these actions:

  • Move - Moves the selected profiles/bindings to the Selected Profiles list. Use the control key to select multiple profiles/bindings.

  • Move All - Moves all profiles/bindings currently in the Available Profiles list to the Selected Profiles list.

  • Remove - Moves the selected profiles/bindings from the Selected Profiles list to the Available Profiles list. Use the control key to select multiple profiles/bindings.

  • Remove All - Moves all profiles/bindings currently in the Selected Profiles list to the Available Profiles list.

The buttons at the bottom of the page perform the following functions:

  • Apply - saves changes made to SAML 2.0 Service Provider profiles/bindings.

  • Cancel - returns you to the Service Provider SAML 2.0 Properties page without saving any changes.

6.3.5.7 Select SAML 2.0 Service Provider NameID Formats

Use this page to maintain SAML 2.0 protocol name identifier formats for Oracle Identity Federation in SP mode.

This screen is described in the text.

Check the corresponding Enable box to enable the desired format(s) that the Oracle Identity Federation instance will use as the SAML 2.0 name identifier value in IdP mode.

NameID Format

This column displays the available SAML 2.0 NameID formats.

User Attribute Mapping

Enter the attribute name for the selected name ID format. Oracle Identity Federation will use this attribute name to perform a lookup in the user data store for a name ID in this format.

The name identifier formats are as follows:

Table 6-4 SAML 2.0 SP Name ID Formats

NameID Format Mapping

X.509 Subject Name

DN

Email Address

e-mail

Windows Domain Qualified Name

empty

Kerberos Principal Name

empty


The buttons at the bottom of the page perform the following functions:

  • Save - saves changes made to NameID format selections

  • Reset - returns you to Service Provider SAML 2.0 Properties without saving any changes

6.3.6 Service Provider - Attribute Requester

Use this page to configure the mapping of DNs or sub-DNs to IdPs. This configuration is used with the Attribute Sharing Profile.

This screen is fully explained in the text.

When an application sends an attribute request to this Oracle Identity Federation server with an X.509 SubjectDN, the server uses these mappings to determine to which IdP to send a SAML 2.0 AttributeQuery message on behalf of the application. Oracle Identity Federation will match the SubjectDN with the DNs configured here, from the most general to the most specific DNs.

Consider an example with two peer companies: PeerA has one identity provider and PeerB has three identity providers, for divisions Div1, Div2, and all other divisions. The attribute requester mappings might look like this:

Table 6-5 Example DN-to-IdP Mappings

DN IdP

O=PeerA,C=US

http://fed.peera.com/fed/idp

OU=Div1,O=PeerB,C=US

http://fed.div1.peerb.com/fed/idp

OU=Div2,O=PeerB,C=US

http://fed.div2.peerb.com/fed/idp

O=PeerB,C=US

http://fed.other.peerb.com/fed/idp


Table 6-6 Example SubjectDN-to-IdP Mappings

SubjectDN Maps to IdP

CN=John Doe,OU=DeptA,O=PeerA,C=US

http://fed.peera.com/fed/idp

CN=Jane Smith,OU=Div1,O=PeerB,C=US

http://fed.div1.peerb.com/fed/idp

CN=Bill Jones,OU=DeptY,OU=Div2,O=PeerB,C=US

http://fed.div2.peerb.com/fed/idp

CN=Sam McCoy,OU=Div5,O=PeerB,C=US

http://fed.other.peerb.com/fed/idp


DN Pattern

This is the DN or sub-DN being mapped.

Identity Provider/Attribute Responder

This is the identity provider or attribute responder URL to which the DN is being mapped.

Remove

Check this box and use the Update button to remove an existing mapping.

Note on Handling Unknown RDN Components

If the DN pattern contains RDN component types that are unknown to Oracle Identity Federation, you will not be able to add the entry to the responder mappings list.

You can resolve this by defining RDN component types in the Oracle Identity Federation server configuration file so that the server will recognize them. Take the following steps to implement this:

  1. Open the $ORACLE_HOME/fed/conf/config.xml file

  2. Search for the entry <Config name="dnidpmapping">. Add the RDN component type as shown:

    <propertyset name="x500rdns">
        <propertyvalue>Email</propertyvalue>
        <propertyvalue>emailAddress</propertyvalue>
        <propertyvalue>NEW_RDN_COMPONENT</propertyvalue>
    </propertyset>
    <property name="Email">1.2.840.113549.1.9.1</property>
    <property name="emailAddress">1.2.840.113549.1.9.1</property>
    <property name="NEW_RDN_COMPONENT">NEW_OID</property>
    
    
  3. Save the changes and restart the server.

Notes:

  • Do not remove the entries already present in the file.

  • You cannot use the Oracle Identity Federation Administrative console while making changes to the file, and should restart the server as soon as you are done with the changes.

Actions

Buttons on the page provide these actions:

  • Add Mapping - Adds a new row for DN-to-IdP mapping information.

  • Apply - adds a new mapping, deletes or saves changes you make to attribute responder mappings.

    After adding the information for a new mapping, press Update to store the new entry.

    To delete an existing mapping, check the corresponding box in the Remove column and press Update.

  • Cancel - returns to the main Server Configuration page without saving any changes.

6.3.7 Editing Circles of Trust

This section describes how to edit and maintain Circle of Trust properties in Oracle Identity Federation. It contains these sub-sections:

Note that configuration data is managed in the context of other providers in the circle of trust. Configuration details affect a provider's metadata, which must be re-published when certain data changes. There is a two-way exchange - a site administrator publishes metadata so that peer providers can load this data, and the administrator is also responsible for loading metadata published by peer providers in the circle of trust.

See Also:

For additional details, see "Server Configuration Data"

6.3.7.1 Circle of Trust

Use this page to add and update trusted providers in Oracle Identity Federation's circle of trust. The page displays three types of entities:

  • Identity Providers

  • Service Providers

  • Affiliations, which are groupings of providers

This screen is fully explained in the text.
This screen is fully explained in the text.

Trusted Provider

Lists, in separate sets, the identity providers, service providers, and affiliations currently in the circle of trust. The fields in each set are:

  • Provider Id - this is the provider ID

  • Description - this is a brief description of the provider

  • Version - this is the protocol version:

    • 1.1 (Liberty 1.1)

    • 1.2 (Liberty 1.2)

    • 2.0 (SAML 2.0)

Select a provider from the current trusted IdPs, SPs, and affiliations, and use these buttons to perform the following functions:

  • Update - update provider or affiliation properties.

  • Remove - remove the provider or affiliation from the circle of trust.

    Note:

    If you remove a provider from the circle of trust which serves as the Default Single Sign-On (SSO) Identity Provider (defined on the "Service Provider - Global Settings" page), you must select a new default IdP on that page.

Add Trusted Provider

Allows additional peer providers to be included in the circle of trust. The fields are:

  • Metadata Location - this is the location of the file containing the peer provider's metadata. Click Browse to choose a location.

  • Description - this is a brief description of the provider.

Use the Add button to add the provider to the circle of trust.

Note:

When you add a new provider to the circle of trust, it is automatically enabled and federation operations can be performed with the provider.
6.3.7.1.1 Metadata Signing Support

Oracle Identity Federation 10.1.4.2 supports XML Digital Signatures in the XML Metadata documents that describe the services published by a compliant Federation Server. Oracle Identity Federation provides the following support for metadata signatures:

  • digitally signing the metadata Oracle Identity Federation publishes

  • verifying any XML digital signature present on a metadata document that is being uploaded to the server. If the verification fails, the metadata will not be uploaded.

  • configuring the server to require an XML Digital Signature on the metadata in order to upload it into the circle of trust.

Take these steps to configure Oracle Identity Federation to sign the metadata it publishes:

  1. Open the $ORACLE_HOME/fed/conf/config.xml file.

  2. Locate the FederationConfig XML Element, and set its useLocalConfig attribute to true:

    <FederationConfig useLocalConfig="true">
    
    
  3. Locate the XML Config element named serverconfig, and look for the metadatasign property:

    <Config name="serverconfig">
    ...
       <property name="metadatasign">false</property>
    ...
    </Config>
    
    

    Change the value of the property to true to configure Oracle Identity Federation to sign the XML Metadata documents, or to false to not sign the metadata.

  4. Save the file and exit.

  5. Restart the OC4J_FED instance.

Take these steps to configure Oracle Identity Federation to require signed metadata when importing a descriptor to the circle of trust:

  1. Open the $ORACLE_HOME/fed/conf/config.xml file.

  2. Locate the FederationConfig XML element, and set its useLocalConfig attribute to true:

    <FederationConfig useLocalConfig="true">
    
    
  3. Locate the XML Config element named serverconfig, and look for the metadatarequiresigned property:

    <Config name="serverconfig">
    ...
       <property name="metadatarequiresigned">false</property>
    ...
    </Config>
    
    

    Change the value of the property to true to require signed XML Metadata documents. Change the value to false to accept signed and unsigned metadata.

  4. Save the file and exit.

  5. Restart the OC4J_FED instance.

6.3.7.2 Editing a Trusted Provider

Clicking Update for a selected provider on the Circle of Trust page displays this page, on which you can edit properties for a trusted provider in the circle of trust.

Local properties (which are defined here) and global properties (inherited from global or protocol settings) are displayed separately.

This screen is fully explained in the text.
This screen is fully explained in the text.

The local properties are:

Provider ID

This is the provider ID in URI format.

Description

This is a description of the provider.

Metadata Location

Enter the file path to the metadata.

If the metadata has changed, you can use the Load New button to upload the new metadata.

Enable Provider

Check this box to enable this provider in the circle of trust.

Note:

The next two fields, Enable Attributes in SSO and Attribute Mappings, apply only if your server instance operates as an identity provider, and the trusted provider (being configured here) is a service provider.

Enable Attributes in SSO

Check this box to specify that Oracle Identity Federation should send attributes with the authentication assertion when acting as an IdP.

Attribute Mappings

If you specified that the server should send attributes with the authentication assertion, click Select to define the attributes.

If the IdP acts as an Attribute Authority accepting attribute query requests and sending back attribute assertions, you will need to configure the attribute mappings.

Subsequent fields relate to global properties.

Use Global Value - Select All

Several global properties can be defined on this page.

Use Select All in this way:

  • Check the box to specify that global trusted provider settings override the local settings of all the listed properties.

  • Uncheck the box to ensure that the local settings of all the properties override global settings.

Force User Consent

Check this box to force consent for setting up a new federation. A user who is redirected to the federation server will explicitly have to accept or deny account linking in order to proceed.

User Consent URL

Enter the URL to be displayed to the user to obtain consent for federation.

The server passes a number of query parameters to this URL:

Table 6-7 Parameters Passed to User Consent URL (Local Setting)

Parameter Description

providerid

This is the peer provider id.

description

This is the description of the peer provider id.

returnurl

This is the URL to which the user should be directed once a consent decision has been made.

refid

This is passed as a query parameter to the returnurl. Oracle Identity Federation require this parameter in order to resume the operation the server had been performing prior to redirection to the consent URL.


Use this field only if Force User Consent is checked.

Here is an example of a consent page:

<%
    String prefix = request.getContextPath();
    String redirectURL = request.getParameter("returnurl");
    String refID = request.getParameter("refid");
    String providerID = request.getParameter("providerid");
    String desc = request.getParameter("description");
%>
<HTML>
<BODY>
Do you consent to create a federation with <%=providerID%> (<%=desc%>):<br>
<form method="POST" action="<%=redirectURL%>">
    <input type="checkbox" name="userconsent" value="true"/>I agree<br>
    <input type="submit" value="OK" />
    <input type="hidden" name="refid"  value="<%=refID%>"/>
</form>
</BODY>
</HTML>

Ignore Unknown Conditions

A condition is an extension point in the XML schema. Custom conditions can be defined according to specific needs - for example, to denote that assertion X is conditional in a given time zone. Such conditions may not be amenable to evaluation, and checking this box allows the server to ignore a condition it does not recognize.

Artifact Timeout

This is the validity time, in seconds, of an artifact object created by Oracle Identity Federation. Use only if this server instance is acting as an identity provider.

Request Timeout

This is the validity time, in seconds, of an outgoing request from Oracle Identity Federation.

Assertion Validity

This is the time, in seconds, during which an assertion issued by an identity provider is valid. An assertion is considered invalid if processed outside the validity period. Use only if this server instance is acting as an identity provider.

Reauthenticate After

This is the time, in seconds, after which the service provider must re-authenticate the user. Assertions containing an authentication statement by the identity provider are only valid for this period, after which the user is to be considered non-authenticated.

Use only if this server instance is acting as an identity provider.

Note:

This feature is applicable to OracleAS Single Sign-On authentication. For a limitation on forced reauthentication, see "Deploying Oracle Identity Federation with OracleAS Single Sign-On".

Server Clock Drift

This is the allowable time difference, in seconds, between Oracle Identity Federation, when acting as identity provider, and its peer servers.

Default Binding

Specifies the preferred binding to use, when possible, in sending messages to peer providers. Valid values are:

  • HTTP Redirect

  • HTTP POST

  • SOAP

Default SSO Request Binding

Specifies the preferred binding for the service provider to use, when possible, in sending authentication requests to the identity provider. Use only if this server instance is acting as a service provider. Valid values are:

  • HTTP Redirect

  • HTTP POST

Default SSO Response Binding

Specifies the preferred binding for the identity provider to use, when possible, in sending an unsolicited assertion to the service provider. Valid values are:

  • Artifact

  • HTTP POST

Unsolicited SSO RelayState

When an IdP performs unsolicited single sign-on operations, a relay state can be communicated to the service provider. Uncheck the box and enter the relay state.

This field is also used when the server instance is acting as a service provider. If the service provider does not receive a relay state in an authentication response from the identity provider, the service provider will use the relay state you provide here.

The Unsolicited SSO RelayState can be used as a final target URL to which the user is sent after the Single Sign-On operation successfully ends.

When an Oracle Identity Federation SP receives an unsolicited assertion, it sends the user to the relay state specified by the assertion following the SSO operation; if the relay state field in the assertion is empty, it will use the Unsolicited SSO RelayState to redirect the user.

Send Encrypted Assertion

Check this box to enable Oracle Identity Federation to send encrypted assertions to peer providers. Use only if your server instance operates as an identity provider, and the trusted provider (being configured here) is a service provider.

Note:

This field applies only to SAML 2.0.

Send Encrypted NameIDs

Check this box to enable Oracle Identity Federation to send encrypted name identifiers to peer providers.

Note:

This field applies only to SAML 2.0.

Send Encrypted Attributes

Check this box to enable Oracle Identity Federation to send encrypted attributes to peer providers. Use only if your server instance operates as an identity provider, and the trusted provider (being configured here) is a service provider.

Note:

This field applies only to SAML 2.0.

Allow Federation Creation

Use this field if your server instance operates as a service provider, and the trusted provider (being configured here) is an identity provider. Check this box to allow federation between the providers.

Do not check this box if you already have the federations you need, and you do not want new federations to be created between your SP/IdP and the peer provider.

Auto Account Linking Enabled

Check this box to enable automatic account linking.

Messages to Send Signed

Click Select to display a list of federation protocol message types and specify the messages that Oracle Identity Federation sends, in IdP mode, that it can sign.

Messages to Require Signed

Click Select to display a page which lists the federation protocol message types and specify the messages that Oracle Identity Federation receives, in IdP mode, that it requires to be signed.

NameID Formats

Click Select to choose the NameID format to use when none is specified. Choices are:

  • X.509 Subject Name

  • Email Address

  • Windows Domain Qualified Name

  • Kerberos Principal Name

  • Persistent Identifier [1]

  • Transient/One-Time Identifier [1]

Default Authn Request NameID Format

Use the list box to select a default name ID format for authentication requests. Choices are:

  • X.509 Subject Name

  • Email Address

  • Windows Domain Qualified Name

  • Kerberos Principal Name

  • Persistent identifier

  • Transient/one-time identifier

  • Unspecified

The buttons at the bottom of the page perform the following functions:

  • Apply - saves changes made to Trusted Provider properties.

  • Cancel - restores the screen to its original values without saving any changes.

6.3.7.3 Edit Trusted Provider: Attribute Mappings

If enabling attributes for a trusted identity provider, use this page to maintain SSO attribute mappings and NameID formats.

This screen is fully explained in the text.

Attribute Mappings

Each attribute consists of these properties:

  • The user attribute name in the data store from which the value will be retrieved.

  • The SAML attribute name that will be included in the assertion.

  • The attribute format, used solely in the Liberty 1.1, Liberty 1.2, and SAML 2.0 protocols to specify the Attribute Namespace, which consists of any URI.

Send with SSO Assertions

Check this box to send the attribute in an authentication assertion.

Send Attributes with SSO Assertions for Subject NameID Formats

Click the desired check boxes to specify which attributes to include with SSO assertions.

The buttons at the bottom of the page perform the following functions:

  • Update - saves changes made to attribute mappings.

  • Cancel - returns you to Edit Trusted Provider without saving any changes.

6.3.7.4 Select Messages to Send Signed

Use this page when configuring a trusted peer provider, to specify which message types that provider should send signed.

This screen is fully explained in the text.

Use this page when configuring a trusted peer provider, to specify which message types that provider should require signed.

Available Messages

Messages in this list are not required to be signed.

Selected Messages

Messages in this list are required to be signed.

Actions

Buttons on the page provide these actions:

  • Move - Moves the selected message types to the Selected Messages list. Use the control key to select multiple message types.

  • Move All - Moves all messages currently in the Available Messages list to the Selected Messages list.

  • Remove - Moves the selected message types from the Selected Messages list to the Available Messages list. Use the control key to select multiple message types.

  • Remove All - Moves all messages currently in the Selected Messages list to the Available Messages list.

The buttons at the bottom of the page perform the following functions:

  • Apply - saves changes made to the page for signed/unsigned messages.

  • Cancel - returns to the Circle of Trust - Edit Trusted Provider page without saving any changes.

6.3.7.5 Select Messages to Require Signed

Use this page when configuring a trusted peer provider, to specify which message types that provider should require signed.

This figure is explained in surrounding text.

Available Messages

Messages in this list are not required to be signed.

Selected Messages

Messages in this list are required to be signed.

Actions

Buttons on the page provide these actions:

  • Move - Moves the selected message types to the Selected Messages list. Use the control key to select multiple message types.

  • Move All - Moves all messages currently in the Available Messages list to the Selected Messages list.

  • Remove - Moves the selected message types from the Selected Messages list to the Available Messages list. Use the control key to select multiple message types.

  • Remove All - Moves all messages currently in the Selected Messages list to the Available Messages list.

The buttons at the bottom of the page perform the following functions:

  • Apply - saves changes made to the page for signed/unsigned messages.

  • Cancel - returns to the Circle of Trust - Edit Trusted Provider page without saving any changes.

6.3.7.6 Edit Trusted Provider: Select NameID Formats

Use this page when configuring a trusted peer provider, to specify the NameID formats that are to be enabled for that provider.

This screen is fully explained in the text.

NameID Format

This column displays the available NameID formats.

User Attribute Mapping

Enter the attribute name for the selected name ID format. Oracle Identity Federation will use this attribute name to perform a lookup in the user data store for a name ID in this format.

The name identifier formats are as follows:

Table 6-8 Trusted Provider Name ID Formats

NameID Format Mapping

X.509 Subject Name

DN

Email Address

e-mail

Windows Domain Qualified Name

empty

Kerberos Principal Name

empty

Persistent Identifier

empty

Transient/One-Time Identifier

empty


Default Assertion NameID Format

This is the assertion name identifier format to use for this trusted provider.

The buttons at the bottom of the page perform the following functions:

  • Apply - saves changes made to NameID format selections.

  • Cancel - returns you to Edit Trusted Provider without saving any changes.

6.3.8 Configuring and Using Affiliations

This section explains affiliations and how they are used in Oracle Identity Federation. It contains these topics:

6.3.8.1 About Affiliations

A Liberty 1.2/SAML 2.0 affiliation consists of service providers that are part of a logical group.

An affiliation is not a concrete entity or server, but a logical provider; thus, no server can act as an affiliation. Rather, service providers use an affiliation when performing protocol message exchanges - in this case, the affiliation will be viewed as a logical provider, but the sender/received of messages for this affiliation will be a concrete service provider. In this way, the service providers participating in the affiliation act as the affiliation, and will have access to all the federation information about that logical provider.

An affiliation is described by an Affiliation Descriptor (also known as metadata for affiliation). It can be viewed as an abstract service provider that interacts with peer identity providers for SSO operations, and with service providers for Web services operations.

For example, consider an affiliation Aff1 consisting of two service providers SP1 and SP2. These two service providers, an identity provider IDP, and the affiliation are contained in a common circle of trust. User ORAUSER has established a federation, FED_IDP_AFF1, between IDP and the affiliation Aff1, the logical provider.

Taking advantage of the affiliation features, SP1 and SP2 - acting through Aff1 - can perform single sign-on operations with IDP, using the FED_IDP_AFF1 federation, even if they do not have any direct federations with IDP. They have access to Aff1's federation information, and IDP views these service providers as Aff1.

The benefits of affiliations lies in reduced number of federations, since the service providers share the same federations. At the same time, this forces the SPs to share their federation information stores, as well as their user data stores, since the federation records are linked to user records.

6.3.8.2 Affiliation Support in Oracle Identity Federation

Oracle Identity Federation provides the following support for affiliations:

  • Oracle Identity Federation, as an IdP, can interact with a service provider which is using an affiliation.

  • Oracle Identity Federation, as an SP, can be part of an affiliation, and can use it to interact with an IdP.

Oracle Identity Federation does not provide any facilities to create and manage affiliations. As such, there is no support for operations like:

  • adding or removing members

  • setting owner and contact information of the affiliation

  • creating metadata for the affiliation

6.3.8.3 Configuring Affiliations

Adding an affiliation to Oracle Identity Federation's circle of trust requires the same steps as adding an IdP or SP metadata to the COT: go to the circle of trust page, and add the affiliation's metadata.

If Oracle Identity Federation is an IdP, in order to interact with service providers that are members of an affiliation, the circle of trust needs to include metadata for both the affiliation and the service provider.

6.3.8.4 Runtime Behavior of Affiliations

The run-time functioning of affiliations depend on whether the Oracle Identity Federation server is acting as an IdP or an SP.

Oracle Identity Federation Acting as IdP

When Oracle Identity Federation is an IdP, provided the affiliation/SP is present and enabled in the circle of trust, the Oracle Identity Federation server is ready to process any requests originating from service providers using the affiliation.

Oracle Identity Federation Acting as SP

As an SP, you can trigger a single sign-on operation with an IdP using an affiliation to which the SP belongs. To do so, just include a federationid query parameter in the URL protected by the IdM back-end, and set the parameter value to the affiliation ID.

For example with an OracleAS Single Sign-On back-end, assuming that a resource is protected by mod_osso and configured for Oracle Identity Federation authentication, requesting the URL of this resource with the federationid query parameter will instruct Oracle Identity Federation to use an affiliation when performing single sign-on with a peer IdP. Here is an example of such a URL:

http://protected_res_host:protected_res_port/path?federationid=http://affiliationid

It is also possible to directly access the http://oif_host:oif_port/fed/sp/initiatesso URL with the same federationid query parameter. In this case, Oracle Identity Federation will trigger a single sign-on operation, and will use the Unsolicited SSO RelayState for the peer IdP as the URL to which the user is redirected after successful authentication.

Note:

The Unsolicited SSO RelayState is set on the Server Configuration -> Circle of Trust -> Edit Trusted Provider page of the Oracle Identity Federation administration console.

6.3.8.5 How Affiliations are Displayed

The Oracle Identity Federation administration console displays, under the Identity Federation tab, federations between the Oracle Identity Federation server and any supported entity type for which metadata is loaded, including federations with affiliations. When listing federations, the server uses these rules to display federations between itself and remote providers or affiliations, depending on the nature of the affiliation:

In the Identity Federation - > Trusted Providers section, the server lists federations between:

  • Oracle Identity Federation server as an IdP and remote SPs from the Service Provider portion of the table

  • Oracle Identity Federation server as an IdP and affiliations from the Affiliation portion of the table

  • Oracle Identity Federation server as an SP and remote IdPs from the Identity Provider portion of the table

However, it will not display federations between remote IdPs and affiliations when this Oracle Identity Federation server acts as an SP and is part of the affiliations.

In the Identity Federation -> Users section, for a specific user, the server lists federations between:

  • Oracle Identity Federation server as an IdP and remote SPs

  • Oracle Identity Federation server as an IdP and affiliations

  • Oracle Identity Federation server as an SP and remote IdPs

  • Affiliations of which this Oracle Identity Federation/SP server is a member, and remote IdPs

6.3.9 Editing the Certificate Validation Store

Use this page to maintain the certificate validation store, which enables you to manage:

  • trusted certificate authorities (CAs)

  • certificate revocation lists (CRLs)

Note:

Certificate validation applies only to the certificates used with the SAML 2.0 and Liberty 1.x protocols, not to SAML 1.x or WS-Federation.
This screen is fully explained in the text.

CA Maintenance Fields

The CA table shows a list of CAs trusted by Oracle Identity Federation. Select a CA and click Remove to delete the CA from the list of trusted CAs.

The CA fields are:

  • Subject - this is the CA certificate subject

  • Issuer - this is the certificate issuer

  • Serial Number - this is the certificate's serial number

  • Valid From - this is the start time of the certificate validity period

  • Valid Until - this is the end time of the certificate validity period

CRL Maintenance Fields

The CRL table shows a list of Certificate Revocation Lists (CRLs) known to Oracle Identity Federation. Select a CRL and click Remove to delete the CRL from the list.

The CRL fields are:

  • Issuer - this is the CA that issued the CRL

  • Valid From - this is the start time of the CRL validity period

  • Valid Until - this is the end time of the CRL validity period

This screen is fully explained in the text.

Add Trusted CA or CRL

Use this field to add either a trusted CA or a CRL location. Use the Browse button to locate an X.509 Certificate or a CRL. X.509 certificates and CRLs can be loaded in DER or PEM format.

Note:

You must be sure that the CA certificates and CRLs are coming from a trusted source, since these files will be used to validate the signatures of the incoming messages.

Certificate Validation Repository

Oracle Identity Federation stores the entries for CAs and CRLs in the XML file $ORACLE_HOME/fed/conf/cacert-store.xml.

CA certificates are stored in Base64 encoded format.

Actions

Click the Done button at the bottom of the page to return to the main Server Configuration page.

6.4 Configuring IdM Data Stores

Use the IdM Data Stores tab to specify information about data stores. From this tab you can access the following pages:

6.4.1 Edit Federation Data Store

Use this page to maintain information about the repository which contains your federation data records. Start by choosing the active repository for the data:

  • Select LDAP Directory if you wish to store the federation records in an LDAP server.

  • Select None (SAML 2.0 only) if Oracle Identity Federation uses only non-opaque SAML 2.0 name identifiers.

Fields available on this page are dynamically determined by the type of repository you select:

Note:

Refer to "Federation Data Store", in the discussion titled "A Note About LDAP Schema" for details on how to configure the LDAP schema.

Federation Data in LDAP Directory

This screen is fully explained in the text.

When the Oracle Identity Federation federation records reside in an LDAP directory, you can specify the following:

Connection URL

This is the LDAP URL to connect to the server. For example,

ldap://ldap.oif.com:389

Bind DN

This is the administrator account DN to use to connect to the LDAP server. For example,

cn=orcladmin

Password

This is the administrator account password to use to connect to the LDAP server.

User Federation Record Context

This is the LDAP container entry under which all the federation records will be stored. For example,

cn=fed,dc=us,dc=oracle,dc=com

Notes:

The User Federation Record Context must be compatible with the LDAP Container Object Class, as explained in the description of that field.

If the User Federation Record Context container object does not exist in the LDAP directory, Oracle Identity Federation will create it at runtime the first time it needs to store a federation record.

LDAP Container Object Class

This is the type of the User Federation Record Context class that Oracle Identity Federation should use when creating the LDAP container, if one does not already exist. If this field is empty, its value will be set to applicationProcess.

Note:

The chosen LDAP container object class must have cn as an attribute, as this is used for federation records created in the container.

For Microsoft Active Directory, this field has to be set (to container for example) depending on the User Federation Record Context since applicationProcess will not work under Microsoft Active Directory.

To see how these fields are related, note that the User Federation Record Context references the LDAP container entry under which federation records will be stored, and the LDAP Container Object Class defines the LDAP container attribute used in the DN. In the User Federation Record Context, you specify the DN of the container where the federation records will be stored. That DN contains the parent of an already existing container, and an attribute of the federation record context that is part of its object class. For example, if the container parent is dc=us,dc=oracle,dc=com and the record context attribute is cn=orclfed, the requirement that cn must be an attribute of the object class set in the LDAP Container Object Class field (or the applicationProcess object class if not set) ultimately produces a DN such as:

cn=orclfed,dc=us,dc=oracle,dc=com

If you choose to express the DN of the Federation Record Context as ou=fed,dc=us,dc=oracle,dc=com, you will need to set the LDAP Container Object Class to an object class that has ou as an attribute, like applicationProcess.

And if the DN is:

cn=fed,dc=us,dc=oracle,dc=com

then the LDAP Container Object Class must define the cn attribute.

Here are examples of the LDAP Container Object Class for different types of directory servers:

  • Oracle Internet Directory: empty

  • Sun Java System Directory Server: empty

  • Microsoft Active Directory: container

Unique Federation ID Attribute

This is the LDAP attribute that Oracle Identity Federation uses to uniquely identify a federation record. If empty, its value will be DN, which is the DN of the LDAP federation record.

Here are examples of the Unique Federation ID Attribute for different types of directory servers:

  • Oracle Internet Directory: empty

  • Sun Java System Directory Server: empty

  • Microsoft Active Directory: empty

Maximum Connections

This is the maximum number of LDAP connections that Oracle Identity Federation will simultaneously open to the LDAP server.

Connection Wait Timeout

This is the timeout, in minutes, to use when Oracle Identity Federation opens a connection to the LDAP server.

No Active Repository (SAML 2.0)

Select None as the Active Repository if:

  1. you do not wish to use an LDAP server to store federation records, and

  2. Oracle Identity Federation will be configured to use federation assertions with non-opaque name identifiers based on the SAML 2.0 profile (email, X.500, Kerberos, or WindowsNameQualifier)

    or

    Oracle Identity Federation will be configured to use only SAML 1.x or WS-Federation

No additional configuration is required for this option.

The buttons at the bottom of the page perform the following functions:

  • Save - saves changes made to federation data store properties.

  • Reset - restores the original values without saving any changes.

6.4.2 Edit User Data Store

Use this page to edit the configuration of the user data store. Oracle Identity Federation uses this information to retrieve user attributes from the data store.

Note:

This information is used to retrieve user attributes, not for authentication.

Fields are displayed dynamically depending on the repository type you choose:

User Data in Oracle Access Manager

This screen is fully explained in the text.

Repository Parameters

Connection URL(s)

This is the LDAP URL to connect to Oracle Access Manager.

Bind DN

This is the administrator account DN to use to connect to Oracle Access Manager.

Password

This is the administrator account password to use to connect to Oracle Access Manager.

User ID Attribute

This is the LDAP attribute used to identify the user during authentication, for example uid.

Here are examples of the User ID Attribute for different types of directory servers:

  • Oracle Internet Directory: uid

  • Sun Java System Directory Server: uid

  • Microsoft Active Directory: sAMAccountName

User Description Attribute

This is the human-readable LDAP attribute used to identify the owner of a federation record, for example uid.

Here are examples of the User Description Attribute for different types of directory servers:

  • Oracle Internet Directory: uid

  • Sun Java System Directory Server: uid

  • Microsoft Active Directory: sAMAccountName

Person Object Class

Object classes define what data or attributes are associated with an object. A person object class refers to the attributes of a "person" object; in our context, it is the owner of a federated identity. A directory may utilize one or more object classes to hold person data (names, addresses, and so on).

Enter the LDAP object class representing an LDAP user entry in the server. For example:

inetOrgPerson

Here are examples of the Person Object Class for different types of directory servers:

  • Oracle Internet Directory: inetOrgPerson

  • Sun Java System Directory Server: inetOrgPerson

  • Microsoft Active Directory: user

Base DN

This is the domain of the LDAP server containing the user records. For example:

dc=us,dc=oracle,dc=com

Maximum Connections

This is the maximum number of LDAP connections that Oracle Identity Federation will simultaneously open to Oracle Access Manager.

Connection Wait Timeout

This is the timeout, in minutes, to use when Oracle Identity Federation opens a connection to Oracle Access Manager.

Oracle Access Manager Configuration Parameters

This screen is fully explained in the text.

Master Admin Login ID

This is the master administrator login. Oracle Identity Federation uses this login to create Oracle Access Manager policy objects related to federation.

Master Admin Password

This is the master administrator password.

Authorization result for unprotected resources

This is the result returned for a SAML 1.x AuthorizationDecisionQuery for a resource that is not protected by an Oracle Access Manager policy. Choices are:

  • Allow

  • Deny

  • Indeterminate

Note:

If you choose Deny, SAML 1.x SSO access to unprotected resources will be blocked. This is equivalent to setting Oracle Access Manager AccessGate Deny On Not Protected to On.

Oracle Access Manager Cookie Domain

This is the domain for which the cookie is valid.

Basic Authentication Scheme Name

This is the name of an authentication scheme using the Basic challenge method, for example, Oracle Access and Identity Basic Over LDAP. This scheme is used in the Fed Domain policy domain.

User Data in OracleAS Single Sign-On

This screen is fully explained in the text.
This screen is fully explained in the text.

Repository Parameters

Oracle Internet Directory is the user data repository for OracleAS Single Sign-On.

Connection URL(s)

This is the LDAP URL to connect to Oracle Internet Directory.

Bind DN

This is the administrator account DN to use to connect to Oracle Internet Directory.

Password

This is the administrator account password to use to connect to Oracle Internet Directory.

User ID Attribute

This is the LDAP attribute used to identify the user during authentication, for example uid.

User Description Attribute

This is the human-readable LDAP attribute used to identify the owner of a federation record. For example:

uid

Person Object Class

Object classes define what data or attributes are associated with an object. A person object class refers to the attributes of a "person" object; in our context, it is the owner of a federated identity. A directory may utilize one or more object classes to hold person data (names, addresses, and so on).

Enter the LDAP object class that represents an LDAP user entry. For example:

inetOrgPerson

Base DN

This is the directory to which the search for users should be confined. For example:

dc=us,dc=oracle,dc=com

Maximum Connections

This is the maximum number of LDAP connections that Oracle Identity Federation will simultaneously open to Oracle Internet Directory.

Connection Wait Timeout

This is the timeout, in minutes, to use when Oracle Identity Federation opens a connection to Oracle Internet Directory.

OracleAS Single Sign-On Parameters

OracleAS Single Sign-On parameters include:

  • Use Oracle SSO - Check this box to use Oracle Single Sign-On as the authentication module.

    Note:

    The Oracle Application Server (on which Oracle Identity Federation server is installed) needs to be associated with the Oracle SSO Server. To do this, go to the OracleAS Enterprise Manager console, then to Infrastructure, and in the Identity Management section, click the Configure button. Refer to the Oracle Application Server Administrator's Guide for details.
  • OSSO Login URL - This is the OracleAS Single Sign-On server URL to present at login. For example:

    http://sso_host:sso_port/sso/auth

  • OSSO Logout URL - This is the OracleAS Single Sign-On server URL to present at logout. For example:

    http://sso_host:sso_port/sso/logout

  • Regenerate OSSO Secret - Click Update to regenerate the key.

User Data in CA eTrust SiteMinder

This screen is fully explained in the text.
This screen is fully explained in the text.

Either an LDAP directory or a relational database can serve as the back-end repository for eTrust SiteMinder.

Note:

When employing eTrust SiteMinder with an RDBMS back-end, you can use Oracle Identity Federation as a service provider similar to the way it is configured as an identity provider. The difference is that when you configure it as a service provider, the RDBMS to use should be the one configured for eTrust SiteMinder.

eTrust SiteMinder with LDAP Directory Data Store

Use these fields to update parameters for communication with a eTrust SiteMinder data store residing in an LDAP directory.

Connection URL(s)

This is the LDAP URL to connect to eTrust SiteMinder.

Bind DN

This is the administrator account DN to use to connect to eTrust SiteMinder.

Password

This is the administrator account password to use to connect to eTrust SiteMinder.

User ID Attribute

This is the LDAP attribute used to identify user during authentication, for example uid.

Here are examples of the User ID Attribute for different types of directory servers:

  • Oracle Internet Directory: uid

  • Sun Java System Directory Server: uid

  • Microsoft Active Directory: sAMAccountName

User Description Attribute

This is the human-readable LDAP attribute used to identify the owner of a federation record, for example uid.

Here are examples of the User Description Attribute for different types of directory servers:

  • Oracle Internet Directory: uid

  • Sun Java System Directory Server: uid

  • Microsoft Active Directory: sAMAccountName

Person Object Class

Object classes define what data or attributes are associated with an object. A person object class refers to the attributes of a "person" object; in our context, it is the owner of a federated identity. A directory may utilize one or more object classes to hold person data (names, addresses, and so on).

Enter the LDAP object class representing an LDAP user entry in the server.

Here are examples of the Person Object Class for different types of directory servers:

  • Oracle Internet Directory: inetOrgPerson

  • Sun Java System Directory Server: inetOrgPerson

  • Microsoft Active Directory: user

Base DN

This is the domain of the LDAP server containing the user records. For example:

dc=us,dc=oracle,dc=com

Maximum Connections

This is the maximum number of LDAP connections that Oracle Identity Federation will simultaneously open to eTrust SiteMinder.

Connection Wait Timeout

This is the timeout, in minutes, to use when Oracle Identity Federation opens a connection to eTrust SiteMinder.

Buttons on this page provide the following domain maintenance features:

  • Update - Presents a second page for eTrust SiteMinder server and agent configuration.

  • Reset - Cancels the operation.

eTrust SiteMinder with Database Data Store

Use these fields to update parameters for communication with an eTrust SiteMinder data store residing in a relational directory.

JNDI Name

This is the EJB JNDI Name of the data source used to locate and authenticate users. For example:

jdbc/RDBMSUserDataSource

User Name

This is the administrator account username used to connect to the database server.

Password

This is the administrator account password to use to connect to the database server.

Login Table

This is the database table of the data source containing the user login information.

Login ID Column

This is the table column containing the user identifier needed to authenticate and locate users.

Login Password Column

This is the table column containing the user's passwords needed for authentication.

Password Digest Algorithm

This is the password digest algorithm to use during authentication to match the password data contained in the password column. Choices are:

  • MD5

  • SHA

  • None

User Description Attribute

This is the database table column containing a human-readable attribute used to identify the owner of a record.

eTrust SiteMinder Connection Data

After you supply eTrust SiteMinder repository parameters, a separate screen collects information used to connect to the policy server and for agent configuration.

This screen is fully explained in the text.

Connection to eTrust SiteMinder Policy Servers

Update eTrust SiteMinder server connection details:

  • Host - This is the host where the policy server is installed.

  • Authorization Port - This is the policy server port used for authentication requests. The default value is 44442.

  • Authentication Port - This is the policy server port used for authentication requests. The default value is 44443.

  • Accounting Port - This is the policy server port used for accounting requests. The default value is 44441.

  • Max Connections - This is the maximum number of agent connections to the policy server.

  • Min Connections - This is the minimum number of agent connections to the policy server.

  • Step Connections - This is the number of connections the agent can open to the policy server at one time.

  • Timeout - This is the time, in seconds, that the agent will wait for a response from the policy server before it returns a failure.

eTrust SiteMinder Agent Configuration

eTrust SiteMinder agents control access to protected resources. Update eTrust SiteMinder agent configuration with these fields:

  • Agent Name - This is the name of the eTrust SiteMinder agent.

  • Agent Secret - This is the password for the pre-existing agent registered with the eTrust SiteMinder policy server.

  • Cookie Domain - This is the cookie domain for the agent.

  • SiteMinder IdMBridge Agent Secret - This is the secret string shared between the agent and the policy server.

Automatic Policy Creation

The eTrust SiteMinder bridge automatically creates the policy objects it requires by logging into eTrust SiteMinder as an administrator. Update these eTrust SiteMinder policy details:

  • Admin ID - This is the eTrust SiteMinder administrator ID.

  • Admin Password - This is the eTrust SiteMinder administrator password.

  • Domain Name - This is the eTrust SiteMinder to contain the policy objects.

  • User Directory - This is the eTrust SiteMinder-configured name of the user directory for the domain.

Assertion Mapping Using a Secondary IdMBridge

If an incoming assertion contains the name of the local eTrust SiteMinder user, it can be used directly. However, if the user name is not supplied in the assertion, a secondary bridge is necessary to map the assertion SubjectName and Attribute values to a user. Provide this information for eTrust SiteMinder assertion mapping:

  • Select Secondary IdMBridge - Specify the type of bridge. Choices are:

    • LDAP Bridge

    • RDBMS Bridge

    • None

  • User Name Attribute in Directory - Enter one of these:

    • For LDAP bridge, enter an attribute in the user's directory entry.

    • For RDBMS Bridge, enter a column in the user database table.

    • For None, specify an attribute from the received assertion.

User Data in LDAP Directory

This screen is fully explained in the text.
This screen is fully explained in the text.

Connection URL(s)

This is the LDAP URL to connect to the LDAP directory.

Bind DN

This is the administrator account DN to use to connect to the LDAP directory.

Password

This is the administrator account password to use to connect to the LDAP directory.

User ID Attribute

This is the LDAP attribute used to identify user during authentication, for example uid.

Here are examples of the User ID Attribute for different types of directory servers:

  • Oracle Internet Directory: uid

  • Sun Java System Directory Server: uid

  • Microsoft Active Directory: sAMAccountName

User Description Attribute

This is the human-readable LDAP attribute used to identify the owner of a federation record, for example uid.

Here are examples of the User Description Attribute for different types of directory servers:

  • Oracle Internet Directory: uid

  • Sun Java System Directory Server: uid

  • Microsoft Active Directory: sAMAccountName

Person Object Class

Object classes define what data or attributes are associated with an object. A person object class refers to the attributes of a "person" object; in our context, it is the owner of a federated identity. A directory may utilize one or more object classes to hold person data (names, addresses, and so on).

Enter the LDAP object class representing an LDAP user entry in the server.

Here are examples of the Person Object Class for different types of directory servers:

  • Oracle Internet Directory: inetOrgPerson

  • Sun Java System Directory Server: inetOrgPerson

  • Microsoft Active Directory: user

Base DN

This is the directory to which the search for users should be confined.

Maximum Connections

This is the maximum number of LDAP connections that Oracle Identity Federation will simultaneously open to the directory.

Connection Wait Timeout

This is the timeout, in minutes, to use when Oracle Identity Federation opens a connection to the directory.

User Data in a Database

See Also:

For details about the tasks required to configure a database, see "Configuring an RDBMS as the User Data Store"
This screen is fully explained in the text.

JNDI Name

This is the EJB JNDI Name of the data source to use to locate and authenticate users. For example:

jdbc/RDBMSUserDataSource

User Name

This is the administrator account username to use to connect to the database server.

Password

This is the administrator account password to use to connect to the database server.

Login Table

The database table of this data source containing the user login information.

Login ID Column

This is the table column containing the user identifier needed to authenticate and locate users.

Login Password Column

This is the table column containing the user's passwords needed for authentication.

Password Digest Algorithm

This is the password digest algorithm to use during authentication to match the password data contained in the password column. Choices are:

  • MD5

  • SHA

  • None

User Description Attribute

This is the database table column containing a human-readable attribute used to identify the owner of a federation record.

6.4.2.1 Configuring an RDBMS as the User Data Store

This section explains how to configure a relational database as the user data store for Oracle Identity Federation.

Note:

If a data source has been already created at the OC4J_FED instance level, skip steps 1 and 2.
  1. Log in to the EM 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:   com.evermind.sql.DriverManagerDataSource
    JDBC URL:            jdbc:oracle:thin:@stahs08.us.oracle.com:1521:ORCL
    JDBC Driver:         oracle.jdbc.driver.OracleDriver
    Username:            CUSTDATA
    Password:            PASSWORD
    Location:            jdbc/RDBMSUserDataSource
    Transactional Loc:   jdbc/xa/RDBMSUserDataSource
    EJB Location:        jdbc/RDBMSUserDataSource
    
    

    Note:

    The database connection information must be updated to reflect your deployment configuration; refer to the Oracle Application Server and Oracle JDBC documentation for more information.

    Apply the changes.

  3. Log into the Oracle Identity Federation administration console and navigate to IdM Data Stores - > User Data Store.

  4. Select 'Database' as the Active Repository and enter the appropriate values, for example:

    JNDI Name:             jdbc/RDBMSUserDataSource
    User Name:             CUSTDATA
    Password:              PASSWORD
    Login Table:           EMPLOYEES
    Login ID Column:       EMPLOYEE_ID
    Login Pwd Column:      USERPASSWORD
    User Desc. Attribute:  EMPLOYEE_ID
    
    

    Note:

    This is an example and is meant to be a guide. For example, you need to substitute the relevant user name for CUSTDATA and so on.

    Save the changes.

  5. Restart the OC4J_FED instance.

6.5 Configuring SAML 1.x and WS-Federation Properties

Use the SAML 1.x/WS-Fed tab to specify configuration details for Oracle Identity Federation SAML 1.x domains.

From SAML 1.x/WS-Fed sub-tabs you can access the following pages:

This section contains these topics:

6.5.1 Certificate Store

Use this page to enter information about the certificate store that Oracle Identity Federation uses for SSL and digital signatures. If you want to use different certificate stores for SSL and digital signatures, click Help.

This figure is explained in surrounding text.

Oracle Identity Federation creates a default key and certificate store, for use with the SAML 1.x and WS-Federation protocols, containing a default self-signed certificate with the shareid alias.

By default, the certificate store is located in the /fed/shareid/oblix/config folder of your Oracle Identity Federation installation directory.

The initial password for this certificate store is the same as the ias_admin password set during Oracle Identity Federation installation. To change the password for this certificate store, first run the keytool utility to change the password for the keystore; then update the password that Oracle Identity Federation uses to access the keystore. The certificate store and key passwords are expected to be the same.

See Also:

For an example ofkeytool utility usage, see "Working with Affiliations"

Path to the certificate store

This is the path to the certificate store.

Signing Key Alias

This is a shorthand name for the signing key.

Certificate Store and Signing Key Password

This is the password that Oracle Identity Federation uses to access the keystore.

Confirm Password

Re-enter the password to confirm the password entry.

Buttons on this page provide the following:

  • Submit - Updates the certificate store information.

  • Reset - Cancels and resets the fields.

6.5.2 Regenerate Encryption Key

The encryption key is used to secure login session cookies and passwords in the Oracle Identity Federation configuration file. For example, one password in the configuration file is used for the certificate store password.

This figure is explained in surrounding text.

To protect your sessions from attacks, you should regularly update the encryption key by clicking the Update button.

6.5.3 Audits and Logs

Use this page to allow Oracle Identity Federation to retain generated and received assertions for auditing.

This figure is explained in surrounding text.

Click Enable Auditing and submit to allow the server to save assertion records.

6.5.4 Assertion Profiles

This page displays the SAML assertion profiles you have defined for your source site. An assertion profile defines the contents of the assertion that is sent to the destination.

This figure explained in text.

Name

This is the assertion profile name.

Description

This is a brief description of the assertion profile.

Buttons on this page provide the following:

  • Add - allows you to add a new assertion profile.

  • Delete - deletes assertions for which the Delete checkbox is marked.

  • Reset - cancels and resets the fields.

6.5.5 Add Assertion Profile

Use this page to add a new assertion profile to use for identity assertions from your source site. An assertion profile defines the contents of the assertion that is sent to the destination.

Basic Profile

This figure explained in text.

Basic profile information includes:

  • the profile name

  • a brief description of the profile

  • the profile issuer

  • the subject name qualifier

  • the subject format; options include email, X509 subject name, windows domain, unspecified, or none

  • user attribute for subject; if blank, the user DN is used

Assertion Attributes

This figure explained in text.

Using the attributes provided by the administrator of the destination domain, provide attribute information for each required attribute. The fields are:

  • Assertion Attribute

  • Attribute in Data Store

  • Name Space

  • Optional Type

  • In SSO Assertions checkbox

  • Allowed Values - These are the permissible values of the attribute.

Assertion Signing

Indicate whether the assertion needs to be signed, and whether to include a certificate in the signature.

For the WS-Federation protocol, the assertion is always signed regardless of the Sign the Assertion setting.

This figure explained in text.

Delimited Data

If you check Data is delimited, Oracle Identity Federation will break an attribute value, retrieved from the user data store that contains the specified delimiter characters, into multiple assertion attribute values. The delimiter character can be escaped by a backslash ("\"). For example, if the delimiter character is ":" and a user data store attribute value is "A:B\:C:D", the assertion will contain three attribute values - "A", "B:C", and "D".

6.5.6 Edit Assertion Profile

Use this page to modify an existing assertion profile.

Basic Profile Information

Basic profile data includes:

  • Assertion Profile Name

  • Description - This is a brief description of the profile.

  • Issuer - This is the profile issuer, for example http://host.company.com.

  • Subject Name Qualifier

  • Subject Format - Choose from Email Address, X.509 Subject Name, Windows Domain, Unspecified, None, and Other.

  • User Attribute for Subject

Add Assertion Attributes to Your Assertion Profile

Use this set of fields to map assertion attributes from a peer site to your data store's user attributes. Attribute mappings include:

  • Assertion Attribute Name

  • Attribute in Data Store - This is the corresponding attribute in your user store.

  • Name Space

  • Optional Type

  • In SSO Assertions - Specify if this attribute is used in SSO assertions.

  • Allowed Values - Enter one or more allowed values (click on the icon to add more values.

Advanced Options

Advanced options include:

  • Assertion Signing - enables you to specify whether and how assertions should be signed.

  • Assertion Validity Period - defines how long, in seconds, the assertion is valid prior to and following generation.

  • Delimited Data - lets you specify whether multi-valued assertion data is delimited, and if so, specify the delimiter character.

Buttons on this page provide the following:

  • Submit - updates the assertion profile with your changes.

  • Reset - cancels and resets the fields.

6.5.7 Destination Mappings

Use this page to view destination mappings, which associate an assertion with a user identity. The mapping allows the destination domain to determine the identity of the local user.

This figure explained in text.

Name

This is the assertion-to-user mapping name. Click on the name to modify its assertion-to-user mappings.

Description

This is a brief description of the assertion mapping.

Buttons on this page provide the following:

  • Add - allows you to add a new assertion mapping.

  • Delete - deletes mappings for which the Delete checkbox is marked.

  • Reset - cancels and resets the fields.

6.5.8 Modify Destination Mappings

Use this page to modify an assertion-to-user destination mapping.

Note:

If you modify the authentication level for a mapping, you must also modify the authentication level of the SASSO mapping to match.
This figure explained in text.

Description

A brief description of the mapping.

Active IdMBridge

Specifies the IdMBridge for the mapping. Valid choices are:

  • Oracle Access Manager IdMBridge

  • eTrust SiteMinder IdMBridge

  • OracleAS Single Sign-On

This figure explained in text.

Use this portion of the page to establish a mapping between an assertion and a local user.

Note:

Mapping an assertion attribute containing multiple values to a local user is not supported.

Assertion Attribute

Use an assertion attribute consistent with the corresponding assertion profile at the source.

Local User Attribute

Enter the corresponding local user attribute.

Terminology Note

Local user mapping, known in the previous release as SmartWalls, was a best practice related to mapping an incoming SSO assertion to a user. The technique was intended to thwart a user from one IdP from impersonating a user from another IdP by falsely asserting attributes for that user.

As a rule, SAML 2.0 and Liberty do not use attribute mapping; instead they use opaque name identifiers that are not susceptible to this problem.

6.5.9 Domains

This is the main page for domain configuration.

This figure explained in text.

Name

This is the domain name.

Description

A brief description of the domain.

Enabled

Indicates if this domain is enabled.

Buttons on this page provide the following domain maintenance features:

  • MyDomain - allows you to configure information about the local Oracle Identity Federation instance.

  • Add Oracle Identity Federation Domain - allows you to easily configure a partner domain that is also using Oracle Identity Federation.

  • Add Non-Oracle Identity Federation Domain - allows you to configure a partner domain using any other SAML 1.x or WS-Federation products.

  • Delete - deletes the domain record(s) indicated in the Delete checkbox.

  • Reset - cancels and resets the fields.

6.5.10 Update MyDomain

Use this page to update MyDomain, which is a local domain configured automatically with every Oracle Identity Federation installation.

Basic MyDomain Information

This figure explained in text.
This figure explained in text.

You can update the following:

  • Enable this Domain - Enables or disables the domain

  • Domain Name - Protected field

  • Issuer

  • Domain Description - A brief description

  • Supported Protocols

    Note:

    If you disable SAML 1.0, SAML 1.1, or WS-Federation, this takes precedence over disabling it in partner domains. Thus, if WS-federation is disabled in MyDomain, then it is disabled for all partners, even if its enabled for some partner domain configurations.
  • Whether MyDomain responds to requests for authorization; if checked, this domain accepts and responds to authorization queries.

  • Enable SmartMarks - Check the box to enable SP-initiated IdP discovery (formerly SmartMarks - details appear in the following paragraph).

  • Error URL - This is the URL to which users are redirected in the event of an error.

  • Transfer URL - This is the redirect URL.

  • Transfer Query String - This is a query string, if any, to be utilized at the transfer URL.

  • Supported Profiles

About SP-initiated IdP Discovery

SmartMarks, a proprietary Oracle technique for SP-initiated SSO with SAML 1.x and Oracle Access Manager, has been superseded in SAML 2.0 with the implementation of the SP-initiated IdP discovery using common domain cookies. While the feature is still applicable in the context of SAML 1.x, from now on it is referred to as SP-initiated IdP discovery..

When a resource - protected by an Oracle Access Manager policy using the "Fed SSO - SAML 1.x" authentication scheme - is accessed by a federated user, Oracle Access Manager redirects the access to Oracle Identity Federation. Oracle Identity Federation then redirects the access to a source site to initiate a SAML 1.x SSO for the resource. To do this, Oracle Identity Federation constructs a redirection URL from the Transfer URL and the Transfer Query String configured for the source site and the target URL. For a source site using Oracle Identity Federation, these are:

Transfer URL = http(s)://source-host:port/shareid/saml/ObSAMLTransferService

Transfer Query String = DOMAIN=dest-domain&METHOD=method&TARGET=

where dest-domain is the domain configured at the source site at the Oracle Identity Federation destination, and the method is post or artifact.

So the entire redirection URL is:

http(s)://source-host:port/shareid/saml/ObSAMLTransferService?DOMAIN=source-domain&TARGET=targetURL

SP-initiated IdP Discovery can also be configured for source sites using other SAML 1.x products, as long as the targetURL is the last part of the redirection URL.

Configure This Domain as a Source/Identity Provider

This figure explained in text.

If users from your domain wish to access resources at other domains, configure MyDomain as an IdP.

You can update the following:

  • Post profile signing certificate subject DN

  • Post profile signing certificate issuer DN

  • Artifact profile responder URL

  • Artifact profile source ID

  • The Identity Realm URI for the WS-Federation Passive Requester Profile

  • The Identity Realm STS URL for the WS-Federation Passive Requester Profile

Configure This Domain as a Destination/Service or Resource Provider

This figure explained in text.

If users from other domains wish to access resources at MyDomain, configure MyDomain as an SP.

You can update the following:

  • Receiver URL

  • Artifact Profile (Basic configuration)

    • Requester ID

    • Requester Password

    • Password Re-entry

  • Artifact Profile (X509 configuration)

    • X.509 Signing Certificate Subject DN

  • WS-Federation Passive Requester Profile

    • The Resource Realm URI

    • The Resource Realm STS URL

Configure this Domain for Loopback Testing

This figure explained in text.

Use these fields to configure MyDomain in loopback mode for testing.

The URL to use for loopback testing is:

http(s)://OIF-host:port/shareid/saml/ObSAMLTransferService?DOMAIN=MyDomain&METHOD=method&TARGET=targetURL

6.5.11 Add Oracle Identity Federation Domain

Use this page to configure a partner domain that is also using Oracle Identity Federation. This page uses default values for most of the domain configuration items based on Oracle Identity Federation conventions. The administrator of the domain must provide you the host and port information. After you submit this page, the Modify Other Domain page will be returned to allow you to modify the domain configuration if needed. In particular, you need to set the Assertion Profile and Assertion Mapping for the domain.

This figure is explained in surrounding text.
This figure is explained in surrounding text.

You can update the following:

  • Domain Name

  • Fully qualified hostname (host and port)

  • Oracle Identity Federation Ports:

    • Open Port

    • SSL Port

    • Client certificate authentication port

Buttons on this page provide the following domain maintenance features:

  • Submit - adds the domain record to the SAML 1.x configuration.

  • Reset - cancels the operation.

6.5.12 Add a Non-Oracle Identity Federation Domain

Use this page to configure an external domain as either an IdP or SP domain. The domain uses a federation server other than Oracle Identity Federation. Besides basic server information, the administrator of the domain must provide you the SAML service URL's.

Basic MyDomain Information

This figure is explained in surrounding text.
This figure is explained in surrounding text.

Provide the following:

  • Enable this Domain - Enables or disables the domain.

  • Domain Name - This is a protected field.

  • Issuer

  • Domain Description - This is a brief description.

  • Supported Protocols

  • Whether the domain responds to requests for authorization

  • Enable SmartMarks

  • Error URL - This is the URL to which users are redirected in the event of an error.

  • Transfer URL - Tis is the redirect URL.

  • Transfer Query String - This is the query string, if any, to be utilized at the transfer URL.

  • Supported Profiles

Configure This Domain as a Source/Identity Provider

This figure is explained in surrounding text.

If users from this domain wish to access resources at your domain, configure the domain as an IdP.

You can update the following, depending on the chosen profile (post, artifact, or WS-Federation):

  • Post profile signing certificate subject DN

  • Post profile signing certificate issuer DN

  • Artifact profile responder URL

  • Artifact profile source ID

  • The Identity Realm URI for the WS-Federation Passive Requester Profile

  • The Identity Realm STS URL for the WS-Federation Passive Requester Profile

Configure This Domain as a Destination/Service or Resource Provider

This figure is explained in surrounding text.

If users from this domain wish to access resources from other domains, configure the domain as an SP.

You can update the following:

  • Receiver URL

  • Artifact Profile (Basic configuration)

    • Requester ID

    • Requester Password

    • Password Re-entry

  • Artifact Profile (X509 configuration)

    • X.509 Signing Certificate Subject DN

  • WS-Federation Passive Requester Profile

    • The Resource Realm URI

    • The Resource Realm STS URL

Configure this Domain for Loopback Testing

This figure is explained in surrounding text.

Use these fields to configure the domain for loopback testing.

6.5.13 Exchanging SAML 1.x and WS-Federation Configuration Data with Peers

Service URLs and related information about Oracle Identity Federation will need to be shared with trusted peers using the SAML 1.x and WS-Federation protocols. The information described here is obtained from the MyDomain configuration page (SAML 1.x/WS-Fed - > Domains - > MyDomain). Use this information if your site's circle of trust contains one or more peer providers, and you need to enter the URL details for an Oracle Identity Federation server.

This section explains how to obtain the service URLs:

6.5.13.1 When Oracle Identity Federation is an IdP

Provide the following configuration data about your Oracle Identity Federation, acting as an identity provider, to the service providers in the circle of trust using SAML 1.x or WS-Federation:

  • Issuer: Oracle Identity Federation actually uses the Issuer defined in the assertion profile associated with the partner domain. This allows different issuers to be used for different partners if necessary, but in practice this flexibility is not needed. To avoid confusion, the best practice is to set the Issuer in all the assertion profiles to the issuer in MyDomain.

  • If the SP is also an Oracle Identity Federation installation, use:

    • Error URL - to use the error redirection feature

    • Transfer URL - to use the SP-initiated SSO or SP-initiated IdP discovery (previously SmartMarks) feature

    • Transfer Query String - to use the SP-initiated SSO feature:

      • DOMAIN=<SP-domain>&METHOD=<method>&TARGET=

      • SP-domain is the name of the domain configured for the SP

      • method is artifact or post

  • If the SAML 1.x Artifact Profile is used:

    • Responder URL - this is the SOAP service to which the SP sends the Artifact request.

    • SourceID - Identifies the IdP to the SP.

  • If the SAML 1.x POST Profile is used:

    • If the SP is also an Oracle Identity Federation server:

      • Signing Certificate Subject DN and Issuer DN (used to verify the signed SAML response in the POST).

    • the SP is another SAML implementation:

      • the certificate used to verify the signed SAML response. The certificate can be exported from the keystore as follows:

        cd ORACLE_HOME/fed/shareid/oblix/config/keystore

        keytool -keystore <keystore> -storepass <ias-password> -export -alias shareid -rfc -file <file>

        ias-password is the administrator password selected when Oracle Identity Federation was installed.

        file is a file to which the certificate is written, in PEM format.

  • If the WS-Federation Passive Requester Profile is used:

    • Identity Realm URI - identifies the IdP to the SP.

    • Identity Realm STS URL - this is the URL to which the SP redirects to obtain a security token.

6.5.13.2 When Oracle Identity Federation is an SP

Provide the following configuration data about your Oracle Identity Federation, acting as a service provider, to the identity providers in the circle of trust using SAML 1.x or WS-Federation:

  • If the SAML 1.x Artifact Profile is used:

    • Receiver URL - this is the URL to which the IdP redirects with the artifact.

    • For IdP authentication of the SP's SOAP Artifact request:

      • If using HTTP basic - Requester ID and Password

      • If using SSL client certificate authentication:

        If the IdP is also Oracle Identity Federation - Signing Certificate Subject DN

        If the IdP is another SAML implementation - the certificate, exported as described above.

  • If the SAML 1.x POST Profile is used:

    • Receiver URL - this is the URL to which the IdP POSTs the SAML response.

  • If the WS-Federation Passive Requester Profile is used:

    • Resource Realm URI - this URI identifies the SP to the IdP.

    • Resource Realm STS URL - this is the URL to which the IdP POSTs the security token.

6.6 Configuring Attribute Sharing

Attribute sharing is a joint feature of Oracle Access Manager and Oracle Identity Federation that implements the SAML Attribute Sharing Profile for X.509 Authentication-Based Systems. In this profile, a user who requests a protected resource or service is authenticated via SSL client X.509 certificates, but authorization is performed with user attributes retrieved from the user's home organization using the SAML protocol. The user's home organization is the identity provider (IdP), and the organization performing authentication and authorization is the service provider (SP).

This section explains how to configure Oracle Access Manager and Oracle Identity Federation for attribute sharing. It contains these topics:

6.6.1 Components Used for Attribute Sharing

Attribute sharing uses several Oracle Access Manager and Oracle Identity Federation components. The instructions assume that these components have been installed and configured for their normal operation.

Service Provider Components

  • Web Server with an Access Manager WebGate - for HTTP requests for a protected URL, performs the SSL client certificate authentication and enforces the access decision from the Oracle Access Manager server.

  • Oracle Access Manager - performs authentication and authorization for the WebGate. Uses these custom plugins for the attribute sharing feature:

    • authz_attribute Authentication Plugin - passes the certificate SubjectDN to the authz_attribute authorization plugin

    • authz_attribute Authorization Plugin - uses the Attribute Requester Service to retrieve attribute values for the user's SubjectDN and evaluates a rule expression with the attribute values to determine if access is allowed

    Note:

    The authentication and authorization plugins use the same authz_attribute library.
  • Oracle Identity Federation Attribute Requester Service - sends a SAML 2.0 attribute query to the IdP Attribute Responder Service determined by the user's SubjectDN, and returns the retrieved attributes to the authz_attribute plugin.

Identity Provider Component

Oracle Identity Federation Attribute Responder Service or other SAML 2.0-compliant federation product - receives a SAML 2.0 attribute query from the SP Attribute Requester Service, retrieves the attributes for the specified user (subject to local policy controls), and returns a response with the attributes to the Attribute Requester Service.

6.6.2 Remote and Local Users

In addition to remote users authorized by SAML attribute retrieval, the protected resource may also be accessed by local users with attributes defined within the service provider Oracle Access Manager user directory. Local users, configured as discussed here, are detected by the authz_attribute authentication plugin, which returns a Failure status. The authentication scheme described later uses this status to create a local session for the user, and authorization rules with local LDAP filters can be applied.

6.6.3 Configuring the Oracle Access Manager Plugins

Take these steps to configure the Oracle Access Manager plugins:

  1. Log in to the Access Server host as the user who installed the Access Server.

  2. Create the directory INSTALLDIR/oblix/config/attributePlugin, if it does not already exist.

  3. Edit or create the config.xml file in the INSTALLDIR/oblix/config/attributePlugin directory, using the sample config.xml file shown here as a template.

  4. Edit the attributes and elements of the config.xml file as required.

  5. Restart the Access Server for changes to take effect.

Sample config.xml File

<Config LogLevel="audit" WaitTime="30" SizeLimit="0" MaxConnections="5" 
  InitialConnections="2"
    Authn="basic" Username="coreid-as-ashost-6021"  Password="xyzzy" 
      KeyPassword="abcde"
    CacheTimeout="3600" MaxCachedUsers="1000" HeaderKeyLength="128" 
      RequestFormat="values">
    <Mapping Local="true">
        <DN>O=Company,C=US</DN>
    </Mapping>
    <Mapping URL="https://fed1.company.com:7777/fed/ar/soap">
        <DN>O=PeerA,C=US</DN>
        <DN>O=PeerB,C=US</DN>
    </Mapping>
    <Mapping URL="https://fed2.company.com:7777/fed/ar/soap" 
      RequestFormat="all">
        <DN>O=PeerC,C=US</DN>
        <DN>O=PeerD,C=US</DN>
    </Mapping>
    <Mapping URL="https://fed3.company.com:7777/fed/ar/soap">
        <DN>C=US</DN>
    </Mapping>
</Config>

Configuration Parameters

The configuration parameters are:

  • LogLevel - Controls the amount of information logged to INSTALL_DIR/oblix/logs/authz_attribute_plugin_log.txt.

    • off - Nothing is logged except errors (this is the default).

    • audit - One line is logged for each authentication request, showing the access decision, the user's certificate subject DN or local directory DN, and the HTTP operation and the local part of the requested URL.

    • debug - Logs extensive information useful in debugging problems.

  • HTTP connection parameters (authz_attribute plugin to the Oracle Identity Federation Attribute Requester Service), consisting of:

    • WaitTime - This is the time in seconds to wait for a response; default is 30 seconds.

    • SizeLimit - This is the maximum size in bytes of HTTP messages sent and received (default is unlimited, 0 means unlimited).

    • MaxConnections - This is the maximum number of concurrent HTTP connections (default is 5).

    • InitialConnections - This is the number of current HTTP connections opened initially (default is 2).

  • Parameters for authentication of the authz_attribute plugin to the Oracle Identity Federation Attribute Requester Service, including:

    • Authn - authentication method

      • none - no authentication

      • basic - use HTTP basic authentication with Username and Password (default)

      • cert - use SSL client certificate authentication using key.pem, cert.pem, and KeyPassword

    • Username - This is the username for basic authentication.

    • Password - This is the password for basic authentication.

    • KeyPassword - This is the password for key.pem for SSL client certificate authentication.

  • Attribute value cache parameters, including:

    • CacheTimeout - This is the time, in seconds, that cached attribute values will be held before requiring updated values (default 3600 seconds - 1 hour; 0 disables caching).

    • MaxCachedUsers - This is the maximum number of users with cached attribute values; if the cache is full, the least recently used unexpired entries will be reclaimed (default is 1000).

  • Mappings of subject DNs to Attribute Requester Service URLs. For each Attribute Requester Service, specify:

    • URL - the URL for the service, of the form %HTTP_PROTOCOL%://%OIF_HOST%:%OIF_PORT%/fed/ar/soap, where:

      • %HTTP_PROTOCOL% - http or https

      • %OIF_HOST%:%OIF_PORT% - This is the host and port of the Oracle Identity Federation server.

      For example: https://fed1.company.com:7777/fed/ar/soap

    • Local - if true, the matching users are local and an Attribute Requester Service is not used. If true, the URL parameter is ignored.

    • DN - one or more elements specifying a DN pattern to match against the user Subject DN; the pattern is simply the right most components of the DN. For example: O=PeerA,C=US.

  • Attribute query properties - The RequestFormat parameter determines the attributes and values returned in an attribute response. RequestFormat overrides authorization rules; for example, if an authorization rule specifies both attributes and values, but RequestFormat specifies names, the query omits values. RequestFormat can be specified with these options:

    • RequestFormat="values"

      The AttributeQuery contains attribute names and values taken from the authorization rule's ruleExpression. The Attribute Responder will only return user attributes and values that are in the AttributeQuery. This is the default setting. This setting minimizes the amount of memory used for cached attribute values (values are only requested when needed for authorization), at the cost of more frequent attribute requests.

    • RequestFormat="names"

      The AttributeQuery contains attribute names but not values taken from the ruleExpression. The Attribute Responder returns all the user's values for the named attributes, subject to any Responder policies controlling access to the attributes values. This setting provides a trade-off between cache memory usage and attribute requests that is somewhere between the "values" and "all" setttings. Note: With this setting, the AttributeQuery does not disclose to the IdP what attribute values are required for authorization; for security reasons, this might be preferred over the "values" setting.

    • RequestFormat="all"

      The AttributeQuery does not contain any attribute names or values. The Attribute Responder returns all the attributes and values for the user subject to any Responder policies controlling access to the attributes values. This setting minimizes the number of attribute requests (only one request per user), at the cost of more memory used for caching attribute values before they are used (and may never be used) for authorization. This setting works best when the Attribute Responder policies have been reasonably configured to return only attributes that the SP might want. Note: With this setting, the AttributeQuery does not disclose to the IdP what attributes are required for authorization; for security reasons, you may prefer this over the "values" and "names" settings.

    As illustrated in the sample config.xml file, the RequestFormat parameter can appear in the <Config> element, where it sets the default request format, and in the <Mapping> elements, where it sets the request format for subject DNs covered by the mappings.

Mapping Examples for the Sample Configuration

Here are some mapping examples for the sample config.xml configuration file shown earlier.

User Subject DN Maps to URL
E=john.smith@company.com,CN=John Smith, OU=Development,O=Company,C=US local
E=betty.jones@peera.com.CN=Betty Jones,OU=Marketing,O=PeerA,C=US https://fed1.company.com:7777/osfs/sp/soap
E=sally.smith@peerd.com,CN=Sally Smith,OU=Marketing,O=PeerD,C=US https://fed2.company.com:7777/osfs/sp/soap
E=bill.jones@peerx.com,CN=Bill Jones,OU=Finance,O=PeerX,C=US https://fed3.company.com:7777/osfs/sp/soap

Configuring SSL and Client Certificate Authentication

Use these steps to configure HTTPS and SSL client certificate authentication:

  1. If HTTPS is used between the authz_attribute plugin and at least one Attribute Requester Service, set up the trusted CA list in INSTALL_DIR/oblix/config/attributePlugin/cacerts.pem. For each CA that certifies an Attribute Requester service, add the PEM formatted certificate (including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----) to cacerts.pem.

  2. If SSL client certificate authentication is used between the authz_attribute plugin and at least one Attribute Requester Service, set up the key.pem and cert.pem files:

    • Generate the private key and certificate request using the openssl utility included with Oracle Access Manager with these steps:

      • cd INSTALL_DIR/oblix/tools/openssl

      • openssl req -config openssl.cnf -newkey rsa:1024 -keyout../../config/attributePlugin/key.pem -out../../config/attributePlugin/req.pem

    • Send INSTALL_DIR/oblix/config/attributePlugin/req.pem to your CA to get a certificate.

    • Copy the generated certificate to INSTALL_DIR/oblix/config/attributePlugin/cert.pem.

  3. Restart the Access Server to ensure that the plugin uses the PEM files.

6.6.4 Configuring Oracle Access Manager Schemes and Policies

This section explains how to configure Oracle Access Manager schemes and policies for Oracle Identity Federation. It contains these sections:

6.6.4.1 Configuring the Attribute Sharing Authentication Scheme

Take these steps:

  1. Log in to the Oracle Access Manager System Console as a Master Access Administrator. Select the Access System Configuration panel and Authentication Management.

  2. Click on Add and fill out the Define a New Authentication Scheme form.

    • Name: OIF Attribute Sharing

    • Description: Performs an SSL client certificate authentication for Oracle Identity Federation Attribute Sharing authorization

    • Level: set based on the requirements of the protected resources; should be higher than any password schemes

    • Challenge Method: X509Cert

    • Challenge Parameter: ssoCookie:Expires=Tue, 1 Nov 2005 00:00:00 GMT

      Note:

      To ensure that this authentication scheme is run on every access to protected resources, this challenge parameter forces the browser to discard the ObSSOCookie which forces Oracle Access Manager to re-authenticate.
    • SSL Required: yes

    • Enabled: no (until the plugins are configured...)

      Click Save and commit the changes.

  3. Select the Plugins tab and click Modify. Add the plugins and parameters shown in the table. To enter built-in plugins, select the plugin name from the drop-down list.To enter custom plugins, select Custom Plugin from the drop-down list and enter the plugin name in the text box. Click on Save when all plugins have been added.

    Plugin Name Type Plugin Parameters
    authz_attribute custom (none)
    cert_decode built-in (none)
    credential_mapping built-in obMappingBase="MAPPING_BASE",obMappingFilter="(uid=OblixAnonymous)"
    credential_mapping built-in obMappingBase="MAPPING_BASE",obMappingFilter="(&(&(objectclass=PERSON_OBJECTCLASS) (USER_ATTRIBUTE=%certSubject.FIELD%))(|(!(obuseraccountcontrol=*))(obuseraccountcontrol=ACTIVATED)))"

    Here is an example:

    Plugin Name Plugin Parameters
    authz_attribute  
    cert_decode  
    credential_mapping obMappingBase="o=Company,c=US", obMappingFilter="(uid=OblixAnonymous)"
    credential_mapping obMappingBase="o=Company,c=US", obMappingFilter="(&(&(objectclass=inetorgperson)(mail=%certSubject.E%)) (|(!(obuseraccountcontrol=*))(obuseraccountcontrol=ACTIVATED)))"

  4. Select the Steps panel. Add the following steps:

    Step Name Active Plugins Purpose
    SubjectDN authz_attribute Extracts SubjectDN from certificate; determines if user is remote or local
    RemoteUser first credential_mapping Creates an anonymous session for a remote user
    LocalUser cert_decode, second credential_mapping Creates a real session for a local user

  5. Select the Authentication Flow panel, click Modify and set the flow shown in the table. Note: The authz_attribute plugin returns Success if the user is remote and Failure if the user is local.

    Step Name Initiating Step On Success Next Step On Failure Next Step
    Default Step no Stop Stop
    SubjectDN yes RemoteUser LocalUser
    RemoteUser no Stop Stop
    LocalUser no Stop Stop

  6. Return to the Steps panel and remove the now-unused Default step.

  7. Return to the General panel and enable the authentication scheme.

6.6.4.2 Configuring the Attribute Sharing Authorization Scheme

Take these steps to configure the attribute sharing authorization scheme:

  1. Log in to the Oracle Access Manager System Console as a Master Access Administrator. Select the Access System Configuration panel and Authorization Management.

  2. Click Add and fill out the Define a new Authorization Scheme form:

    • Name: OIF Attribute Sharing

    • Description: Uses Oracle Identity Federation to obtain attributes for remote users to evaluate the rule expression

    • Shared Library: oblix/lib/authz_attribute

    • Plugin is Managed Code: no

    • Managed Code Name Space: (none)

    • User Parameter: RA_SubjectDN (Note: This uses the "reverse action" feature to obtain the SubjectDN header set by the authz_attribute plugin.)

    • Required Parameter

      • Name: ruleExpression

      • Value: (none) (Note: Each access policy authorization rule will supply the rule expression.)

    • Click Save to commit the changes.

6.6.4.3 Configuring an Oracle Access Manager Policy using Attribute Sharing

Take these steps to configure an Oracle Access Manager policy using the Attribute Sharing profile:

  1. Log in to Oracle Access Manager as a Master or Delegated Access Administrator. Select Create Policy Domain.

  2. Fill out the General panel form:

    • Name: as appropriate (for example, Oracle Identity Federation Attribute Sharing Test)

    • Description: as appropriate

    Click Save.

  3. Select the Resource panel and add one or more resource URL prefixes to protect (for example, /attribute-test).

  4. Select the Authorization Rules panel and add an authorization rule for each set of attributes (represented as a rule expression) required for a remote user.

    • Select Custom Authorization Scheme and click Add.

    • Fill out the authorization rule form and click Save.

      • 1. Name: as appropriate (for example, Peer Marketing VP)

      • 2. Description: as appropriate

      • 3. Authorization Scheme: OIF Attribute Sharing

    • Select the Plugin Parameters panel, click Modify, and set the ruleExpression parameter as specified in the table. Note: White space is allowed around =, !=, &, and |.

      Element Syntax Meaning
      name alphanumeric string including '-', '_', and '.' Name of attribute to request from the user's identity provider
      value one of "string", any, or null Required attribute value. With Oracle COREid Access 7.0.4 the string is restricted to Latin-1 characters. With Oracle Access Manager 10.1.4 and later, the string can contain any Unicode characters. The any value retrieves and matches all values for the attribute. The null value matches a SAML <Attribute> with the xsi:nil="true" attribute.
      comparison name = value, name != value, or (expression) True if the user has/does not have the attribute value
      and-clause comparison & comparison True if both comparisons are true.
      or-clause comparison | comparison True if either comparison is true. & has higher precedence than !.

      Name examples:

      • title = "VP" & function = "Marketing"

      • title = "VP" | title = "Director"

      • title = "VP" & (function = "Marketing" | function = "Finance")

      • title = any & function = any

    • Set any timing conditions or actions as desired for the authorization rule.

    • Return to the General panel and enable the rule.

  5. Select the Authorization Rules panel and add an authorization rule for any local user attributes.

    • Select Oracle Authorization Scheme and click Add.

    • Fill out the authorization rule form:

      • Name: as appropriate (for example, Company Marketing VP).

      • Description: as appropriate

      • Enabled: yes

      • Allow Takes Precedence: no

      Click Save.

    • Select the Allow Access panel, click Modify, and add an LDAP filter for the local attributes. You can use the Query Builder in the Oracle Access Manager Identity User Manager (Configuration -> Delegate Administration -> Build Filter). For example:

      ldap:///o=Company,c=US??sub?(&(title=VP)(function=Marketing))

    • Set any timing conditions or actions as desired for the authorization rule.

    • Return to the General panel and enable the rule.

  6. Select the Default Rules panel and add the default authentication rule:

    • Name: as appropriate

    • Description: as appropriate

    • Authentication Scheme: OIF Attribute Sharing

    Click Save.

  7. Select the Authorization Expression panel and add the default authorization rule:

    • Select the applicable remote authorization rule as defined above and click Add (for example, Peer Marketing VP).

    • If there is a corresponding local authorization rule, select OR and Add the local authorization rule. (for example, Peer Marketing VP | Company Marketing VP).

    Click Save.

  8. Alternatively, you can add policies to the policy domain with authorization expressions for subsets of the protected URLs.

6.6.5 Configuring Oracle Identity Federation as an SP Attribute Requester

Take these steps to configure Oracle Identity Federation as an attribute requester in service provider mode:

  1. Access the Oracle Identity Federation Administration Console at http://sp-hostname:port/fedadmin, with username oif_admin and the password that was set during installation.

  2. Enable the Attribute Requester functionality:

    • Go to the Server Configuration tab and select the Service Provider section

    • Click on SAML 2.0 to edit SAML 2.0 Service Provider Properties

    • Check Attribute Requester Enabled

    • Click Save

  3. Add the SAML 2.0 IdP metadata to the Circle Of Trust:

    • Go to the Server Configuration section.

    • Select the Circle of Trust section

    • Enter the location of the SAML 2.0 IdP metadata in the Add Trusted Provider section and an additional description

    • Click Add

  4. Configure the DN to IdP mapping:

    • Click on the Server Configuration tab and go to the Service Provider section

      Go to Attribute Requester.

    • To add a mapping:

      • Click Add Mapping

      • Enter the DN or sub-DN (for example, c=us)

      • Map this DN or sub-DN to an existing IdP

      • Repeat the operation if necessary

    • Click Apply

    • Click Refresh Server

  5. Enable Certificate Validation:

    • Go to the Server Configuration section

    • Click Certificate Validation Enabled. (Note: Setting a property on this page requires a server restart)

    • Go to the Enterprise Manager Console, with the username ias_admin and the password that was set up during installation

    • Select OC4J_FED in the System Components

    • Click Restart

      Note:

      Certificate validation is optional.
  6. Configure Certificate Validation:

    • Go to the Server Configuration section.

    • Select the Certificate Validation section.

    • Add Trusted CAs or CRLs. (Note: if Certificate Validation is enabled, a Trusted CA is required to validate signatures).

    • Click Done.

    • Click Refresh Server.

      Note:

      Certificate validation is optional.
  7. Enable Encryption:

    • Go to the Server Configuration section.

    • Select the Service Provider section and select the SAML 2.0 section.

    • Check Send Encrypted NameIDs to encrypt the Name Identifiers in the AttributeQuery to the Attribute Responder.

      Note:

      Encryption is optional.
    • Check Send Encrypted Attributes to encrypt the Attributes in the AttributeQuery to the Attribute Responder.

    • Click Save.

    • Click Refresh Server.

  8. The Attribute Requester service is available at http://sp-hostname:port/fed/ar/soap.

6.6.5.1 If Using Basic Authentication

If using basic authentication between the plug-in and Oracle Identity Federation, you need to add the following to the httpd.conf file of the OHS server for your Oracle Identity Federation instance:

<LocationMatch "/fed/ar/soap">
    AllowOverride None
    AuthType Basic
    AuthName "Restricted Files"
    AuthUserFile /private/oifpassword
    Require user alice
    Order allow,deny
    Allow from all
</LocationMatch>

A user passwords file must also be created using the htpasswd utility. In the above example, the AuthUserFile containing the users and their passwords points to the /private/oifpassword file, in which the user alice is defined.

This example creates such a file by adding the user alice:

Apache/Apache/bin/htpasswd -c /private/oifpassword alice

6.6.5.2 If Using Client Certificate Authentication

If using client certificate authentication, see "Configuring SSL Server on Oracle Identity Federation".

6.6.6 Configuring Oracle Identity Federation as an IdP Attribute Responder

Use these steps to configure Oracle Identity Federation as an attribute responder in IdP mode:

  1. Save the SAML 2.0 SP Metadata:

    • Go to URL http://sp-hostname:port/fed/sp/metadatav20.

    • Save the XML file to the local disk.

    Note:

    The metadata URL applies only if the SP is using Oracle Identity Federation. If the SP is using some other SAML implementation, the process of obtaining the metadata will be determined by that implementation.
  2. Access the Oracle Identity Federation Administration Console at http://sp-hostname:port/fedadmin, with username oif_admin and the password that was set during installation.

  3. Enable the Attribute Responder functionality:

    • Go to the Server Configuration tab, select the Identity Provider section and select the SAML 2.0 section to edit SAML 2.0 IdP properties.

    • Check Attribute Responder Enabled.

    • Click Save.

  4. Map the X.509 Name ID:

    • Go to the Server Configuration section.

    • Select the Identity Provider section and select the SAML 2.0 section.

    • Click on Assertion NameID Formats.

    • Check that the X.509 Subject Name is enabled and mapped to the correct user entry attribute from the user repository:

      • Use dn to map the X.509 Subject Name to an entry's Distinguished Name, or

      • use any attribute from a user entry

      Note:

      The attribute selected for the X509 Subject Name must exactly match the client certificate subject DN, following the format specified in RFC 2253. If unsure of the format, you can perform a test with the SP and look at the Subject NameIdentifier value sent from the SP, which is logged in ORACLE_HOME/fed/log/federation-msg.log.
    • Click Apply.

    • Click Save on the Edit SAML 2.0 Identity Provider Properties page.

    • Click Refresh Server.

  5. Add the SAML 2.0 SP metadata to the Circle Of Trust:

    • Go to the Server Configuration tab.

    • Select the Circle of Trust section.

    • Enter the location of the SAML 2.0 SP metadata in the Add Trusted Provider section and enter an additional description.

    • Click Add.

  6. Configure the Attribute Mappings for the SP Attribute Requester:

    • Go to the Server Configuration section.

    • Select the Circle of Trust section.

    • Select the SP Attribute Requester entry and click Update.

    • Click on Attribute Mappings.

    • To add attribute mapping:

      • Click Add Another Row.

      • Enter the user repository attribute name in the User Attr Name column.

      • In Assertion Attr Name, enter the identifier used in the AttributeQuery or Assertion to reference the attribute.

      • Leave the Format or Namespace column empty for SAML 2.0.

      • Repeat the operation to add other attribute mappings.

    • Click Apply.

    • Click Apply on the Edit Trusted Provider page.

    • Click Refresh Server.

    Note:

    For an SP using Oracle Identity Federation, the Assertion Attr Name is determined by the attribute name in a ruleExpression as set in "Configuring an Oracle Access Manager Policy using Attribute Sharing". The attribute names must be agreed upon between the IdP and SP.
  7. Enable Certificate Validation:

    • Go to the Server Configuration section.

    • Click Certificate Validation Enabled. (Note: Setting a property on this page requires a server restart).

    • Go to the Enterprise Manager Console, with the username ias_admin and the password that was set up during installation.

    • Select OC4J_FED in the System Components.

    • Click Restart.

    Note:

    Certificate validation is optional.
  8. Enable Encryption:

    • Go to the Server Configuration section.

    • Select the Identity Provider section and select the SAML 2.0 section.

    • Check Send Encrypted NameIDs to encrypt the name identifiers in the response to the attribute requester.

    • Check Send Encrypted Attributes to encrypt the attributes in the response to the attribute requester.

    • Check Send Encrypted Assertions to encrypt the assertion in the response to the attribute requester.

    • Click Save.

    • Click Refresh Server.

    Note:

    Encryption is optional.

6.6.7 Configuring Oracle Identity Federation for SSL

To configure SSL on the Oracle Application Server, refer to "Using SSL with Oracle Identity Federation"

6.7 Web Services Interface for Attribute Sharing

This section describes the Oracle Identity Federation's Attribute Requester Service Interface. It contains these topics:

6.7.1 Overview of the Service Interface

The Attribute Requester Service provides a request/response interface using the SOAP POST protocol. The service supports the X.509 authn-based attribute sharing profile and follows the SAML 2.0 <AttributeQuery> convention.

The service can be invoked to send samlp:AttributeQuery messages to a remote identity provider.

Here are the steps that are exercised when the web service client sends an AttributeRequest to the Oracle Identity Federation/Attribute Requester server:

  1. The web service client sends an AttributeRequest message using the SOAP protocol.

  2. Oracle Identity Federation processes the incoming AttributeRequest message, and selects the IdP to which to send the SAML 2 AttributeQuery, based on the Subject contained in the AttributeRequest.

  3. Oracle Identity Federation applies, for the specific remote IdP, the atttribute value mapping for the optional attribute values listed in the AttributeRequest.

  4. Oracle Identity Federation applies, for the specific remote IdP, the atttribute name mapping for the optional attribute listed in the AttributeRequest.

  5. Oracle Identity Federation sends the AttributeQuery to the remote IdP.

  6. Oracle Identity Federation receives the response containing the assertion, along with the attributes sent by the IdP.

  7. Oracle Identity Federation applies, for the specific remote IdP, the attribute name mapping for the attribute names listed in the assertion's AttributeStatement.

  8. Oracle Identity Federation applies, for the specific remote IdP, the attribute value mapping for the attribute values listed in the assertion's AttributeStatement.

  9. Oracle Identity Federation builds the AttributeResponse message, and returns it to the web service client in a SOAP response message.

6.7.2 Attribute Request Message

The AttributeRequest message issues a request for attribute data about a user.

The AttributeRequest specifies these inputs:

  • The user's SubjectDN. This is a required input.

  • Zero or more names of attributes to be retrieved for the user.

The AttributeRequest message is wrapped in a SOAP Envelope and Body and sent in an HTTP POST request. The message structure is:

<SOAP-ENV:Envelope 
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Body>
      <orafed-arxs:AttributeRequest xmlns:orafed-arxs="http://www.oracle.com/fed/ar/10gR3">
         <orafed-arxs:Subject>cn=alice,cn=users,dc=us,dc=oracle,dc=com
         </orafed-arxs:Subject>
         <orafed-arxs:Attribute Name="mail">
            <orafed-arxs:Value>alice@oracle.com</orafed-arxs:Value>
            <orafed-arxs:Value>bob@oracle.com</orafed-arxs:Value>
         </orafed-arxs:Attribute>
         <orafed-arxs:Attribute Name="firstname">
            <orafed-arxs:Value>Bobby</orafed-arxs:Value>
            <orafed-arxs:Value>Charles</orafed-arxs:Value>
         </orafed-arxs:Attribute>
         <orafed-arxs:Attribute Name="lastname">
         </orafed-arxs:Attribute>
      </orafed-arxs:AttributeRequest>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The output rules are as follows:

  • Following the SAML 2.0 <AttributeQuery> convention, if no attributes are named, all of the user's attributes are returned.

  • If one or more attributes are named in the request, only these are returned.

  • Attributes are returned subject to the responder's local policy.

6.7.3 Attribute Response Message

The Attribute Requester service returns the AttributeResponse message to a SOAP client following an attribute request.

Outputs of AttributeResponse include:

  • the status of the SAML 2.0 query (Success or Failure, with the reason)

    The client can use this information for logging.

  • the SubjectDN of the user

  • zero or more <Attribute> elements, with each element supplying an attribute name and zero or more values

Note the following about returned attribute values:

  • All values are UTF-8 strings.

  • Following the SAML 2.0 AttributeQuery convention, if the requestor is not allowed to see any values for an attribute, the Attribute element will be returned with no Value elements.

  • An attribute value of NULL is represented by <Value Null="true"/>.

  • The CacheFor attribute in the AttributeResponse message specifies how long the attribute values can be cached.

The AttributeResponse message is wrapped in a SOAP Envelope and Body and returned in an HTTP 200 OK response. The message structure is:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
      <orafed-arxs:AttributeResponse       xmlns:orafed-arxs="http://www.oracle.com/fed/ar/10gR3" CacheFor="1199">
         <orafed-arxs:Status>Success</orafed-arxs:Status>
         <orafed-arxs:Subject>cn=alice,cn=users,dc=us,dc=oracle,dc=com
         </orafed-arxs:Subject>
         <orafed-arxs:Attribute Name="sn">
            <orafed-arxs:Value>Appleton</orafed-arxs:Value>
         </orafed-arxs:Attribute>
         <orafed-arxs:Attribute Name="givenname"></orafed-arxs:Attribute>
         <orafed-arxs:Attribute Name="mail">
            <orafed-arxs:Value>alice@oracle.com</orafed-arxs:Value>
         </orafed-arxs:Attribute>
      </orafed-arxs:AttributeResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

6.7.4 Interface WSDL

The WSDL that formally defines the Attribute Requester Service interface is as follows:

<?xml version ="1.0" encoding="US-ASCII" ?>
<wsdl:definitions name="AttributeRequesterFed" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
                    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                    xmlns:xml="http://www.w3.org/XML/1998/namespace"
                    xmlns:orafed-arxs="http://www.oracle.com/fed/ar/10gR3"
                    xmlns:orafed-arwsdl="http://www.oracle.com/fed/ar/wsdl"
                    targetNamespace="http://www.oracle.com/fed/ar/wsdl">
        <wsdl:types>
                <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
                        targetNamespace="http://www.oracle.com/fed/ar/10gR3"
                        elementFormDefault="qualified"
                        attributeFormDefault="unqualified">
                        <xs:element name="Subject" type="xs:string"/>
 
                        <xs:complexType name="ValueType">
                            <xs:simpleContent>
                                <xs:extension base="xs:string">
                                    <xs:attribute name="Null" type="xs:boolean"/>
                                </xs:extension>
                            </xs:simpleContent>
                        </xs:complexType>
                        <xs:element name="Value" type="orafed-arxs:ValueType"/>
 
                        <xs:complexType name="AttributeType">
                                <xs:sequence>
                                        <xs:element ref="orafed-arxs:Value" minOccurs="0" maxOccurs="unbounded"/>
                                </xs:sequence>
                                <xs:attribute name="Name" type="xs:ID"/>
                        </xs:complexType>
                        <xs:element name="Attribute" type="orafed-arxs:AttributeType"/>
 
                        <xs:complexType name="AttributeRequestType">
                                <xs:sequence>
                                        <xs:element ref="orafed-arxs:Subject"/>
                                        <xs:element ref="orafed-arxs:Attribute" minOccurs="0" maxOccurs="unbounded"/>
                                </xs:sequence>
                        </xs:complexType>
                        <xs:element name="AttributeRequest" type="orafed-arxs:AttributeRequestType"/>
 
                        <xs:complexType name="AttributeResponseType">
                                <xs:sequence>
                                        <xs:element name="Status" type="xs:string"/>
                                        <xs:element ref="orafed-arxs:Subject"/>
                                        <xs:element ref="orafed-arxs:Attribute" minOccurs="0" maxOccurs="unbounded"/>
                                </xs:sequence>
                                <xs:attribute name="CacheFor" type="xs:unsignedInt"/>
                        </xs:complexType>
                        <xs:element name="AttributeResponse" type="orafed-arxs:AttributeResponseType"/>
                </xs:schema>
        </wsdl:types>
 
        <wsdl:message name="AttributeRequestMessage">
                <wsdl:part name="body" element="orafed-arxs:AttributeRequest"/>
        </wsdl:message>
 
        <wsdl:message name="AttributeResponseMessage">
                <wsdl:part name="body" element="orafed-arxs:AttributeResponse"/>
        </wsdl:message>
 
        <wsdl:portType name="AttributeRequesterServicePortType">
                <wsdl:operation name="AttributeRequestOp">
                        <wsdl:input message="orafed-arwsdl:AttributeRequestMessage"/>
                        <wsdl:output message="orafed-arwsdl:AttributeResponseMessage"/>
                </wsdl:operation>
        </wsdl:portType>
 
        <wsdl:binding name="AttributeRequesterServiceBinding" type="orafed-arwsdl:AttributeRequesterServicePortType">
                <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
                <wsdl:operation name="AttributeRequestOp">
                        <soap:operation soapAction="http://www.oracle.com/fed/AttributeRequestOp" />
                        <wsdl:input>
                                <soap:body use="literal"/>
                        </wsdl:input>
                        <wsdl:output>
                                <soap:body use="literal"/>
                        </wsdl:output>
                </wsdl:operation>
        </wsdl:binding>
 
        <wsdl:service name="AttributeRequesterService"> 
                <wsdl:port name="AttributeRequesterServicePort"
                           binding="orafed-arwsdl:AttributeRequesterServiceBinding">
                        <soap:address location="http://stadm04.us.oracle.com:7778/fed/ar/soap"/>
                </wsdl:port>
        </wsdl:service>
</wsdl:definitions>

The types and message sections define the contents of the AttributeRequest and AttributeResponse messages.

The built-in XML Scheme type ID is used for the Name attribute of the Attribute elements; this type approximates the desired syntax for attribute names (letters, numbers, '"_", "-", and ".") However, ID (which is derived from the XML NCName type) also includes a number of Unicode combining characters and extenders.

See Also:

The W3C specification, Namespaces in XML, at http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName.

The binding and service sections specify how the messages are to be sent over SOAP and HTTP(S).

6.7.5 References

See http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html for a summary of regular-expression constructs.

6.8 Configuring Attribute Mapping

This section explains how to configure the attribute mapping functionality in Oracle Identity Federation. It contains these topics:

See Also:

See http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html for a summary of regular-expression constructs.

6.8.1 Introduction to Attribute Mapping

Oracle Identity Federation supports attribute mapping for the following:

  • SAML 2.0 Attribute Authority

  • SAML 2.0 Attribute Requester

  • Liberty 1.x/ SAML 2.0 Identity Provider, when sending attributes in SSO assertions

Oracle Identity Federation provides the following attribute mapping capabilities:

  • Attribute Name Mapping: maps local attribute names to external attribute names used in Liberty/SAML messages

  • Attribute Value Mapping: maps local attribute values to external attribute values used in Liberty/SAML messages

  • Attribute Value Filtering: filters local attribute values by sending only allowed values in assertion messages

Note:

In this release, all attribute mapping and filtering is available only as per-peer-provider configuration, not at the global level.

6.8.1.1 Attribute Name Mapping

Attribute name mapping allows the administrator to specify the name with which a local attribute should be defined in the Liberty/SAML messages when sending or receiving messages.

On the IdP/Attribute Authority side, when a mapping is defined, Oracle Identity Federation can also be configured to send the attribute to a specific peer provider. Thus, when no name mappings are defined, Oracle Identity Federation is configured to send no attributes to peer providers.

Oracle Identity Federation exercises attribute name mapping when acting as a:

  • SAML 2.0 Attribute Authority

  • SAML 2.0 Attribute Requester

  • Liberty 1.x/SAML 2.0 Identity Provider, when sending attributes in SSO Assertions

Attribute name mapping is configured through the Oracle Identity Federation Administration Console. See "Attribute Name Mapping" for details.

6.8.1.2 Attribute Value Mapping

Attribute value mapping allows the administrator to specify the value that a local attribute should be assigned in a Liberty/SAML message when sending or receiving messages.

Attribute value mapping has these characteristics:

  • A value mapping consists of a combination, or duet, of a local value and the corresponding external value.

  • Value mappings can be defined for any local attributes. Multiple value mappings can be defined for each local attribute.

  • Different external values can be mapped to the same local value using value mappings. A default attribute is used to determine which external value will be used in outgoing mode.

  • Different local values can be mapped to the same external value by means of value mappings. A default attribute is used to determine which local value to use in incoming mode when mapping external values into local values.

Oracle Identity Federation exercises attribute value mapping when acting as a:

  • SAML 2.0 Attribute Authority

  • SAML 2.0 Attribute Requester

  • Liberty 1.x/SAML 2.0 Identity Provider, when sending attributes in SSO Assertions

Configuration involves manually editing an XML file. See "Attribute Value Mapping" for more details.

6.8.1.3 Attribute Value Filtering

Attribute value filtering allows the administrator to specify which local value is allowed when sending a Liberty/SAML message.

Attribute value filtering has these characteristics:

  • Filter rules can be defined for any local attributes. A filter rule evaluates each attribute value to determine if it can be sent. If the evaluation is positive, the value is sent; otherwise, it is removed from the list of attribute values to be sent.

  • Multiple filter rules can be defined for each local attribute. When sending a value, Oracle Identity Federation can be set up to either:

    • send only after all filters evaluate successfully

    • send if at least one filter evaluates successfully

  • The administrator defines a filtering rule by specifying the type of comparison, and the string value to compare (see "Attribute Value Filtering").

  • Oracle Identity Federation supports these comparison types when comparing the attribute value to a string:

    • equals

    • not equals

    • starts with

    • ends with

    • contains

    • does not contain

    • equals null

    • not equals null

  • In addition to these comparison types, filtering supports regular expressions, allowing the user to match the attribute value against a regular expression. See "Filtering Conditions" in the section "Attribute Value Filtering" for details.

  • The filtering rules allow you to specify whether the comparison will be case-sensitive.

Oracle Identity Federation exercises attribute value filtering when acting as a:

  • SAML 2.0 Attribute Authority

  • Liberty 1.x/SAML 2.0 Identity Provider, when sending attributes in SSO Assertions

Configuration involves manually editing an XML file. See "Attribute Value Filtering" for details.

6.8.2 Mapping Configuration

This section provides details about configuring the attribute mapping features of Oracle Identity Federation. It contains these topics:

6.8.2.1 Configuration Files

Configuration information for Oracle Identity Federation attribute sharing features is stored in two different files:

  • The $ORACLE_HOME/fed/conf/cot.xml file contains configuration data for attribute name mapping.

  • The $ORACLE_HOME/fed/conf/attr-config.xml file contains configuration data for attribute value mapping and filtering.

6.8.2.1.1 cot.xml

The cot.xml file contains the Circle Of Trust configuration information that Oracle Identity Federation uses to interact with peer providers.

This file is managed by the Oracle Identity Federation Administration Console and must not be manually edited.

6.8.2.1.2 attr-config.xml

The attr-config.xml file was specifically created to hold configuration data for the attribute value mapping and filtering support in Oracle Identity Federation.

This file is not managed by the Oracle Identity Federation Administration Console. The administrator must edit it manually to configure attribute value mapping and filtering. For details on how to configure the Attribute Sharing framework in Oracle Identity Federation, see "Server Configuration".

Note:

The $ORACLE_HOME/fed/conf/attr-config.xml file is not present by default in the Oracle Identity Federation installation. The administrator needs to create it manually. See "XML File Structure" and "Server Configuration" below for details about the structure of this file.

The procedure for using this file depends on whether the transient data is stored in an RDBMS or in memory.

RDBMS Transient Store

When the Oracle Identity Federation transient data store is of RDBMS type (that is, user session information is stored in a database), Oracle Identity Federation uses the RDBMS to store its configuration data. Thus, in a clustered environment, Oracle Identity Federation servers using a common database will share the same configuration without the need to manually copy configuration files to propagate any changes.

All changes made through the Oracle Identity Federation Administration Console are persisted to the RDBMS, and will in turn be picked up by any Oracle Identity Federation server using the RDBMS as its configuration repository.

When manual changes are made to the attr-config.xml file, the data is not automatically persisted to the database. Take these steps to ensure the changes are reflected in the database:

  1. Open the $ORACLE_HOME/fed/config/attr-config.xml file.

  2. Locate the top root XML element, which is called AttributeConfig.

  3. Set the value of the useLocalConfig attribute of the AttributeConfig XML element to true. That forces Oracle Identity Federation to persist the local attr-config.xml file to the database during the next restart, and the boolean flag is reset to false.

  4. Save and exit the file.

  5. Restart the OC4J_FED container of the machine where the attr-config.xml file was modified.

After these steps are performed, the local content of the attr-config.xml file are propagated to the RDBMS, and to all Oracle Identity Federation servers using this database to store their configuration information.

In-memory Transient Store

When the Oracle Identity Federation transient data store is of type memory, the configuration data is stored entirely in local files.

When performing manual changes to the attr-config.xml file, it is only necessary to force a refresh of the Oracle Identity Federation server to pick up the new changes.

To refresh the server:

  1. Perform changes to the attr-config.xml file, and save the file.

  2. Go to the Oracle Identity Federation Administration Console.

  3. Click on the Refresh Server button. This forces the standalone Oracle Identity Federation server to reload its configuration based on the files.

XML File Structure

To set up attribute value mapping, the administrator manually edits the $ORACLE_HOME/fed/conf/attr-config.xml file. This XML file has a generic structure, as it defines the configuration information for attribute value mapping and attribute value filtering on a per-provider basis.

Note:

See "Sample attr-config.xml File" below for an example of the attr-config.xml file.

The structure of the attr-config.xml file is as follows:

AttributeConfig is the top XML root element. It contains:

  • useLocalConfig attribute: Boolean to indicate whether the local file's content should overwrite the RDBMS configuration entry when Oracle Identity Federation uses RDBMS as its transient data store. See "RDBMS Transient Store" above for more information on this attribute.

  • PeerProvider child elements: These XML elements appear as children of AttributeConfig and represent configuration information for a specific provider.

PeerProvider XML element represents the attribute value mapping and filtering for a specific peer provider. It contains:

  • providerID attribute: Defines the identifier used to reference the Peer Provider. This value must equal the value used in the Circle Of Trust to reference the Peer Provider.

  • PropertyGroup child elements: Represent a list of specific configuration entries. These are the only children of the PeerProvider XML element.

PropertyGroup XML element is a list of specific configuration entries, such as configuration data for attribute value mapping, and configuration information for attribute value filtering. It contains:

  • name attribute: The name of the PropertyGroup XML element configuration group.

  • PropertyGroupItem child elements: Represent configuration entries in the list defined by the PropertyGroup parent. These are the only children of the PropertyGroup XML element.

PropertyGroupItem XML element: Represents a configuration entry in the list defined by the PropertyGroup parent. For example, when the PropertyGroup parent represents configuration for attribute value filtering, the PropertyGroupItem XML element will contain filtering configuration information for one specific local attribute. It contains:

  • Property child elements: Simple name-value pair properties attached to the PropertyGroupItem parent.

  • PropertiesList child elements: Represent groups of name-value pair properties.

Property XML element: A simple name-value pair property. It contains:

  • name attribute: The name of the property

  • XML text child: The value of the property

PropertiesList XML element: Represents multiple groups of name-value pair properties. It contains:

  • name attribute: The name of the PropertiesList element.

  • PropertiesListItem child elements: Each child represents a group of name-value pair properties.

PropertiesListItem XML element: A group of name-value pair properties. For example, when the PropertyGroup parent represents configuration for attribute value filtering, the PropertyGroupItem XML element will contain filtering configuration information for one specific local attribute, the PropertiesList XML element will contain the mapping configuration information for that specific attribute, and a PropertiesListItem XML element will contain information for one mapping for that specific attribute.

The element consists of:

6.8.2.2 Server Configuration

We now describe how to configure Oracle Identity Federation to:

  • act as an Attribute Authority

  • act as an Attribute Requester

  • send attributes in SSO Assertions

6.8.2.2.1 Configuring Oracle Identity Federation as Attribute Authority

Take these steps to configure Oracle Identity Federation to act as an attribute authority:

  1. Go to the Oracle Identity Federation Administration Console.

  2. Go to Server Configuration -> Identity Provider -> SAML 2.0.

  3. Check the Attribute Responder Enabled box.

  4. Save and refresh the server.

Checking the Attribute Responder Enabled box enables the attribute authority feature. It also modifies the IdP's metadata to include information about the attribute authority service. Note that the metadata at the peer providers' sites must be updated with the new version.

After enabling the attribute responder capability, you must configure:

  • which attributes to send

  • the attribute name mapping

  • the attribute value mappings

  • the attribute value filters

See"Mapping & Filtering Configuration" for more information.

6.8.2.2.2 Configuring Oracle Identity Federation as Attribute Requester

Take these steps to configure Oracle Identity Federation to act as an attribute requester:

  1. Go to the Oracle Identity Federation Administration Console.

  2. Go to Server Configuration -> Service Provider -> SAML 2.0.

  3. Check the Attribute Requester Enabled box.

  4. Save and refresh the server.

When Oracle Identity Federation acting as an attribute requester receives a request that will trigger an attribute exchange flow (by means of an attribute query from a Service Provider to attribute authority, and assertion from attribute authority to SP), the request will contain the DN identifying the user for which the attributes need to be retrieved.

Oracle Identity Federation can query a specific attribute authority based on the user's DN. Take these steps to configure this feature:

  1. Go to the Oracle Identity Federation Administration Console.

  2. Go to Server Configuration -> Service Provider -> Attribute Requester.

  3. Enter a sub-DN, and select the attribute authority where a request will be sent with a DN matching the sub-DN.

  4. Save and refresh the server.

See "Service Provider - Attribute Requester" for more details.

If no matches can be found for the user's DN, the Default SSO IdP is used.

To configure the default SSO IdP:

  1. Go to the Oracle Identity Federation Administration Console.

  2. Go to Server Configuration -> Service Provider.

  3. Select the Default SSO IdP from the drop down list.

  4. Save and refresh the server.

After enabling the attribute requester capabilities and setting up the Default SSO IdP and/or the DN Mappings, you must configure the attribute name mapping and the attribute value mappings. See "Mapping & Filtering Configuration" for more information.

6.8.2.2.3 Sending Attributes in SSO Assertion

During a Single Sign-On operation, the IdP can optionally include attributes in the authentication assertion to be consumed by the Service Provider.

Take these steps to enable attributes to be sent in an assertion:

  1. Go to the Oracle Identity Federation Administration Console.

  2. Go to Server Configuration -> Circle Of Trust.

  3. Select the peer provider with which you want to configure attribute sharing, and click the Update button.

  4. Check the Enable Attributes in SSO box.

  5. Click Apply.

After checking the Enable Attributes in SSO box, you need to configure

  • the attributes to send

  • the attribute name mapping

  • the attribute value mappings

  • the attribute value filters

See "Mapping & Filtering Configuration" for more information.

6.8.2.3 Mapping & Filtering Configuration

This section explains how to configure mapping and filtering.

6.8.2.3.1 Attribute Name Mapping

Attribute name mapping is configured at the Circle Of Trust page of the Oracle Identity Federation Administration Console. This configuration serves two purposes:

  • to map attributes names contained in an assertion to local attribute names on the IdP

  • to define which local attributes can be sent to the peer provider. This means that defining an attribute name mapping for a peer provider will authorize Oracle Identity Federation to send this attribute to the remote server.

Take these steps to define an attribute name mapping, or to enable an attribute to be sent, on the IdP side:

  1. Go to the Oracle Identity Federation Administration Console.

  2. Go to Server Configuration -> Circle Of Trust.

  3. Select the peer provider with which you want to configure attribute sharing, and click the Update button.

  4. Click the Attribute Mappings button.

    Note:

    Note [1] no longer applies to the field name.

    The first table contains the attribute name mappings configuration, with the following fields for each attribute definition:

    • User Attr Name: The name of the local attribute in the user repository

    • Assertion Attr Name: The name that will be used to identify the attribute in the Assertion

    • Format or Namespace: An optional field used to specify the format of the namespace of the SAML attribute, depending on the version.

      • For SAML 1.x/Liberty 1.x, this field's value is used to set the SAML attribute's namespace.

      • For SAML 2.0, this value is used to set the SAML attribute's NameFormat; if this field is empty, the NameFormat of the SAML attribute will be set to urn:oasis:names:tc:SAML:2.0:attrname-format:basic; otherwise the NameFormat will hold the value specified in this field.

    • Send with SSO Assertions: Indicates whether the attribute should be sent during an SSO operation, along with the authentication assertion.

  5. After defining the necessary attributes, click the Apply button.

    Note:

    if you want to send any attributes with the SSO assertions, define the name formats for which attributes will be sent in the second table of the Attribute Mappings page. Also check the Enable Attributes in SSO box at the Edit Trusted Provider page.
  6. To make the changes effective for use by the server, click the Refresh Server button after saving all the data.

Here is an example of an Attribute Mappings configuration page:

Figure 6-1 Configuring Attribute Mappings

Surrounding text describes Figure 6-1 .
6.8.2.3.2 Attribute Value Mapping

This section describes how to configure attribute value mapping.

Note:

See "XML File Structure" above for a description of the attr-config.xml file. An understanding of the file structure is necessary to follow the subsequent discussion.

PeerProvider

Attribute value mapping is configured on a per-provider basis, which means that a specific mapping will apply only to one provider. The configuration for attribute value mapping will be stored in a PeerProvider element:

<PeerProvider providerID="idpID">
…  <!-- contains configuration for provider idpID -->
</PeerProvider>

PropertyGroup

The attribute value mapping configuration is contained in a PropertyGroup XML element whose name attribute is equal to attr-value-mappings. This element is defined under PeerProvider:

<PeerProvider providerID="idpID">
   <PropertyGroup name="attr-value-mappings">
   <!-- contains value mapping configuration for provider idpID -->
   </PropertyGroup>
</PeerProvider>

PropertyGroupItem

Each PropertyGroupItem defined under the PropertyGroup element represents mapping information for a local attribute:

<PropertyGroup name="attr-value-mappings">
   <PropertyGroupItem>
      …    <!-- contains mapping configuration for mail attribute -->
   </PropertyGroupItem>
   <PropertyGroupItem>
      …    <!-- contains mapping configuration for title attribute -->
   </PropertyGroupItem>
…
</PropertyGroup>

PropertyGroupItem contains two kinds of parameters:

  • simple name-value pair properties contained in Property elements

  • multiple groups of name-value pair properties contained in PropertiesList

Properties of PropertyGroupItem

The possible name-value pair properties that can be defined under the PropertyGroupItem for a specific attribute are:

  • attr-name, which defines the name of the local attribute for which the mapping configuration will apply:

    <Property name="attr-name">title</Property>
    
    
  • send-unmapped-values, which indicates whether Oracle Identity Federation will allow unmapped values to be sent out (true or false):

    <Property name="send-unmapped-values">true</Property>
    
    
  • receive-unmapped-values, which indicates whether Oracle Identity Federation will allow receipt of unmapped values (true or false):

    <Property name="receive-unmapped-values">false</Property>
    

PropertiesList

The PropertiesList element with the attribute name of mappings contains multiple groups of name-value pair properties. Each group of name-value pair properties defines a value mapping rule for the attribute defined in the PropertyGroupItem element.

A group of name-value pair properties is defined by a PropertiesListItem element.

<PropertiesList name="mappings">
   <PropertiesListItem>
      …  <!-- mapping rule for attribute title, for value local
       value "Senior Member of Technical Staff" and external value "smts" -->
   </PropertiesListItem>
   <PropertiesListItem>
      …  <!-- mapping rule for attribute title, for value local value 
      "Principal Member of Technical Staff" and external value "pmts" -->
   </PropertiesListItem>
</PropertiesList>

A PropertiesListItem element can be made up of XML attributes and Property children.

Properties of PropertiesListItem

The possible name-value pair properties that can be defined under the PropertiesListItem for a value mapping rule are:

  • local-value, which holds the local value for this mapping rule.

    <Property name="local-value">Senior Member of Technical Staff
    </Property>
    
    
  • external-value, which holds the external mapped value for this mapping rule.

    <Property name="external-value">smts
    </Property>
    

Attributes of PropertiesListItem

The possible parameters that can be defined as attributes of the PropertesListItem XML element are:

  • ignoreCase, which indicates whether the string comparison will be case-sensitive when matching attribute values (true or false):

    <PropertiesListItem ignoreCase="true">
    
    
  • isLocalNull, which indicates that the local value equals a null string (different from an empty string ""):

    <PropertiesListItem default="true" isLocalNull="true">
    <Property name="external-value">foo</Property>
    </PropertiesListItem>
    
    
  • isExternalNull, which indicates that the external value equals a null string:

    <PropertiesListItem default="true" isExternalNull="true">
    <Property name="local-value">foo</Property>
    </PropertiesListItem>
    
    
  • default, which indicates whether the local value will be used as the local value in case an incoming external value can be mapped to several local values. Note: There can only be one PropertiesListItem element defined with the default value set to true in a PropertiesList group (true or false).

    <PropertiesListItem ignoreCase="true" default="true">
    
6.8.2.3.3 Attribute Value Filtering

This section describes how attribute value filtering is applied in Oracle Identity Federation.

Note:

The structure of the attr-config.xml file was explained in "XML File Structure" above. An understanding of this file is necessary in order to follow the subsequent discussion.

PeerProvider

Attribute value filtering is configured on a per-provider basis, which means that a specific filter will only apply to one provider. So the configuration for attribute value filtering will be stored in a PeerProvider element:

<PeerProvider providerID="spID">
…  <!-- contains configuration for provider spID -->
</PeerProvider>

PropertyGroup

The attribute value filtering configuration information is contained in a PropertyGroup XML element whose name attribute is equal to attr-value-filters. This element is defined under PeerProvider:

<PeerProvider providerID="spID">
   <PropertyGroup name="attr-value-filters">
   …  <!-- contains value filtering configuration for provider spID -->
   </PropertyGroup>
</PeerProvider>

PropertyGroupItem

Each PropertyGroupItem defined under the PropertyGroup element represents filtering information for a local attribute:

<PropertyGroup name="attr-value-filters">
   <PropertyGroupItem>
      …    <!-- contains filtering configuration for mail attribute -->
   </PropertyGroupItem>
   <PropertyGroupItem>
      …    <!-- contains filtering configuration for title attribute -->
   </PropertyGroupItem>
…
</PropertyGroup>

The PropertyGroupItem contains two kinds of parameters:

  • simple name-value pair properties contained in Property elements

  • multiple groups of name-value pair properties contained in PropertiesList

Properties of PropertyGroupItem

The possible name-value pair properties that can be defined under the PropertyGroupItem for a specific attribute are:

  • attr-name, which defines the name of the local attribute for which the filtering configuration will apply:

    <Property name="attr-name">title</Property>
    
    
  • condition-operator, which indicates whether all conditions need to be met for an attribute to be sent (and operator), or if only one filter is enough to send an attribute (or operator):

    <Property name="condition-operator">and</Property>
    

PropertiesList

The PropertiesList element with the attribute name of filters contains multiple groups of name-value pair properties. Each group of name-value pair properties defines a value filtering rule for the attribute defined in the PropertyGroupItem element.

A group of name-value pair properties is defined by a PropertiesListItem element.

<PropertiesList name="filters">
   <PropertiesListItem>
   …  <!-- filtering rule for attribute title, for condition "not-equals" and expression "Manager" -->
   </PropertiesListItem>
   <PropertiesListItem>
   …  <!-- filtering rule for attribute title, for condition "not-equals" and expression "Director" -->
   </PropertiesListItem>
</PropertiesList>

A PropertiesListItem element can be made up of XML attributes and Property children.

Properties of PropertiesListItem

The possible name-value pair properties that can be defined under the PropertiesListItem for a value filtering rule are:

  • condition, which holds the type of condition of the filtering rule.

    <Property name="condition">not-equals
    </Property>
    
    
  • expression, which holds the expression that will be used to evaluate the condition with the outgoing attribute value.

    <Property name="expression">Manager
    </Property>
    

Attributes of PropertiesListItem

The following parameter can be defined as an attribute of the PropertiesListItem XML element:

  • ignoreCase, which indicates whether the string comparison will be case sensitive when matching attribute values.

    <PropertiesListItem ignoreCase="true">
    
    

Filtering Conditions

Oracle Identity Federation provides several filtering conditions (to be used in elements defined in "Properties of PropertiesListItem" above):

  • equals: the filtering rule will return true if the expression value is equal to the outgoing attribute value.

  • not-equals: the filtering rule will return true if the expression value is different from the outgoing attribute value.

  • startswith: the filtering rule will return true if the outgoing attribute value begins with the expression value.

  • endswith: the filtering rule will return true if the outgoing attribute value ends with the expression value.

  • contains: the filtering rule will return true if the outgoing attribute value contains the expression value.

  • not-contains: the filtering rule will return true if the outgoing attribute value does not contain the expression value.

  • equals-null: the filtering rule will return true if the outgoing attribute value is null.

  • not-equals-null: the filtering rule will return true if the outgoing attribute value is not null.

  • regexp: the filtering rule will return true if the outgoing attribute value matches the regular expression, which is defined in the expression value.

Note:

The rules are used to determine the allowed values. Consequently, if a rule evaluates to true, this means that it is permissible to send the value.

When the filtering rule is set to regexp, the expression value must be a standard Unix regular expression. See http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html for details about regular expression constructs.

Note:

The ignoreCase flag is disregarded during attribute value processing because regular expressions already support case-insensitivity.

Table 6-9 contains some examples illustrating the use of the regexp filtering condition:

Table 6-9 Using the regexp Filtering Condition

Regular Expression Meaning

.*rector

any string which ends with "rector"

[^abc]

any character except a, b, or c (negation)

user\d

user0, user1, ..., user9

a*b

any string which begins with 0+ "a" characters and ends with a letter b (for example, aaaaab)


6.8.3 Sample attr-config.xml File

A sample attr-config.xml file is provided here for reference.

<AttributeConfig useLocalConfig="false">
   <PeerProvider providerID="http://stadm14.us.oracle.com:7779/fed/idp">
      <PropertyGroup name="attr-value-filters">
         <PropertyGroupItem>
            <Property name="attr-name">title</Property>
            <Property name="condition-operator">and</Property>
            <PropertiesList name="filters">
               <PropertiesListItem ignoreCase="true">
                  <Property name="condition">not-equals</Property>
                  <Property name="expression">Manager</Property>
               </PropertiesListItem>
               <PropertiesListItem ignoreCase="true">
                  <Property name="condition">not-equals</Property>
                  <Property name="expression">Director</Property>
               </PropertiesListItem>
            </PropertiesList>
         </PropertyGroupItem>
      </PropertyGroup>
      <PropertyGroup name="attr-value-mappings">
         <PropertyGroupItem>
            <Property name="attr-name">title</Property>
            <Property name="send-unmapped-values">true</Property>
            <Property name="receive-unmapped-values">true</Property>
            <PropertiesList name="mappings">
               <PropertiesListItem ignoreCase="true">
                  <Property name="local-value">Senior Member of 
                  Technical Staff</Property>
                  <Property name="external-value">smts</Property>
               </PropertiesListItem>
               <PropertiesListItem ignoreCase="true">
                  <Property name="local-value">Principal Member of 
                  Technical Staff</Property>
                  <Property name="external-value">pmts</Property>
               </PropertiesListItem>
               <PropertiesListItem ignoreCase="true">
                  <Property name="local-value">Consulting Member of 
                  Technical Staff</Property>
                  <Property name="external-value">cmts</Property>
               </PropertiesListItem>
            </PropertiesList>
         </PropertyGroupItem>
      </PropertyGroup>
   </PeerProvider>
</AttributeConfig>

6.8.4 Examples

This section provides some examples showing how value mapping/filtering rules apply to SAML 2.0 outgoing attributes.

6.8.4.1 Example 1

Attribute Name = "title"

Old Attribute Values = ["Consulting Member of Technical Staff", "PRINCIPAL MEMBER OF TECHNICAL STAFF", "Principal Member of Technical Staff", "Vice President"]

New Attribute Values = ["cmts", "pmts", "Vice President"]

Note:

  1. Since we defined value mappings to be case-insensitive, both "PRINCIPAL MEMBER OF TECHNICAL STAFF" and "Principal Member of Technical Staff" get mapped to "pmts".

  2. Since "send-unmapped-values = true" and there is no rule defined for value "Vice President", we map it to itself.

  3. No filtering rules apply.

6.8.4.2 Example 2

Attribute Name = "title"

Old Attribute Values = ["Manager", "Consulting Member of Technical Staff"]

New Attribute Values = ["cmts"]

Note:

"Manager" is one of the forbidden values, so it never gets sent.

6.8.4.3 Example 3

The old filtering rules were:

<PropertyGroupItem>
   <Property name="attr-name">title</Property>
   <Property name="condition-operator">and</Property>
   <PropertiesList name="filters">
      <PropertiesListItem ignoreCase="true">
         <Property name="condition">not-equals</Property>
         <Property name="expression">Manager</Property>
      </PropertiesListItem>
      <PropertiesListItem ignoreCase="true">
         <Property name="condition">not-equals</Property>
         <Property name="expression">Director</Property>
      </PropertiesListItem>
   </PropertiesList>
</PropertyGroupItem>

The interpretation is that we allow any attribute value which is not equal to "Manager" and not equal to "Director".

Now suppose we change the filtering rules (changed items are in bold):

<PropertyGroupItem>
   <Property name="attr-name">title</Property>
   <Property name="condition-operator">or</Property>
   <PropertiesList name="filters">
      <PropertiesListItem ignoreCase="true">
         <Property name="condition"> equals</Property>
         <Property name="expression">Manager</Property>
      </PropertiesListItem>
      <PropertiesListItem ignoreCase="true">
         <Property name="condition"> regexp</Property>
         <Property name="expression">.*rector</Property>
      </PropertiesListItem>
   </PropertiesList>
</PropertyGroupItem>

The interpretation changes, in that we now only allow an attribute value which is either "Manager" or ends in "rector". Thus, we get:

Attribute Name = "title"

Old Attribute Values = ["Manager", "Consulting Member of Technical Staff"]

New Attribute Values = ["Manager"]

6.9 Configuring the Logout Service

Oracle Identity Federation provides a logout service that can be invoked to log the user out from all peer providers and from the Oracle Identity Federation, OracleAS Single Sign-On, Oracle Access Manager, and eTrust SiteMinder domains (clearing cookies for the last two servers).

The logout flow is invoked when logging out of the OracleAS Single Sign-On domain, but it may not be triggered when logging out from Oracle Access Manager or eTrust SiteMinder.

Administrators can use this service to trigger the logout flow from Oracle Identity Federation or use it as a link in a portal.

The logout process can be launched by accessing a URL of the form:

http://hostname:port/fed/user/logout?returnurl=http://anotherhostname/path

The logout service takes a required returnurl parameter, which is necessary for correct operation; the user will be redirected to this URL after the logout process completes.

If no returnurl parameter is specified 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. To avoid the problem, specify the returnurl parameter to point to the result page.

Note:

The logout is performed for all peer providers for the following protocols:
  • Liberty 1.1

  • Liberty 1.2

  • SAML 2.0

  • WS-Federation

6.9.1 WS-Federation Logout

WS-Federation can be used to sign into one or more service providers using an identity provider that performs the actual authentication.

The logout mechanism and URLs depend on whether the action is initiated at the IdP or the SP.

Note:

The IdP and SP logout URLs listed here are for use by remote WS-Federation providers when these providers need to set up their implementation for logout.

IdP-initiated Logout

The user clicks on a link at the IdP site that initiates a WS-Federation signout. This URL is:

http(s)://IP-HOST:IP-PORT/shareid/wsfederation/
ObWSFedIdentitySTS?wa=wsignout1.0

The Oracle Identity Federation IdP keeps track of each service provider that the user signed into. The server constructs and returns to the user's browser an HTML signout page, with iframes for each SP. Each iframe issues a request to the target SP for the WS-Federation signout cleanup:

http(s)://RP-HOST:RP-PORT/shareid/wsfederation/
ObWSFedResourceSTS?wa=wsignoutcleanup1.0

Each SP processes the signout cleanup to signout the SP session created for WS-Federation, and returns an appropriate logout message to be displayed in the iframe in the IdP's signout page.

When Oracle Identity Federation is the SP, it performs an internal redirection back to the ObWSFedResourceSTS servlet, and the servlet returns the following logout message:

Successful logout for Realm Resource Realm URI

This message and its HTML declaration is defined in the shareid-messages.properties file, and can be translated and customized.

To sign out the IdP session, the Oracle Identity Federation IdP adds an iframe with a signout cleanup request for the IP host and port. The logout page will display logout messages for each SP and for the IdP.

SP-initiated Logout

The user clicks on a link at an SP site that initiates the WS-Federation signout. This URL is:

http(s)://RP-HOST:RP-PORT/shareid/wsfederation/
ObWSFedResourceSTS?wa=wsignout1.0

The SP records the IP address that was used to sign in, and redirects the user's browser to the IdP's signout URL to perform the signout. From this point on, the signout is the same as for the IP-initiated signout.

6.10 Using SSL with Oracle Identity Federation

This section explains how to set up SSL connections between Oracle Identity Federation servers and peer providers. It contains these topics:

To configure SSL on the Oracle Application Server where Oracle Identity Federation is running, refer to:

Oracle HTTP Server Administrator's Guide

6.10.1 Connecting to SSL Servers

To configure Oracle Application Server to allow Oracle Identity Federation to make SSL connections to remote Liberty 1.x/SAML providers, you will need to import the trusted CA certificates in the JVM's keystore. To do so, use the keytool application located in the $ORACLE_HOME/jdk/bin directory to add trusted certificates to the keystore in the $ORACLE_HOME/fed/shareid/oblix/config/keystore file.

Restart Oracle Application Server for the changes to take effect.

Note:

If you had previously inserted SSL certificates into the $ORACLE_HOME/jdk/jre/lib/security/cacerts file, you will need to re-import them to $ORACLE_HOME/fed/shareid/oblix/config/keystore.

6.10.2 Authenticating to SSL Servers

Some SSL Servers might require authentication of the client performed during the SSL handshake. This operation is typically done by having the SSL Client presenting an SSL Client Certificate to the SSL Server.

This section describes how to set up SSL with client certificate authentication. In brief, the steps are:

  1. Set up trust for the CA that issued the IdP SSL server certificates.

  2. Obtain a certificate for the Oracle Identity Federation SSL client.

The detailed step-by-step procedure follows.

In the syntax shown in these steps, KEYTOOL, KEYSTORE, and STOREPASS represent these values:

KEYTOOL=ORACLE_HOME/jdk/bin/keytool
KEYSTORE=ORACLE_HOME/fed/shareid/oblix/config/keystore
STOREPASS=ias_admin password

Take these steps to configure certificate authentication on the server where the SSL client resides:

  1. Set up trust for the CA(s) that issued the SSL server certificates for the remote SSL Server(s) to which Oracle Identity Federation will connect:

    • Obtain the PEM-formatted certificates for each CA that issued a certificate for the SSL servers.

    • Import each CA certificate into the shareid keystore.

      KEYTOOL -keystore ORACLE_HOME/fed/shareid/oblix/config/keystore 
         -storepass OIF_ADMIN_PASSWORD -import -alias CA-ALIAS 
         -file CA-CERT.pem
      
      
    • Restart OC4J_FED.

  2. For client certificate authentication, get a certificate for the Oracle Identity Federation SSL client.

    • Generate a certificate request for the existing key:

      KEYTOOL -keystore KEYSTORE -storepass STOREPASS
         -certreq -alias shareid -file CLIENT-REQ.pem
      
      
    • Submit the certificate request in client-req.pem to your CA. Request a certificate without a keyUsage extension.

    • Obtain the certificate from the CA, and also the CA's certificate, in PEM format. Paste the certificates into files and ensure there are no extraneous newlines in the files.

    • Import the CA certificate into the keystore as a trusted certificate:

      KEYTOOL -keystore KEYSTORE -storepass STOREPASS 
         -import -alias your-CA -file CA-CERT.pem
      
      Trust this certificate? yes
      
      
    • Import the certificate into the keystore:

      KEYTOOL -keystore KEYSTORE -storepass STOREPASS 
         -import -alias shareid -file CLIENT-CERT.pem
      
      

      Note:

      If you see the exception "java.security.cert.CertificateException: DerInputStream.getLength(): lengthTag=127, too big", there is an extraneous newline in the certificate file after the last line. Delete it and try again.
    • Restart OC4J_FED:

      ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=OC4J_FED
      ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=OC4J_FED
      
      

6.10.3 Configuring SSL Server on Oracle Identity Federation

This section describes how to set up SSL with optional client certificate authentication. In brief, the steps are:

  1. Create a wallet with the HTTP server key and certificate.

  2. Enable SSL on the HTTP server.

  3. Optionally configure an additional SSL port on the HTTP server with client certificate authentication enabled.

The detailed step-by-step procedure follows. Take these steps to configure certificate authentication on the Oracle Identity Federation site where the SSL server resides:

  1. Create a wallet with the HTTP server key and certificate.

    • Set the ORACLE_HOME environment variable, if it is not already set.

    • Run the Oracle Wallet Manager:

      Unix: $ORACLE_HOME/bin/owm

      Windows: Start - > All Programs - > Oracle - ORACLE_HOME_NAME - > Integrated Management Tools - > Wallet Manager

    • Create a new wallet:

      • In the Manager window, select Wallet - > New.

      • Answer Yes to "Your default wallet does not exist".

      • Answer Yes to "Cannot create system default wallet directory... continue anyway?"

      • In the New Wallet window, enter a password for the wallet. Use the default Standard Wallet Type. Click OK.

      • Answer Yes to "Do you want to create a certificate request at this time?"

      • Fill in the Create Certificate Request window with the fields you want in the server's certificate DN. Note that the Common Name must be the server's DNS name. Click OK.

      • Click OK on the "A certificate request has been created" confirmation.

    • Save the wallet as the default wallet for Oracle HTTP Server.

      • Select Wallet - > Save As.

      • In the Select Directory window, enter ORACLE_HOME/Apache/Apache/conf/ssl.wlt/default.

      • Click OK twice.

      • Answer Yes in response to "A wallet already exists in the selected location."

    • Obtain a certificate from your CA and import it into the wallet.

      • In the Wallet Manager window, left-click on Certificate:[Requested].

      • Submit the certificate request shown in the Certificate Request panel to your CA. Request an SSL server certificate, for OpenSSL.

        - keyUsage = digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
        
        - nsCertType = server
        
      • Obtain the base64 format certificate from the CA, and obtain the base64 format certificate for the CA.

      • In the Wallet Manager window, right-click on Trusted Certificate and select Import Trusted Certificate.

      • In the Import Trusted Certificate window, select Paste Certificate. Click OK and paste the CA certificate in the text box. Click OK. The CA certificate appears in the list of Trusted Certificates in the Wallet Manager window.

      • In the Wallet Manager window, right-click on Certificate:[Requested] and select Import User Certificate.

      • In the Import Certificate window, select Paste Certificate. Click OK and paste the certificate in the text box. In the Wallet Manager window, the certificate status turns to Certificate:[Ready].

    • Select Wallet->Save.

    • Select Wallet->Exit.

    • Also save the wallet to ORACLE_HOME/opmn/conf/ssl.wlt/default.

  2. Enable SSL on Oracle HTTP Server.

    • Edit ORACLE_HOME/opmn/conf/opmn.xml. In the element shown here, change "ssl-disabled" to "ssl-enabled".

      <ias-component id="HTTP_Server">
         <process-type id="HTTP_Server" module-id="OHS">
            <module-data>
               <category id="start-parameters">
                  <data id="start-mode" value="ssl-enabled/>
               </category>
            </module-data>
            <process-set id="HTTP_Server" numprocs="1"/>
         </process-type>
      </ias-component>
      

      Save the edited file.

    • Update the Distributed Cluster Management database using this command:

      ORACLE_HOME/dcm/bin/dcmctl updateconfig -ct opmn

    • Reload OPMN using this command:

      ORACLE_HOME/opmn/bin/opmnctl reload

      Note:

      If you see the "globalInitNLS: NLS boot file not found or invalid" error, unset any environment variables with names starting in ORA_NLS.
    • Restart Oracle HTTP Server.

      ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=HTTP_Server

      ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=HTTP_Server

      Note:

      You must use opmnctl to restart Oracle HTTP Server; do not restart from the Enterprise Manager console.
    • Use the Enterprise Manager console to verify that the SSL port is active. Select the Ports tab from the EM home page. You should see an entry in the ports table for the Oracle HTTP Server component with type Listen (SSL) and the port number. (The default port number for the first install on the host is 4443, for the second install 4444, and so on.)

    • Use a browser to verify the SSL port is active.

      https://hostname:ssl-port/

      Note:

      If you see an alert indicating that the server certificate does not match the server name, check the certificate subject. If the subject is GET A REAL CERTIFICATE, then Oracle HTTP Server is still using the original dummy certificate. Try restarting the server again.
  3. For client certificate authentication, configure an additional SSL port on Oracle HTTP Server with client certificate authentication enabled.

    • Edit the ORACLE_HOME/Apache/Apache/conf/ssl.conf file.

      • Copy the existing Listen and VirtualHost definitions and paste them at the end of the file, before the closing </IfDefine>.

      • Change the port in the copied definitions to an unused port for SSL client certificate authentication.

      • In the copied VirtualHost definition, uncommment SSLVerifyClient require. This directs Oracle HTTP Server to perform the certificate authentication with the client.

      • In the copied VirtualHost definition, replace the commented SSLOptions with:

        SSLOptions +ExportCertData +CompatEnvVars

        This directs Oracle HTTP Server to pass the client certificate on to the mod_oc4j module.

        Here is an example (comments omitted):

        Listen CLIENT-CERT-PORT 
        <VirtualHost _default_:CLIENT-CERT-PORT>
        DocumentRoot "ORACLE_HOME/Apache/Apache/htdocs"
        ServerName HOST-DNS-NAME
        ServerAdmin you@your.address
        ErrorLog "|ORACLE_HOME/Apache/Apache/bin/rotatelogs
           ORACLE_HOME/Apache/Apache/logs/error_log 43200"
        TransferLog "|ORACLE_HOME/Apache/Apache/bin/rotatelogs
           ORACLE_HOME/Apache/Apache/logs/access_log 43200"
        Port CLIENT-CERT-PORT
        SSLEngine on
        SSLCipherSuite ALL:!ADH:!EXPORT56:+HIGH:+MEDIUM:+LOW:+SSLv2:+EX
           SSLWallet file:ORACLE_HOME/Apache/Apache/conf/ssl.wlt/default
           SSLVerifyClient require
           SSLOptions +ExportCertData +CompatEnvVars
           . . .
        </VirtualHost>
        
      • Save the ssl.conf file.

      Notes:

      When setting up the SSL endpoint with client certificate, the Administrator can only specify the Certificate Authority from which Oracle Identity Federation/Oracle HTTP Server will accept SSL Certificates when requiring the Client Certificate: all the certificates issued by the CA will be accepted.

      To be able to do some fine-grained filtering of SSL certificates (that is, only a few certificates out of the whole issued by the CA), the Oracle Identity Federation Administrator can build a filter based on the certificate's subject and issuer names. For example, in the $Oracle_Home/Apache/Apache/conf/ssl.conf file, in the VirtualHost element defining the SSL endpoint, one could add an SSLRequire command defined in a Location element for the /fed relative URL:

      <Location /fed> 
         SSLRequire (%{SSL_CLIENT_S_DN_CN} eq "john doe") 
      </Location> 
      
      

      This statement will only accept certificate with a Subject's Common Name equals "john doe".

      Other filters are available. Please check the mod_ssl SSLRequire command in the Oracle HTTP Server Administrator's Guide.

    • Edit the ORACLE_HOME/Apache/Apache/conf/mod_oc4j.conf file.

      • Add Oc4jExtractSSL On to the end of the file, before the </IfModule> tag. This directs mod_oc4j in Oracle HTTP Server to pass the client certificate on to OC4J in the javax.servlet.request.X509Certificate attribute, as expected by the ObSAMLResponderService servlet, as well as the Oracle Identity Federation Server when the soaprequiresslcert property is set to true, indicating that the Liberty 1.x/SAML 2.0 SOAP stack will require an SSL Client certificate when processing an incoming SOAP connection from a remote provider..

      • Save the mod_oc4j.conf file.

    • Restart Oracle HTTP Server.

      ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=HTTP_Server

      ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=HTTP_Server

      Note:

      You must use opmnctl to restart Oracle HTTP Server; do not restart from the Enterprise Manager console.
    • If you have a browser with one or more client certificates issued by your CA, use that browser to verify that the client-cert-port is active.

      https://hostname:client-cert-port/

6.10.4 Requiring a Client SSL Certificate for SOAP Requests

Oracle Identity Federation version 10.1.4.2 introduces a new configuration parameter, requireSSLCert, applicable only to Liberty 1.x and SAML 2.0 protocols, which allows the Oracle Identity Federation administrator to require a client SSL certificate for all SOAP requests. This protects the SOAP port, if so desired, by setting up an SSL port with SSL client certificate turned on, and instructing Oracle Identity Federation to check if an SSL Client certificate was sent.

When a requester hits the SOAP URL using any opened Oracle HTTP Server ports, Oracle Identity Federation will make sure that the requester presented a certificate; an unknown requester using a non-SSL port or an SSL port without SSL client certificate will be denied access.

Take these steps to configure Oracle Identity Federation to require an SSL client certificate on the SOAP endpoint:

  1. Perform the steps described in "Configuring SSL Server on Oracle Identity Federation".

  2. Open the $ORACLE_HOME/fed/conf/config.xml file.

  3. Locate the FederationConfig XML element, and set its useLocalConfig attribute to true:

    <FederationConfig useLocalConfig="true">
    
    
  4. Locate the XML Config element named serverconfig, and find the soaprequiresslcert property:

    <Config name="serverconfig">
    ...
       <property name="soaprequiresslcert">false</property>
    ...
    </Config>
    
    

    To force Oracle Identity Federation to require SSL certificates on the SOAP endpoint, change the value of the property to true. To accept SOAP requests without SSL client certificates, change the value of the property to false.

  5. Save the file and exit.

  6. Restart the OC4J_FED instance.

6.11 Protecting the Liberty 1.x / SAML 2.0 SOAP Endpoint

Oracle Identity Federation provides two methods to protect the SOAP endpoint used in the Liberty 1.x / SAML 2.0 protocols:

This section explains how to implement these techniques.

6.11.1 SSL Client Authentication

Refer to "Using SSL with Oracle Identity Federation" for details on how to:

  • configure SSL to protect the SOAP URL

  • configure Oracle Identity Federation to connect to SOAP endpoints protected by SSL

6.11.2 HTTP Basic Authentication

This section describes:

  • how to configure HTTP Basic Authentication on the server to protect the SOAP URL

  • how to configure the credentials that will be used when connecting to a remote server protected by HTTP Basic Authentication using the SOAP protocol

Note:

When it is integrated with Oracle Single Sign-On, the Oracle Identity Federation server cannot be protected using HTTP Basic Authentication.

6.11.2.1 Configuring HTTP Basic Authentication to protect the SOAP URL

This section lists the steps needed to protect the Liberty 1.x / SAML 2.0 SOAP endpoint. With these steps, you create a file defining the user credentials, and modify a configuration file to indicate the URL that needs to be protected.

The configuration changes will be made on the Oracle HTTP Server, using the basic mod_auth module.

The steps are as follows:

  1. Create the user credentials file to hold the username and password entries, using the htpasswd utility:

    $ORACLE_HOME/Apache/Apache/bin/htpasswd -c $ORACLE_HOME/Apache/Apache/conf/.htpasswd-fed SOAP_USERNAME
    
    

    where SOAP_USERNAME is the username of the first account to be added to the newly created file. You will be prompted for the password.

    To add other entries to the file, use the following command:

    $ORACLE_HOME/Apache/Apache/bin/htpasswd $ORACLE_HOME/Apache/Apache/conf/.htpasswd-fed SOAP_USERNAME
    
    

    where SOAP_USERNAME is the username of the account to be added to the file. You will be prompted for the password.

  2. Open the $ORACLE_HOME/Apache/Apache/conf/mod_oc4j.conf file.

  3. Add the following element inside the <IfModule mod_oc4j.c> element (to prompt for basic authentication for any requests made to the soap backend), replacing the $ORACLE_HOME variable with the full path to the ORACLE_HOME directory:

    <LocationMatch "/fed/.*/soap*">
       AuthType Basic
       AuthName "SOAPBasicAuth"
       AuthUserFile $ORACLE_HOME/Apache/Apache/conf/.htpasswd-fed
       Require valid-user
    </LocationMatch>
    
    
  4. Save and exit the file.

  5. Restart Oracle HTTP Server using the command:

    $ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server
    

Note:

After executing the command, if using RDBMS as the Oracle Identity Federation transient data store, restart OC4J_FED. Otherwise, click the Refresh Server button on the Oracle Identity Federation Administration Console.

6.11.2.2 Configuring Oracle Identity Federation to Connect to a Protected SOAP URL

On the client side, Oracle Identity Federation implements support for Basic Authentication when connecting to peer providers on the SOAP channel. A command-line tool is available to set up Oracle Identity Federation to use Basic Authentication with a given username/password when connecting to a specific remote provider. This tool, fedbasicauth.jar, updates the Oracle Identity Federation configuration so that the server can use the entered credentials when connecting to the SOAP endpoint of the remote provider.

When configuring the HTTP Basic Authn SOAP credentials, use this command to obtain help for the tool:

$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/fed/lib/fedbasicauth.jar

The tool responds with this information:

Usage: java -jar fedbasicauth.jar <options> [action]
Manage HTTP Basic Auth configuration for Oracle Identity Federation.
Options:
  -oh <path> The ORACLE_HOME directory. (REQUIRED)
  -providerid <id> The URI of the peer provider. (REQUIRED)
  -username <u> The username. (REQUIRED if action is -set)
  
Actions:
  -set Sets basic auth credentials (prompts for password). Basic auth is also enabled for the provider.
  -remove Removes basic auth config for the provider.
  -enable Enables basic auth for the provider.
  -disable Disables basic auth for the provider.
  -show Shows basic auth config for the provider. Password is not displayed.
  --help Displays this usage information. (DEFAULT)

Some examples of tool usage follow.

Example 1

Sets username 'jsmith' (and prompted password) as basic authentication credentials for peer provider http://idp.example.org, and turns on basic authentication for the provider:

$ORACLE_HOME/jdk/bin/java 
-jar $ORACLE_HOME/fed/lib/fedbasicauth.jar 
-oh $ORACLE_HOME 
-provider http://idp.example.org 
-set -username jsmith

Example 2

Turns off basic authentication for provider http://idp.example.org:

$ORACLE_HOME/jdk/bin/java 
-jar $ORACLE_HOME/fed/lib/fedbasicauth.jar 
-oh $ORACLE_HOME 
-provider http://idp.example.org 
-disable 

Example 3

Turns on basic authentication for provider http://idp.example.org. Assumes that the credentials are already set:

$ORACLE_HOME/jdk/bin/java 
-jar $ORACLE_HOME/fed/lib/fedbasicauth.jar 
-oh $ORACLE_HOME 
-provider http://idp.example.org 
-enable

Example 4

Turns off basic authentication for provider http://idp.example.org, and removes the credentials:

$ORACLE_HOME/jdk/bin/java 
-jar $ORACLE_HOME/fed/lib/fedbasicauth.jar 
-oh $ORACLE_HOME 
-provider http://idp.example.org 
-remove