Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Identity Federation
11g Release 1 (11.1.1)

Part Number E13400-06
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
PDF · Mobi · ePub

5 Configuring Oracle Identity Federation

This chapter describes configuration tasks for Oracle Identity Federation. It contains these topics:

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

Note:

Liberty 1.x support is deprecated.

5.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, signing and encryption PKCS#12/JKS keystores, 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

  • Information about peer providers that are trusted providers of this server. Trusted provider configuration data includes:

    • name ID formats to use for assertions

    • attributes to send along with an authentication response

    • 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 trusted providers. Likewise, the administrator must be aware of changes to peer providers' metadata.

Here is a list of properties that affect metadata:

  • Metadata Properties

    • Signing Metadata

    • Validity Period

  • Server Properties

    • Server Hostname

    • Server Port

    • SOAP Port

    • IdP Enabled

    • SP Enabled

    • SSL Enabled

    • Signing PKCS #12/JKS Keystore

    • Encryption PKCS #12/JKS Keystore

  • Common IdP Properties

    • ProviderID

    • SAML 2.0 Enabled

  • Common SP Properties

    • ProviderID

    • SAML 2.0 Enabled

    • Enable Attribute Requester Service

  • SAML 2.0 IdP Properties

    • Enable Protocol Profiles

    • Federation Termination Enabled

    • Register NameID Enabled

    • Attribute Responder Enabled

  • SAML 2.0 SP Properties

    • Enable Protocol Profiles

    • Federation Termination Enabled

    • Register NameID Enabled

The metadata URLs for the various protocols are in this format:

Note:

You can retrieve the metadata from Fusion Middleware Control, by navigating to Security and Trust, then Provider Metadata.

  • IdP metadata URL - http(s)://hostname:port/fed/idp/metadata?version=version

  • SP metadata URL - http(s)://hostname:port/fed/sp/metadata?version=version

where version can be saml20, saml11, saml10, lib11, or lib12.

5.1.2 User Federation Data

A data store contains each user's identity federation data; the data store can be an LDAP directory or an RDBMS. 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 user record in the user data store.

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.

If a user's attribute value in the user store has changed, the user's federation record can be updated, for example in Fusion Middleware Control, from the Identities page.

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 de provisioned.

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:

5.2 Configuring Server Properties

Server properties include:

5.2.1 Host Connection Properties

These types of properties are configured for the server:

  • basic connection parameters

  • encryption settings

  • logout options

Connection Parameters

You can configure the following parameters:

  • Host

    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 your trusted providers.

    If there is a change to the host or port of the server, you can either define a virtual hostname or proxy server hostname, or else change the server host property.

  • 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 container 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 trusted providers.

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

    Note:

    Checking the Force SSL 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 host name and port properties and the requested URL.

  • 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 container 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 trusted providers.

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

    Note:

    Checking the Force SSL 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 host name and port properties and the requested URL.

    Checking Require Client Certificate forces SSL client authentication in all incoming SOAP connections.

  • Server Clock Drift

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

  • 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 or Oracle Single Sign-On 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.

  • Request Timeout

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

Encryption Settings

For Default XML Data Encryption Algorithm - Select one of the available encryption algorithms:

  • AES-128 CBC

  • Triple DES CBC

  • AES-192 CBC

  • AES-256 CBC

Note:

Encryption methods other than AES-128 CBC require installation of the JCE encryption package. See Section 8.3, "Setting up JCE Policy Files for Oracle WebLogic Server".

Logout Options

You can configure one of these logout options:

  • Failure on Error

    During the Global Logout flow, if an error is encountered, Oracle Identity Federation will either abort the operation and throw an error or continue and finish the logout operation.

  • Status Return

    Return: If enabled and if the logout operation is started at Oracle Identity Federation by accessing the /fed/user/logout URL, the server redirects the user to the returnURL once the logout operation is done, and appends to that URL a query parameter indicating the result of the logout operation.

    The query parameter name is orafed_slostatus, and the possible values are:

    • 0 for success

    • 1 for failure

  • Local Only Logout

    If enabled, when Oracle Identity Federation performs a logout operation for a user, it will not invoke the WS-Fed/SAML Logout protocol. Instead it only logs the user out of the Authentication Engines and Identity and Access Management framework, and destroys the Oracle Identity Federation session.

  • Parallel Logout

    By default, when performing a SAML/WS-Fed Global Logout operation, Oracle Identity Federation sequentially redirects the user to all the providers from which the user needs to be logged out. This can become a time-consuming operation and if the logout flow is broken at one point because a provider is unresponsive, the logout flow will not finish. By enabling Parallel Logout, Oracle Identity Federation will display to the user a page with frames, each one performing a SAML/WS-Fed Logout operation with one specific provider. This can improve the global performance of the logout flow and minimize disruptions.

Surrounding text describes oifsvrprops1.gif.

5.2.2 Outbound Connection Properties

Surrounding text describes oifsvrprops2.gif.

Outbound SOAP Connections

You can configure the following parameters:

  • Maximum SOAP Connection

  • Maximum SOAP Connection Per Server

Oracle Identity Federation can communicate with remote SAML Servers using different bindings, among them the SOAP binding. When Oracle Identity Federation needs to send a message to a remote server using the SOAP protocol, it will directly open a connection and send a SOAP message.

You can configure the maximum number of concurrent connections that Oracle Identity Federation can open when sending SOAP messages, and the maximum number of concurrent connections that Oracle Identity Federation can open when sending SOAP messages to a specific provider.

HTTP Proxy Settings

Use this section to configure Oracle Identity Federation to use a proxy for outgoing SOAP connections:

  • Proxy Host - The proxy hostname.

  • Proxy Port - The proxy port number.

  • Username - The username to use when connecting to the proxy.

  • Password - The password to use when connecting to the proxy.

  • Non-Proxy Hosts - A list of hosts for which the proxy should not be used. Use ';' to separate multiple hosts.

5.3 Configuring Identity Providers - Common Properties

Surrounding text describes oifsvrpropsidp1.gif.

Enabling IdP

To enable the server as an IdP:

Assertion Settings

Specify assertion parameters as follows:

Protocol Settings

Specify protocol settings as follows:

5.4 Configuring Identity Providers - Protocol-Specific Properties

This section describes how to configure IdP protocol-specific properties:

5.4.1 Configure SAML 2.0 IdP Properties

Assertion Properties

Surrounding text describes oifsvrpropsidp2.gif.

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

Provide the following information in the table:

  • Enabled - Check a 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.

  • Default - Use the radio button to select a default NameID format.

  • Get Value from User Session - Check a box to specify that the attribute, to which the corresponding NameID maps, is found in the session created when the user is authenticated.

  • NameID Format - This column displays the available name identifier formats. The formats are as follows:

    Table 5-1 SAML 2.0 IdP NameID Formats

    NameID Format Default

    X.509 Subject Name

    dn

    Email Address

    mail

    Windows Domain Qualified Name

    empty

    Kerberos Principal Name

    empty

    Custom

     

    Unspecified

     

    Persistent Identifier

     

    Transient/One-Time Identifier

     

    None

     

  • User Attribute Mapping - Enter the attribute name for the selected name ID format. Oracle Identity Federation uses the attribute name to perform a lookup in the user data store (or user session if Get Value from User Session is checked) for a name ID in this format.

Note:

You can set the user attribute in the Assertion Subject NameID Formats table to "orafed-userid" to use the UserID to populate the NameID element. This is specially useful when no user store is configured for the IdP and thus no user store attributes are available.

Note:

This table is used when creating an outgoing assertion. Depending on the NameID format, Oracle Identity Federation/IdP does the following:

  • for X.509 Subject Name, Email Address, Windows Domain Qualified Name, Kerberos Principal Name and Unspecified, the server checks the configuration to determine which user attribute to use to populate the NameID element and retrieves the value from the user record.

  • for Custom, the server checks the configuration to determine which user attribute to use to populate the NameID element and retrieves the value from the user record. It also sets the format of the NameID to the value specified in the configuration.

  • for Persistent, the server uses a randomly generated identifier to build the NameID. That identifier is stored as a federation record for subsequent operations involving this user with the remote provider.

  • for Transient, the server uses a randomly generated identifier to build the NameID that will only be used once.

  • for None, the server does not include any NameID in the assertion.

Name of Custom Format - This is the format to use in the NameID, when creating an assertion that will use the custom NameID format.

UserID as the NameID

You can set the user attribute in the "Assertion Subject NameID Formats" table to "orafed-userid" to use the UserID to populate the NameID element. This feature is particularly useful when there is no user store configured for the IdP, and thus, no user store attributes available.

Additional Assertion Fields

The fields below the table are as follows:

  • Federation Creation 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.

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

  • Send Encrypted Attributes

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

  • Send Encrypted NameIDs

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

  • Send Encrypted Assertions

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

  • Send Signed Assertions

    Check this box to enable Oracle Identity Federation to send signed assertions to peer providers. The value specified on this page will override the value specified in the Identity Provider - Common tab, when using the SAML 2.0 protocol. If you do not wish to override the value in Identity Provider - Common, click the blue circle so that the square is not filled in, and there is an arrow pointing to the square, as in the image above.

About the User Consent Page

If the user must consent to setting up a new federation, you must design a consent page to which the user is redirected.

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

Table 5-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 requires 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>

Protocol Settings

Surrounding text describes oifsvrpropsidp2a.gif.
  • Enable SAML 2.0 Protocol - Check this box to enable the SAML 2.0 protocol.

  • Enable Single Sign-On Protocol - Check this box to enable the single sign-on protocol.

  • Enable NameID Management Protocol: Terminate

    Check this box to enable the federation termination capability.

    Note:

    This property affects server metadata. When updating this property, distribute the updated metadata to all trusted providers.

  • Enable NameID Management Protocol: Register - Check this box to enable name ID registration.

  • Enable Attribute Query Responder

    Check this box to enable the identity provider to act as an attribute authority.

    Note:

    This property affects server metadata. When updating this property, distribute the updated metadata to all trusted providers.

  • Use Identity Federation for Attribute Response

    Check this box if you wish the user in the attribute request to be located in this identity provider using its federated identity. Note that if using this setting, the user must have a federation identity and its Name ID value and format must match the subject value and format specified in the AttributeQuery.

    When this box is checked, the attribute authority first tries to look up the user in the federation store; if no records are found, it locates the user by attribute value from the user data store.

    This property may also be overridden on the Edit Trusted Provider page on the Oracle Identity Federation Settings tab.

  • Enable Authentication Query Responder

    In SAML protocols, an identity provider may act as an authentication authority. A service provider may send an authentication query to an Authentication authority to ask "What assertions used for authentication have been issued for this subject"? The Authentication authority responds by providing the assertions that have been previously issued for authentication of the given subject.

    Check this box to enable the identity provider to act as an Authentication authority.

    Note:

    This property affects server metadata. When updating this property, distribute the updated metadata to all trusted providers.

  • Enable Assertion ID Responder

    In SAML protocols, an identity provider may act as an assertion ID authority. A trusted service provider may send an assertion ID request to an assertion ID authority in which it provides the unique ID of an assertion previously issued by the identity provider. The assertion ID authority responds by providing the assertion with the ID in the request.

    Check this box to enable this identity provider to act as an assertion ID authority.

    Note:

    This property affects server metadata. When updating this property, distribute the updated metadata to all trusted providers.

  • Enable Protocol Bindings

    In the drop down, select all protocol bindings you wish to enable.

  • Default Binding

    Select the binding to be used as a default when the identity provider sends a request or response (excluding SSO Responses) and no preferred binding was specified. e.g. in Name ID Management Protocol messages.

  • Default SSO Response Binding

    Select the binding to be used as a default when the identity provider sends an SSO Response and no preferred binding was specified in the AuthnRequest.

  • Messages to Send/Require Signed

    specify the messages that Oracle Identity Federation sends, in IdP mode, that it must sign; and the messages it receives, in IdP mode, that it requires signed.

    Note:

    The Require AuthnRequest Signed property affects server metadata. When updating this property, distribute the updated metadata to all trusted providers.

5.4.2 Configure SAML 1.x IdP Properties

Use this page to configure Oracle Identity Federation to use the SAML 1.0/SAML 1.1 protocol when acting as an identity provider. The page contains tables for assertion settings and protocol settings, respectively.

Assertion Settings

Surrounding text describes oifsvrpropsidp3.gif.

The table shows the Subject NameID formats you can configure. Provide the following information:

  • Enabled - Check a box to enable the corresponding NameID format.

  • Default - Use the radio button to select a default NameID format.

  • Get Value from User Session - Check a box to specify that the attribute to which the corresponding NameID maps is found in the session created when the user is authenticated.

  • NameID Format - This column displays the available name identifier formats. The formats are as follows:

    Table 5-3 SAML 1.x Identity Provider Name ID Formats

    NameID Format Default

    X.509 Subject Name

    dn

    Email Address

    mail

    Windows Domain Qualified Name

    empty

    Unspecified

    empty

    Custom

    empty

    None

     

  • User Attribute Mapping - Enter the attribute name for the selected name ID format. Oracle Identity Federation will use the attribute name to perform a lookup in the user data store (or user session if Get Value from User Session is checked) for a name ID in this format.

Note:

You can set the user attribute in the Assertion Subject NameID Formats table to "orafed-userid" to use the UserID to populate the NameID element. This is specially useful when no user store is configured for the IdP and thus no user store attributes are available.

Send Signed Assertion - Check this box to enable Oracle Identity Federation to send signed assertions to peer providers. The value specified on this page will override the value specified in the Identity Provider - Common tab, when using the SAML 1.0 or SAML 1.1 protocols. If you do not wish to override the value in Identity Provider - Common, click the blue circle so that the square is not filled in, and there is an arrow pointing to the square, as in the image above.

Protocol Settings

Use this table to specify protocol settings and related attributes.

Surrounding text describes oifsvrpropsidp3a.gif.

Provide the following information:

  • Protocol - Check one or both of the Enable SAML 1.1 Protocol and Enable SAML 1.0 Protocol boxes.

  • Enable Single Sign-On - Check this box to enable the single sign-on protocol.

  • Enable Attribute Query Responder - Check this box to enable the identity provider to act as an attribute authority.

  • Enable Authentication Query Responder

    In SAML protocols, an identity provider may act as an Authentication authority. A service provider may send an Authentication query to an Authentication authority to ask "What assertions used for authentication have been issued for this subject"? The Authentication authority responds by providing the assertions that have been previously issued for authentication of the given subject.

    Check this box to enable the identity provider to act as an Authentication authority.

  • Enable Assertion ID Responder

    In SAML protocols, an identity provider may act as an assertion ID authority. A trusted service provider may send an assertion ID request to an assertion ID authority in which it provides the unique ID of an assertion previously issued by the identity provider. The assertion ID authority responds by providing the assertion with the ID in the request.

    Check this box to enable this identity provider to act as an assertion ID authority.

  • Default SSO Response Binding - Select the binding to be used as a default when the identity provider sends an SSO Response and no preferred binding was specified in the AuthnRequest.

  • Messages to Send/Require Signed - specify the messages that Oracle Identity Federation sends, in IdP mode, that it must sign; and the messages it receives, in IdP mode, that it requires signed.

5.4.3 Configure WS-Federation IdP Properties

Use this page to configure Oracle Identity Federation to use the WS-Federation 1.1 protocol when acting as an identity provider.

Surrounding text describes oifsvrpropsidp4.gif.

Provide the following information:

  • Enable WS-Federation 1.1 Protocol - Check this box to enable the protocol.

  • SSO Token Type - Use the drop-down box to select the single sign-on token type.

  • Use Microsoft Web Browser Federated SSO Profile - Check this box to have Oracle Identity Federation use the Microsoft WS-Fed protocol specifications.

5.4.4 Configure OpenID IdP Properties

Use this page to configure an OpenID provider in IdP mode.

Surrounding text describes idpopenid.gif.

The fields are as follows:

  • Enable OpenID 2.0 Protocol - Check this box to enable the OpenID 2.0 protocol.

  • Validate ReturnTo URL using XRDS metadata - Check this box to verify the ReturnTo URL (which is the URL to which the server redirects once the authentication is processed) using the XRDS.

  • Validate ReturnTo URL using Realm - Check this box to specify that the IdP should validate the ReturnTo URL present in the OpenID authentication request using the realm.

  • Enabled Session Types - If validating ReturnURL using realm, check the boxes to enable specific session types or All to enable all session types.

  • Default Session Type - If validating ReturnURL using realm, use the drop-down to select the default session type. Any of the enabled session types may be selected.

  • Enable Association Session Types - Lists the enabled association types that the OpenID provider supports:

    • No encryption

    • Diffie-Hellman SHA1

    • Diffie-Hellman SHA256

  • Default Association Session Type - Specifies the default association session type.

    Note:

    Changes in session type and/or association session type require restart of the Oracle Identity Federation server.

  • Association Timeout (sec) -This is the duration of validity of the association in seconds.

  • Force User Consent to create new Federated Identity - Check this box to force consent for setting up a new federation.

  • Force User Consent for all Single Sign-On Operations - Check this box to force consent for SSO.

  • Force User Consent for Single Sign-On Operations with attributes exchange - Check this box to prompt the user for consent any time an SSO operation is being performed between Oracle Identity Federation/IdP and the RP, where user attributes will be released to the RP.

    Related fields for this feature:

    • Force User Consent Web Context - Contains the Web Context of the OpenID consent page to be used instead of the Oracle Identity Federation OpenID built-in consent page. If filled, it will reference a user-implemented page on Oracle WebLogic Server.

    • Force User Consent Web Path

  • Enable Attribute Exchange (AX) 1.0 - Check this box to enable the AX extension.

  • Enable PAPE 1.0 - Check this box to enable the PAPE 1.0 extension. With this feature you can specify one or more of:

    • US Government Level of Assurance Policy

    • PPID Policy

    • US Government OpenID Trust Level 1 Policy

    • US Government No PII Policy

  • Generic OpenID Service Provider

    Oracle Identity Federation lets you define the OpenID RP as:

    • a federated partner for which you can define specific settings

    • an unknown RP with general attribute mappings

    Click Create to define a generic OpenID RP.

5.4.5 Configure an External OpenID Provider

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

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

Take the following steps to configure an external OpenID provider:

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

  2. Navigate to the Oracle Identity Federation instance.

  3. Select Administration, then Federations.

  4. Click Add to add a new OpenID provider.

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

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

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

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

  9. Click OK to create the provider.

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

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

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

  11. Click Apply to commit the edits.

This procedure follows the basic steps for configuring a provider as shown in Section 4.3.2, "Add Trusted Providers".

5.5 Configuring Service Providers

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

5.5.1 Configure Service Provider - Common Properties

Use this table to configure SP properties common to all protocols.

Surrounding text describes oifspcom.gif.

Assertion Settings

  • Enable Map Assertion to User Account - Check this box if you wish Oracle Identity Federation to map the assertion to a user account. Disable it if you wish to implement a custom SP Engine to do the mapping instead.

  • Anonymous User ID - Enter the User ID that will be passed to the SP engine if the assertion received cannot be mapped to a user account, either because mapping assertions to user accounts is disabled or the format of the Name ID in the assertion is 'transient'.

  • Ignore Unknown Condition - Check this box to have the service provider ignore any conditions it does not recognize in the assertion sent by the identity provider.

  • Require Signed Assertions - Check this box to require assertions received from identity providers to be signed.

Protocol Settings

  • Default SSO Identity Provider - Select the identity provider to which requests should be sent as a default when an SSO operation is initiated and no preferred identity provider is specified.

  • Unsolicited SSO RelayState - 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.

  • Include Signing Certificate in XML Signatures - check this box to have Oracle Identity Federation include the signing certificate in the signature when signing XML messages.

  • Enable Identity Provider Discovery Service

    Oracle Identity Federation provides a service, called the Identity Provider Discovery Service, in which the user can be redirected to a custom page in which he can select the identity provider from which he wishes to authenticate.

    Check this box to enable the Identity Provider Discovery Service, and enter the Service URL of the custom page where the user can select the identity provider to be used.

  • Enable Common Domain Cookie Service

    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 this box to specify that this SP should read the introduction cookie, and enter the Service URL where Oracle Identity Federation will read the introduction cookie.

  • Enable Attribute Requester Service - check this box to enable this service provider to act as an Attribute Requester.

    Note:

    This property affects server metadata. When updating this property, distribute the updated metadata to all trusted providers.

Configure Attribute Requester Service

Surrounding text describes spattreq.gif.
  • Default Attribute Authority - Select the attribute authority to which Attribute Queries should be sent to as a default, when no attribute authority is specified in the request.

  • DN Pattern to Attribute Responder Mappings - Use this table to map User DN patterns to attribute authorities. When sending an attribute query for a given user, Oracle Identity Federation will look at the user's DN, match it to a pattern on this table, and send the attribute query to the corresponding attribute authority. If no pattern matches the user's DN, the default attribute authority is used.

    By default, the DN pattern is case-sensitive, and case is considered in comparing the user DN to the DN pattern. You can make the comparison case-insensitive by using the WLST configuration command:

    setConfigProperty ('dnidpmapping','caseinsensitive','true','boolean')
    

    Use true for case-insensitive comparison, false for case-sensitive comparison.

Identity Providers for SSO Authentication Mechanism

Use this table to map authentication mechanisms to identity providers. When an SSO operation is initiated and no identity provider is specified, Oracle Identity Federation will look at this table to map the requested authentication mechanism to an identity provider and send the AuthnRequest to this identity provider. If the authentication mechanism cannot be mapped to an identity provider, the default SSO identity provider will be used.

Surrounding text describes oifspcomssoadd.gif.

5.5.2 Configure SAML 2.0 SP Properties

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

Assertion Settings

Surrounding text describes oifspsaml20.gif.

Choose one of these methods of assertion mapping by checking the associated box:

  • Federated Identity

  • Attribute Query

  • Subject NameID

If mapping users through federated identity, check the box labeled Enable Auto Account Linking.

If mapping users through attribute query, enter the query string in the associated box.

If mapping users through subject NameID, check the box and select the applicable NameID formats from the table titled Assertion Subject NameID Formats. Provide this information in the table:

  • Check the corresponding Enabled box to enable the desired format(s) that the Oracle Identity Federation instance will support in SP 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 5-4 SAML 2.0 SP Name ID Formats

    NameID Format Default

    X.509 Subject Name

    dn

    Email Address

    mail

    Windows Domain Qualified Name

    empty

    Kerberos Principal Name

     

    Custom

    empty

    Unspecified

    empty


Name of the Custom Format - When processing an assertion, this is the name of the format that will be mapped to the custom NameID format type.

Additionally, you can check Error when User Mapping Fails to indicate how Oracle Identity Federation should handle mapping errors.

Protocol Settings

Surrounding text describes oifspsaml20prot.gif.

Provide the following information:

  • Enable SAML 2.0 Protocol - Check the box to enable this protocol for the SP.

  • Enable Single Sign-On Protocol - Check the box to enable the single sign-on protocol.

  • Enable NameID Management Protocol: Register - Check the box to enable NameID registration.

  • Enable Federation Termination Protocol - Check this box to enable the federation termination protocol.

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

  • Send Encryption NameIDs - Check this box to enable Oracle Identity Federation to send encrypted name identifiers to peer providers.

  • Send Encryption Attributes - Check this box to enable Oracle Identity Federation to send encrypted attributes to peer providers.

  • Allow Federation Creation - Check this box to allow federation creation. This is required if you configure the SP to request persistent NameID format as described below.

  • 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:

    See Also:

    Section 5.4.1, "Configure SAML 2.0 IdP Properties" for an example showing how the query parameters are used.

    Table 5-5 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.


  • Enable Protocol Bindings - Specify the valid bindings using the drop-down list.

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

    • HTTP Redirect

    • HTTP POST

    • HTTP Post Simple Sign

    • 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

    • HTTP Post Simple Sign

  • Default SSO Response Binding - Specifies the preferred binding for the identity provider to use, when possible, in sending an assertion to the service provider. Valid values are:

    • Artifact

    • HTTP POST

    • HTTP POST Simple Sign

  • Default Authentication 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

    If the default authentication request NameID format at the SP is unspecified, the IdP will use the default assertion NameID format when creating the assertion (for example, email NameID format).

  • Request Authentication Context Mechanism - Use this list box to select the authentication mechanism that this service provider will specify in the AuthnRequest to the identity provider.

  • Request Authentication Context Comparison - Use the list box to select the authentication context comparison that this service provider will specify in the AuthnRequest sent to the identity provider.

  • Messages to Send/Require Signed

    Use this table when configuring a service provider to specify which message types that provider should send signed and/or require signed.

Notes:

  • The Require Signed Assertion property affects server metadata. When updating this property, distribute the updated metadata to all trusted providers.

  • If you configure the SP to request Persistent NameID format (or if it expects to receive Persistent from the IdP in case the SP does not specify a format), then the SP has to be configured to allow federation creation.

  • Although your configuration changes are saved when you click Apply, at least one of the protocol boxes must also be checked to ensure that the changes on this page are effective.

5.5.3 Configure SAML 1.x SP Properties

Use this tab to specify configuration details for Oracle Identity Federation SAML 1.x domains.

Assertion Settings

Select one of these mapping choices:

  • Map User via Attribute Query - Check the box and enter an attribute query.

  • Map User via NameID - Check the box and select the applicable NameID formats from the table titled Assertion Subject NameID Formats.

Additionally, you can check Error when User Mapping Fails to indicate how Oracle Identity Federation should handle mapping errors.

Surrounding text describes oifspsaml1x.gif.

To Use the Table of Assertion Subject NameID Formats

If you selected assertion mapping through subject NameIDs, provide this information in the table:

  • Check the corresponding Enabled box to enable the desired format(s) that the Oracle Identity Federation instance will support as SAML 1.1/1.0 name identifier formats in SP mode.

  • NameID Format - This column displays the available SAML 1.x 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 5-6 SAML 1.1/1.0 SP Name ID Formats

    NameID Format Default

    X.509 Subject Name

    dn

    Email Address

    mail

    Windows Domain Qualified Name

    empty

    Unspecified

    empty

    Custom

    empty


Protocol Settings

Provide the following information:

  • Enable SAML 1.1 Protocol - Check the box to enable this protocol for the SP.

  • Enable SAML 1.0 Protocol - Check the box to enable this protocol for the SP.

  • Enable Protocol Bindings - Use the drop-down to select the binding to use.

  • Messages to Send/Require Signed - Use this table when configuring a service provider to specify which message types that provider should send signed

Note:

Although your configuration changes are saved when you click Apply, at least one of the protocol boxes must also be checked to ensure that the changes on this page are effective.

5.5.4 Configure WS-Federation 1.1 SP Properties

Use this page to configure Oracle Identity Federation to use the WS-Federation 1.1 protocol when acting as a service provider.

Surrounding text describes oifspwsfed.gif.

Provide the following information:

  • Enable WS-Federation 1.1 Protocol - Check the box to enable WS-Federation 1.1 protocol for the provider.

  • Request Authentication Context Mechanism - Use the drop-down to select the authentication mechanism that will be sent in the authentication request to the identity provider.

Click Apply to save your changes, or Revert to restore the screen to its previous values.

5.5.5 Configure OpenID SP Properties

Use this page to configure the OpenID protocol in SP mode.

Surrounding text describes spopenid.gif.

Assertion Settings

The assertion setting fields are as follows:

  • Map User via Federated Identity - Check this box to specify that the RP will use federated identities to map the incoming assertion to a user record. If not checked, user lookup is based on the assertion data.

  • Enable Auto Account Linking - Check this box to specify that the RP/SP should try to map the incoming assertion to a user record when the federated identity does not exist. The mapping uses the assertion data.

  • Map User via Attribute Query - Check to enable assertion-to-user mapping through LDAP/RDBMS query, and use the associated Attribute Query field.

  • Error when user Mapping fails - Check this box to display a 401 error if mapping of the incoming assertion to a user record using the assertion data fails. If not checked, the RP invokes the authentication engine to authenticate, identify, and provision the user, and the operation resumes after return from the authentication engine. (Note: The authentication mechanism configured for the SP that started the flow determines which authentication engine is invoked).

  • Require Signed Assertions - Indicates whether the RP/SP requires the incoming assertion to be signed.

Protocol Settings

The protocol setting fields are as follows:

  • Enable OpenID 2.0 Protocol - Check this box to enable the OpenID 2.0 protocol.

  • Perform OpenID Provider Discovery - Check this box to specify that the RP should discover the OP from discovery URL to initiate the SSO operation. Discovery will determine the features supported by the OP and create the authentication request accordingly. If discovery is disabled, the OpenID provider SSO URL must be specified and the authentication request format is based solely on the RP configuration.

  • Force User Consent - Check this box to prompt the user for consent for any new federation (that is, new ClaimedID) created between the IdP/OP, the RP/SP and the user.

  • Default Authentication Mechanism - Holds the local authentication mechanism to use as the authentication method to authenticate the user at the IdP/OP, if the assertion uses the PAPE authentication policy.

  • Enabled Session Types - Use the drop-down to list the enabled session types that can be used during the association exchange. Possible values:

    • no-encryption

    • dh-sha1

    • dh-sha256

  • Enabled Association Session Types - Use the drop-down to list the enabled association types that the OP supports. Possible values:

    • hmac-sha1

    • hmac-sha256

  • Default Association Session Type - Specify the default association session type from one of the enabled types.

    Note:

    Changes in session type and/or association session type require restart of the Oracle Identity Federation server.

  • Force User Consent - Check the box to prompt the user for consent for any new federation (that is, new ClaimedID) created between the OP, the RP, and the user.

  • Force User Consent Web Context - Contains the Web context of the OpenID consent page to be used instead of the Oracle Identity Federation OpenID built-in consent page.

  • Generate Diffie-Hellman parameters when initiating associations - Check the box to generate Diffie-Hellman parameters when initiating association of types DH-SHA1 or DH-SHA256. If not checked, default values are used.

  • Enable PAPE 1.0 - Check this box to enable the PAPE 1.0 extension. With this feature you can specify one or more of:

    • US Government Level of Assurance Policy

    • PPID Policy

    • US Government OpenID Trust Level 1 Policy

    • US Government No PII Policy

5.6 Configuring Attribute Sharing with the Oracle Access Manager AuthZ Plug-in

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 with 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:

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

SP components include:

  • 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 Plug-in - passes the certificate SubjectDN to the authz_attribute authorization plug-in

    • authz_attribute Authorization Plug-in - 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 plug-ins use the same authz_attribute library.

  • Oracle Identity Federation Attribute Requester Service - sends a SAML 1.x or 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 plug-in.

IdP Component

Oracle Identity Federation Attribute Responder Service or other SAML 1.x or SAML 2.0-compliant federation product - receives a SAML 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.

5.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 plug-in, 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.

5.6.3 Configuring the Oracle Access Manager Plug-ins

Take these steps to configure the Oracle Access Manager plug-ins:

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service 10g for details about the Web-based user interface.

  1. Log in to the Access Server host as the user who installed the Access Server.

  2. Create the directory INSTALLDIR/oblix/config/attributePlug-in, if it does not already exist.

  3. Edit or create the config.xml file in the INSTALLDIR/oblix/config/attributePlug-in 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

Here is a 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:7499/fed/ar/soap">
        <DN>O=PeerA,C=US</DN>
        <DN>O=PeerB,C=US</DN>
    </Mapping>
    <Mapping URL="https://fed2.company.com:7499/fed/ar/soap" 
      RequestFormat="all">
        <DN>O=PeerC,C=US</DN>
        <DN>O=PeerD,C=US</DN>
    </Mapping>
    <Mapping URL="https://fed3.company.com:7499/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_plug-in_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 plug-in 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 plug-in 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 Oracle Identity Federation.

      For example: https://fed1.company.com:7499/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.

Table 5-7 Mapping Examples for config.xml

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:7499/fed/ar/soap

E=sally.smith@peerd.com,CN=Sally Smith,OU=Marketing,O=PeerD,C=US

https://fed2.company.com:7499/fed/ar/soap

E=bill.jones@peerx.com,CN=Bill Jones,OU=Finance,O=PeerX,C=US

https://fed3.company.com:7499/fed/ar/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 plug-in and at least one Attribute Requester Service, set up the trusted CA list in INSTALL_DIR/oblix/config/attributePlug-in/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 plug-in 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/attributePlug-in/key.pem -out../../config/attributePlug-in/req.pem

    • Send INSTALL_DIR/oblix/config/attributePlug-in/req.pem to your CA to get a certificate.

    • Copy the generated certificate to INSTALL_DIR/oblix/config/attributePlug-in/cert.pem.

  3. Restart the Access Server to ensure that the plug-in uses the PEM files.

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

5.6.4.1 Configuring the Attribute Sharing Authentication Scheme

Take these steps:

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service 10g for details about the Web-based user interface.

  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 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 plug-ins are configured)

    Click Save and commit the changes.

  3. Select the Plug-ins tab and click Modify. Add the plug-ins and parameters shown in the table. To enter built-in plug-ins, select the plug-in name from the drop-down list.To enter custom plug-ins, select Custom Plug-in from the drop-down list and enter the plug-in name in the text box. Click Save when all plug-ins have been added.

    Plug-in Name Type Plug-in 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:

    Plug-in Name Plug-in 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 Plug-ins 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 plug-in 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.

5.6.4.2 Configuring the Attribute Sharing Authorization Scheme

Take these steps to configure the attribute sharing authorization scheme:

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for details about the Web-based user interface.

  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

    • Plug-in 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 plug-in.)

    • Required Parameter

      • Name: ruleExpression

      • Value: (none) (Note: Each access policy authorization rule will supply the rule expression.)

    • Click Save to commit the changes.

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

      • Name: as appropriate (for example, Peer Marketing VP)

      • Description: as appropriate

      • Authorization Scheme: OIF Attribute Sharing

    • Select the Plug-in Parameters panel, click Modify, and set the ruleExpression parameter as specified in the table. Note: White space is allowed around =, !=, &, and |.

      Element Syntax Meaning

      none

      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, then Delegate Administration, then 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.

5.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. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Enable the Attribute Requester functionality:

    • Navigate to Administration, then Service Provider.

    • Check the Enable Attribute Requester Service box, and click Apply.

    Note:

    Checking the Enable Attribute Requester Service box enables the Attribute Requester feature. It also modifies the SP's metadata to include information about the Attribute Requester service. Note that the metadata at the peer providers' sites must be updated with the new version.

  3. Upload the SAML 1.x or SAML 2.0 IdP metadata, or manually create an entry for a SAML 1.x provider.

    • Navigate to Administration, then Federations.

    • Click Add.

    • To upload SAML 1.x or SAML 2.0 metadata, select Upload Metadata and enter the location of the IdP metadata and an additional description.

    • To add a SAML 1.x provider manually, select Add Trusted Provider Manually, and enter the Provider ID, the Provider Version (SAML 1.1 or SAML 1.0), select Identity Provider and Attribute Responder as the Provider Type, and enter an additional description.

    • Click OK.

  4. Configure the DN to IdP mapping:

    • Navigate to Administration, then Service Provider.

    • Click Configure Attribute Requester Service.

    • Select the Default Attribute Authority from the drop down list, and click Apply.

    • To add a mapping:

      • Click Add.

      • 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 OK.

  5. Enable and configure certificate Validation:

    • Navigate to Administration, then Security and Trust.

    • Select Enable Certificate Validation, and click Apply.

    • Add Trusted CAs or CRLs by clicking Add in the corresponding table and selecting the location of the CA or the CRL. (Note: if certificate Validation is enabled, a Trusted CA is required to validate signatures).

    Note:

    Configuring DN to IdP and certificate Validation is optional.

  6. If using SAML 2.0, enable encryption:

    • Navigate to Administration, then Service Provider.

    • In the SAML 2.0 tab, under Protocol Settings:

      • Check Send Encrypted NameIDs to encrypt the Name Identifiers in the AttributeQuery to the Attribute Responder.

      • Check Send Encrypted Attributes to encrypt the Attributes in the AttributeQuery to the Attribute Responder.

    • Click Apply.

    Note:

    Encryption is optional.

  7. The Attribute Requester service is available at http://sp-hostname:port/fed/ar/soap.

After enabling the attribute requester capabilities and setting the Default Attribute Authority and/or the DN Mappings, you must configure the attribute name mappings and the attribute value mappings. See Section 5.9.2, "Mapping and Filtering Configuration" for more information.

Additional topics include:

5.6.5.1 If Using HTTP Basic Authentication With OHS

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

$ORACLE_HOME/ohs/bin/htpasswd -c /private/oifpassword alice

5.6.5.2 If Using HTTP Basic Authentication Without OHS

If using HTTP Basic Authentication without Oracle HTTP Server, see Section 6.9.2, "HTTP Basic Authentication".

5.6.5.3 If Using SSL Client Authentication

If using client certificate authentication, see Section 8.1, "Configuring SSL for Oracle Identity Federation".

5.6.6 Configuring Oracle Identity Federation as an IdP Attribute Responder

Take these steps:

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Enable the Attribute Responder functionality:

    • Navigate to Administration, then Identity Provider.

    • In the SAML 2.0 or SAML 1.x tab, select Enable Attribute Query Responder. If using SAML 2.0, select Use Identity Federation for Attribute Response if you want the user in the attribute request to be located in the IdP using its federated identity. Note that if using this setting, the user must have a federation identity and its Name ID value and format must match the subject value and format specified in the AttributeQuery.

    • Click Apply.

    Note:

    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.

  3. Map the Name ID Formats:

    • Navigate to Administration, then Identity Provider.

    • In the SAML 2.0 tab, under Assertion settings, check that the subject formats to be used are 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.

    • Click Apply.

  4. Upload the SAML 1.x or SAML 2.0 IdP metadata, or manually create an entry for a SAML 1.x provider

    • Navigate to Administration, then Federations.

    • Click Add

    • To upload SAML 1.x or SAML 2.0 metadata, select Upload Metadata and enter the location of the IdP metadata and an additional description.

    • To add a SAML 1.x provider manually, select Add Trusted Provider Manually, and enter the Provider ID, the Provider Version (SAML 1.1 or SAML 1.0), select Service Provider and Attribute Requester as the Provider Type, and enter an additional description.

    • Click Apply.

  5. Configure the Attribute Mappings for the SP Attribute Requester:

    • Navigate to Administration, then Federations.

    • Select the SP Attribute Requester entry and click Edit.

    • Select Update Manually, and under Oracle Identity Federation Settings, click Edit Attribute Mappings and Filters.

    • To add an attribute mapping:

      • Click Add.

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

      • Enter the Format or Namespace, if any. This is an optional field used to specify the format or the namespace of the SAML attribute, depending on the version.

        - For SAML 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.

      • Repeat the operation to add other attribute mappings.

    • Click OK.

    Note:

    For an SP using Oracle Identity Federation, the assertion Attr Name is determined by the attribute name in a ruleExpression as set in Section 5.6.4.3, "Configuring an Oracle Access Manager Policy using Attribute Sharing". The attribute names must be agreed upon between the IdP and SP.

  6. Enable and configure certificate validation:

    • Navigate to Administration, then Security and Trust

    • Select Enable Certificate Validation, and click Apply.

    • Add Trusted CAs or CRLs by clicking Add in the corresponding table and selecting the location of the CA or the CRL. (Note: if certificate Validation is enabled, a Trusted CA is required to validate signatures).

    Note:

    Configuring certificate Validation is optional.

  7. If using SAML 2.0, enable encryption:

    • Navigate to Administration, then Service Provider.

    • In the SAML 2.0 tab, under Protocol Settings:

      • Check Send Encrypted NameIDs to encrypt the Name Identifiers in the AttributeQuery to the Attribute Responder.

      • Check Send Encrypted Attributes to encrypt the Attributes in the AttributeQuery to the Attribute Responder.

    • Click Apply.

    Note:

    Encryption is optional.

After enabling the attribute responder capability, you must configure:

  • which attributes to send

  • attribute name mappings

  • attribute value mappings

  • attribute value filters

See Section 5.9, "Configuring Attribute Mapping and Filtering" for more information.

5.6.7 Configuring Oracle Identity Federation for SSL

To configure SSL for the server, see Section 8.1, "Configuring SSL for Oracle Identity Federation".

5.7 Configuring Identity Provider to send attributes in SSO Assertions

During a Single Sign-On operation, the identity provider 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. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Federations.

  3. Select the service provider with which you want to configure attribute sharing, and click Edit.

  4. Select Update Manually.

  5. Under the Oracle Identity Federation Settings tab, check Enable Attributes in Single Sign-On.

  6. Below, check the boxes to specify the Name ID formats for which attributes will be sent in assertions.

  7. Click Apply.

After checking the Enable Attributes in Single Sign-On box, you need to configure:

See Section 5.9, "Configuring Attribute Mapping and Filtering" for more information.

5.8 Web Services Interface for Attribute Sharing

This section describes the Oracle Identity Federation's Attribute Requester Service Interface. It contains these topics:

5.8.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 <AttributeQuery> convention.

The service can be invoked to send samlp:AttributeQuery messages to a remote identity provider.

Here are the steps 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 AttributeQuery, based either on the IdP specified on the Request, or on the Subject contained in the AttributeRequest.

  3. Oracle Identity Federation applies, for the specific remote IdP, the attribute value mapping for the optional attribute values listed in the AttributeRequest.

  4. Oracle Identity Federation applies, for the specific remote IdP, the attribute 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.

5.8.2 Attribute Request Message

The AttributeRequest message issues a request for attribute data about a user. The AttributeRequest specifies these inputs:

  • The Subject: A string representing the user. This is a required input.

  • The Subject Format: A URI specifying how the Subject string represents the user. If not present, format "oracle:security:nameid:format:x509" will be used. Valid formats are:

    • oracle:security:nameid:format:x509: Indicates that the Name ID is the Subject DN.

    • oracle:security:nameid:format:entity: Indicates that the Name ID is the identifier of an entity that provides SAML services. This Name ID Format only applies to the SAML 2.0 protocol.

    • oracle:security:nameid:format:emailaddress: Indicates that the Name ID is in the form of an email address.

    • oracle:security:nameid:format:windowsdomainqualifiedname: Indicates that the Name ID is a Windows domain qualified name (A Windows domain qualified name is a string of the form "DomainName\UserName", where the DomainName and "\" can be omitted).

    • oracle:security:nameid:format:kerberos: Indicates that the Name ID is in the form of a Kerberos principal name using the format name[/instance]@REALM. This Name ID Format only applies to the SAML 2.0 protocol.

    • oracle:security:nameid:format:persistent: Indicates that the Name ID is a persistent opaque identifier for the user that is specific to an IdP and SP. This Name ID Format only applies to the SAML 2.0 protocol.

    • oracle:security:nameid:format:transient: Indicates that the Name ID is an opaque and temporary identifier for the user. This Name ID Format only applies to the SAML 2.0 protocol.

    • oracle:security:nameid:format:unspecified: Indicates that the interpretation of the Name ID is left up to the implementation.

    • oracle:security:nameid:format:custom: Indicates that the Name ID is a custom value.

    • oracle:security:nameid:format:userid: Indicates that the Name ID is the User ID used by Oracle Identity Federation to identify the user.

    Note:

    To enable/disable Name ID formats and map them to attributes in the user data store, follow these steps:

    1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance

    2. Navigate to Administration, then Identity Provider or Service Provider (to configure IdP and SP, respectively).

    3. In the SAML 2.0/SAML 1.X tabs, modify the Assertion Subject NameID Formats by:

      1. Clicking the Enabled box next to the formats you wish to enable.

      2. Mapping each format to an attribute in the user data store.

    4. Click Apply.

  • The attribute authority to which the AttributeQuery is to be sent. If no attribute authority is specified, Oracle Identity Federation will determine what attribute authority to send the AttributeQuery as follows:

    • If the Subject Format is "oracle:security:nameid:format:x509", or if it is not present, Oracle Identity Federation will map the Subject value to an identity provider. If no mapping is found for the SubjectDN, the default attribute authority is used.

    • Otherwise, Oracle Identity Federation will use the default attribute authority.

    See Also:

    Section 5.6.5, "Configuring Oracle Identity Federation as an SP Attribute Requester" for instructions on how to configure the default attribute authority and the SubjectDN to IdP mappings

  • Zero or more attributes to be retrieved for the user.

  • For each attribute, zero or more values. A NULL value can be represented as <Value Null="true"/>.

The AttributeRequest message is wrapped in a SOAP Envelope and Body and sent in an HTTP POST request. Examples of AttributeRequest messages follow.

Example 1

In the following request, the Subject format is not specified and is therefore assumed to be "oracle:security:nameid:format:x509". The target IdP is also not specified and so Oracle Identity Federation will determine the attribute authority to use by mapping the SubjectDN to an IdP.

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

Example 2

In the following request, the target IdP is specified to be "http://my-corp.com/fed/idp", so Oracle Identity Federation will send the AttributeQuery to this attribute authority. Also, the Subject Format is "oracle:security:nameid:format:userid", so the Subject value "alice" is taken to be the User ID of the user of which attributes are requested.

<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 TargetIDP="http://my-corp.com/fed/idp">
         <orafed-arxs:Subject Format="oracle:security:nameid:format:userid">alice
         </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 <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.

  • If values are specified in the request, the attribute authority will only return a local attribute value if the value is present in the request.

  • Attributes are returned subject to the responder's local policy.

5.8.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 1.x or SAML 2.0 query (Success or Failure, with the reason). The client can use this information for logging.

  • the Subject, as specified in the Request

  • the Subject Format, as specified in the Request

  • 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 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 following attribute responses could correspond to the attribute requests in the examples above:

Example 1

<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="lastname">
            <orafed-arxs:Value>Appleton</orafed-arxs:Value>
         </orafed-arxs:Attribute>
         <orafed-arxs:Attribute Name="firstname"></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>

Example 2

<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 Format="oracle:security:nameid:format:userid">alice
         </orafed-arxs:Subject>
         <orafed-arxs:Attribute Name="lastname">
            <orafed-arxs:Value>Appleton</orafed-arxs:Value>
         </orafed-arxs:Attribute>
         <orafed-arxs:Attribute Name="firstname"></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>

5.8.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:complexType name="SubjectType">
                            <xs:simpleContent>
                                <xs:extension base="xs:string">
                                    <xs:attribute name="Format" type="xs:string"/>
                                </xs:extension>
                            </xs:simpleContent>
                        </xs:complexType>
                        <xs:element name="Subject" type="orafed-arxs:SubjectType"/>
 
                        <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:attribute name="Name" type="xs:ID"/>
                           <xs:sequence>
                              <xs:element ref="orafed-arxs:Value"
minOccurs="0" maxOccurs="unbounded"/>
                           </xs:sequence>
                        </xs:complexType>
                        <xs:element name="Attribute" type="orafed-arxs:AttributeType"/>
 
                        <xs:complexType name="AttributeRequestType">
                <xs:attribute name="TargetIDP" type="xs:string"/>
                                <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://node.us.example.com:1234/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).

5.9 Configuring Attribute Mapping and Filtering

This section explains how to configure the attribute mapping functionality in Oracle Identity Federation. It contains these topics:

5.9.1 Introduction to Attribute Mapping and Filtering

Supported Entities

Oracle Identity Federation supports attribute mapping for the following:

  • Attribute Authority

  • Attribute Requester

  • Identity Provider, when sending attributes in SSO assertions

Mapping Capabilities

Oracle Identity Federation provides the following attribute mapping capabilities:

  • Attribute Name Mapping: maps local attribute names to external attribute names used in SAML messages

  • Attribute Value Mapping: maps local attribute values to external attribute values used in SAML messages

  • Attribute Value Filtering: filters local attribute values by sending only allowed values in assertion messages

Note:

In 11g Release 1 (11.1.1), all attribute mapping and filtering is available only as per-peer-provider configuration, not at the global level.

Attribute Sources

Oracle Identity Federation can map attributes to an outgoing assertion from these sources:

  1. user sessions

  2. user data stores

  3. static values from the Oracle Identity Federation configuration

This section contains these topics:

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

  • Attribute Authority

  • Attribute Requester

  • Identity Provider, when sending attributes in SSO assertions

Attribute name mapping is configured through the Fusion Middleware Control Console. See Section 5.9.2.1, "Configuring Attribute Name Mapping" for details.

5.9.1.1.1 Static Attribute Value

You can map a static attribute value (for example., DeploymentVersion=6.4) from the Oracle Identity Federation configuration to an outgoing assertion.

The feature is implemented with two properties for an existing attribute name mapping definition:

  • from-config, a boolean

  • attribute-value-fromconfig

If from-config is true, and if that attribute needs to be included in an outgoing assertion, the value stored in attribute-value-fromconfig is placed in the outgoing assertion.

If from-config is false, the value set for the attribute in Fusion Middleware Control is used.

The steps involve creating an attribute name mapping definition to the list of attribute mappings, and setting these properties:

  • the internal name of the attribute, referenced by datastore-attr

  • the name of the attribute as it will appear in the assertion, referenced by assertion-attr

  • the format or namespace of the SAML attribute (which can be blank), referenced by format-attr

  • a flag referenced by send-with-sso indicating whether the attribute should be sent in an SSO assertion

  • a flag referenced by from-session indicating whether to retrieve the attribute value from the Oracle Identity Federation user session,

  • a flag referenced by from-config indicating whether the attribute value is static

  • a property referenced by attribute-value-fromconfig containing the static value

The WLST commands to configure static attribute mapping are as follows:

Note:

You must replace the sample host:port, map name, and static values used in this example with valid values.

  • Create an attribute name mapping definition for an attribute - with local name set to cn and assertion name set to commonName - for providerid http://myhost.domain.com:7499/fed/sp, if it does not already exist:

    createFederationPropertyMap('http://myhost.domain.com:7499/fed/sp',
    
    'attributelist')
    createFederationPropertyMapInMap('http://myhost.domain.com:7499/fed/sp','attributelist','cncommonName')
    
  • Add the new set of properties for the attribute, if they do not already exist, using these guidelines. (These properties are added to the previously created element.)

    Note:

    When creating a mapping from scratch, you must also include the attribute "require-from-infocard".

    Property Set to

    datastore-attr

    cn

    assertion-attr

    commonName

    format-attr

    empty value

    send-with-sso

    true (always send the attribute with SSO assertions) or false (do not send attribute)

    from-session

    true (retrieve the attribute value from the Oracle Identity Federation user session) or false (do not retrieve value)

    from-config

    true (attribute has a static value) or false

    attribute-value-fromconfig

    static value if needed


    For example:

    addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'datastore-attr', 'cn', 'string')
    
    addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'assertion-attr', 'commonName', 'string')
    
    addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'format-attr', '', 'string')
    
    addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'send-with-sso', 'true', 'boolean')
    
    addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'from-session', 'false', 'boolean')
    
    addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'from-config', 'true', 'boolean')
    
    addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'attribute-value-fromconfig', 'cn=users,dc=oracle,dc=com', 'string')
    

    Here is another example that includes the "require-from-infocard" property:

    addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'require-from-infocard', 'true', 'boolean')
    
  • To remove a property and the corresponding map for the attribute:

    removeFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp',
    
    'attributelist','cncommonName','attribute-value-fromconfig')
    
    removeFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp',
    
    'attributelist','cncommonName','from-config')
    
    removeFederationMapInMap('http://myhost.domain.com:7499/fed/sp',
    
    'attributelist','cncommonName')
    

5.9.1.2 Attribute Value Mapping

Attribute value mapping allows the administrator to specify the value that a local attribute should be assigned in a 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:

  • Attribute Authority

  • Attribute Requester

  • Identity Provider, when sending attributes in SSO assertions

Attribute value mapping is configured through the Fusion Middleware Control Console. See Section 5.9.2.2, "Configuring Attribute Value Mapping" for details.

5.9.1.3 Attribute Value Filtering

Attribute value filtering allows the administrator to specify which local values are allowed when sending a 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 Section 5.9.2.3, "Configuring 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

Oracle Identity Federation exercises attribute value filtering when acting as a:

  • Attribute Authority

  • Identity Provider, when sending attributes in SSO assertions

You configure this feature through the Fusion Middleware Control Console. See Section 5.9.2.3, "Configuring Attribute Value Filtering" for details.

5.9.2 Mapping and Filtering Configuration

This section explains how to configure mapping and filtering:

5.9.2.1 Configuring Attribute Name Mapping

Configuration of attribute name mapping serves these purposes:

On the IdP side:

  • mapping attribute names contained in assertions to local attribute names

  • determining which local attributes can be sent to the peer provider. Defining an attribute name mapping for a peer provider will authorize Oracle Identity Federation to send this attribute to the remote server.

On the SP side:

  • mapping attribute names contained in SOAP client requests to names in attribute queries to the attribute authority

Take these steps to define attribute name mappings:

On the IdP Side

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Federations.

  3. Select the Attribute Requester with which you want to configure attribute sharing, and click Edit.

  4. Click Edit Attribute Mappings and Filters.

  5. Under the Name Mappings tab, click Add to add an attribute name mapping, with the following fields:

    • User Attribute Name: The name of the local attribute in the user repository. If the UserID should be mapped to the assertion attribute, set this to "orafed-userid".

    • Assertion Attribute Name: The name that will be used to identify the attribute in the Attribute Query and assertion

    • Format or Namespace: An optional field used to specify the format or the namespace of the SAML attribute, depending on the version.

      • For SAML 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 in the assertion during an SSO operation.

      Note:

      In order for the identity provider to send an attribute to a peer provider, a mapping for this attribute must be defined as explained above.

    • Get Value from User Session: Indicates whether the attribute value should be obtained from the user session.

    • Require from Infocard: Indicates whether the attribute must be passed in from Infocard.

On the SP Side

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Federations.

  3. Select the attribute authority with which you want to configure attribute sharing, and click Edit.

  4. Select Update Manually; under Oracle Identity Federation Settings, click Edit Attribute Mappings and Filters.

  5. Under the Name Mappings tab, click Add to add an attribute name mapping, with the following fields:

    • User Attribute Name: The name used by the SOAP client in the AttributeRequest

    • Assertion Attribute Name: The name that will be used to identify the attribute in the attribute query and assertion

    • Format or Namespace: An optional field used to specify the format or the namespace of the SAML attribute, depending on the version

      • For SAML 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

    • Get Value from User Session: Indicates whether the attribute value should be obtained from the user session.

    • Require from Infocard: Indicates whether the attribute must be passed in from Infocard.

    Note:

    If no mapping is found for an attribute name, the service provider will map the name to itself.

Example

The following attribute name configuration will yield the results shown here.

Name Mapping in SP:

User Attribute Assertion Attribute

phone

telephone

userid

username

email

emailaddress

id

idnumber


Name Mapping in IdP:

Assertion Attribute User Attribute

lastname

sn

idnumber

employeenumber

telephone

telephonenumber

title

title

username

uid

emailaddress

mail

firstname

givenname


Results:

Attribute in SOAP client Request Attribute in SAML Attribute Query Attribute in User Datastore Attribute in SAML Assertion Attribute in Response to SOAP client

lastname

lastname

sn

lastname

lastname

id

idnumber

employeenumber

idnumber

id

phone

telephone

telephonenumber

telephone

phone

title

title

title

title

title

userid

username

uid

username

userid

email

emailaddress

mail

emailaddress

email

firstname

firstname

givenname

firstname

firstname

middlename

middlename

-

-

-


Note that:

  • For attributes lastname, title, firstname, there is no mapping in the SP, so they are mapped to themselves.

  • For attribute middlename, there is no mapping in the IdP, so the IdP does not return any values for this attribute. If the attribute name used in the Attribute Query/assertion is the same as in the user data store, you need to explicitly define a mapping for the attribute name that maps the name to itself, as is done here for attribute title.

5.9.2.2 Configuring Attribute Value Mapping

Take these steps to define attribute value mappings:

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Federations.

  3. Select the peer provider with which you want to configure attribute sharing, and click Edit.

  4. Select Update Manually; under Oracle Identity Federation Settings, click Edit Attribute Mappings and Filters.

  5. Under the Value Mappings tab, click Add to add an attribute value mapping, with the following fields:

    • Attribute Name: The name of the local attribute in the user repository

    • Unmapped Values: Check Send to allow Oracle Identity Federation to send values for which a mapping is not defined. Check Receive to allow Oracle Identity Federation to receive values for which a mapping is not defined.

    • A list of Local to External Value Mappings:

      • Local Value: The local value of the attribute

      • External Value: The corresponding value to send in external messages

      • Ignore Case: If checked, indicates that the string comparison should be case-sensitive when matching attribute values.

      • Local Null: If checked, indicates that the local value equals a null string (different from an empty string "").

      • External Null: If checked, indicates that the external value equals a null string (different from an empty string "").

      • Default: If selected, indicates this local value will be used in case an incoming external value can be mapped to several local values.

Example

This value mappings configuration for the attribute title will yield the following results:

  • Attribute Name: title

  • Unmapped Values:

    • Send: checked

    • Receive: checked

  • Value Mappings:

Local Value External Value Ignore Case Local Null External Null Default

Senior Member of Technical Staff

smts

checked

   

checked

Principal Member of Technical Staff

pmts

checked

     
 

None

 

checked

   

Senior Member of Technical Staff

srmts

checked

     

Consulting Member of Technical Staff

cmts

checked

     

Results:

External Value maps to Local Value

Consulting Member of Technical Staff

cmts

PRINCIPAL MEMBER OF TECHNICAL STAFF

pmts

Principal Member of Technical Staff

pmts

Senior Member of Technical Staff

smts

Vice President

Vice President


Local Value maps to External Value

NULL

None

smts

Senior Member of Technical Staff

srmts

Senior Member of Technical Staff

CEO

CEO


Note that:

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

  • Since Unmapped Values: Send is checked and there is no rule defined for value "Vice President", it is mapped to itself.

  • Since we defined smts to be the default local value for "Senior Member of Technical Staff", "Senior Member of Technical Staff" gets mapped to smts even though srmts also maps to "Senior Member of Technical Staff".

  • A local value of NULL, gets mapped to the string None.

  • Both smts and srmts map to "Senior Member of Technical Staff"

  • Since Unmapped Values: Receive is checked and there is no rule defined for "CEO", it is mapped to itself.

5.9.2.3 Configuring Attribute Value Filtering

Take these steps:

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Federations.

  3. Select the attribute requester with which you want to configure attribute sharing, and click Edit.

  4. Select Update Manually; under Oracle Identity Federation Settings, click Edit Attribute Mappings and Filters.

  5. Under the Value Filters tab, click Add to add an attribute value filter, with the following fields:

    • Attribute Name: The name of the local attribute in the user repository

    • Condition Operator: Select "and" to indicates that all conditions need to be met for an attribute to be sent. Select "or" to indicate meeting one condition is enough to send an attribute.

    • A list of filtering rules with the following fields

      • Condition: The condition that will be used to evaluate the attribute value.

      • Expression: The value or regular expression that will be used to evaluate the attribute value.

      • Ignore Case: If checked, indicates that the string comparison should be case-sensitive when matching attribute values.

5.9.2.3.1 Filtering Conditions

Oracle Identity Federation provides several filtering conditions:

  • equals: the filtering rule will return true if the expression value is equal to the outgoing attribute value.

  • does not equal: the filtering rule will return true if the expression value is different from the outgoing attribute value.

  • starts with: the filtering rule will return true if the outgoing attribute value begins with the expression value.

  • ends with: 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.

  • does not contain: 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.

  • does not equal 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 condition 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:

When the filtering condition is set to regexp, the ignoreCase flag is disregarded during attribute value processing because regular expressions already support case-insensitivity.

Table 5-8 contains some examples illustrating the use of the regexp filtering condition:

Table 5-8 Examples of 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)


5.9.2.3.2 Examples of Value Filters

This section provides some examples of value filter configuration.

Example 1

This value filters configuration for the attribute title, will yield the following results:

  • Attribute Name: title

  • Condition Operator: and

  • Value Filters:

Condition Expression Ignore Case

does not equal

Vice-President

checked

contains

President

checked


Results:

Value Send Value?

Vice-President

no

President

yes

Vice-president

no

Senior Vice-President

yes

   

Example 2

Suppose attribute value mappings are defined as in the example in Section 5.9.2.2, "Configuring Attribute Value Mapping". This value filters configuration for attribute title, will yield the following results:

  • Attribute Name: title

  • Condition Operator: and

  • Value Filters:

Condition Expression Ignore Case

does not equal

mngr

true

ends with

mts

false


Results:

Value Send Value? Value Sent

mngr

no

 

cmts

yes

Consulting Member of Technical Staff


Note that:

  • For a value to be sent, it must not equal mngr, so the value mngr will not be sent.

  • cmts can be sent (all filter conditions evaluate to true), and it is mapped to "Consulting Member of Technical Staff".

  • The same results would apply for the following value filters:

Condition Expression Ignore Case

does not equal

mngr

true

regexp

*mts

 

5.10 Configuring Security and Trust

You use the security and trust pages to configure keystores and certificates for the Oracle Identity Federation server.

To access these pages, start from the Oracle Identity Federation drop-down adjacent to the Topology icon, and navigate to Administration, then Security and Trust.

This section contains these topics relating to trust configuration:

5.10.1 Security and Trust - Wallet

Signing and encryption certificates for this server instance are stored in wallets. Use this page to manage the signing and encryption wallets.

Surrounding text describes oiftrustwallet.gif.

The page shows:

  • The type of the signature wallet; for example, PKCS#12 or JKS.

  • The alias of the signing key in the wallet.

  • The type of the previous signature wallet; for example, PKCS#12 or JKS.

  • The alias of the previous signing key in previous wallet.

  • The type of the encryption wallet; for example, PKCS#12 or JKS.

  • The alias of the encryption key in the wallet.

  • The type of the previous encryption wallet; for example, PKCS#12 or JKS.

  • The alias of the previous encryption key in previous wallet.

Click Update to modify the wallet information. The Update Wallet dialog requires this information for the signing and/or encryption wallet:

  • Wallet Location - You can choose an operating system file containing the wallet.

  • Password - Enter the password that was used to encrypt the private key.

  • Key Password - Only required for JKS and custom Java keystores.

  • Signing Key Alias - the alias under which the private key is stored in the wallet.

5.10.2 Security and Trust - Provider Metadata

Use this page to:

  • specify metadata signing requirements

  • generate updated metadata

Surrounding text describes oiftrustprovmet.gif.

Metadata Signing

Oracle Identity Federation 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 provider metadata in order to upload it to the trusted providers.

Use this section of the page to specify metadata signing. Provide the following information:

  • Require Signed Metadata - Check the box to specify that Oracle Identity Federation must require signed metadata when importing a descriptor to the trusted providers. Thus, peer providers must provide signed metadata to the server.

  • Sign Metadata - Check the box to require the Oracle Identity Federation server to sign its metadata.

  • Validity Period - Enter the validity period in days.

Click Apply to save the changes, or Revert to reset the fields to their previous state.

Generate Metadata

Use this section of the page to generate and distribute metadata to peer providers after making any changes to any server configuration that affects metadata.

  • Provider Type - Select the type from the drop-down list.

  • Protocol - Select a protocol from the drop-down list.

    SAML 1.0, 1.1, and 2.0 protocols are supported for this function.

    Note:

    Liberty 1.x configuration and metadata uploads are available by using the WLST command-line tool.

Click Save to generate and distribute the metadata.

5.10.3 Security and Trust - Trusted CAs and CRLs

Oracle Identity Federation maintains a credential store to hold trusted certificates and CRLs. When the certificate validation store is enabled, Oracle Identity Federation uses it to validate the certificates needed to verify the signatures on incoming SAML/WS-Federation messages.

Use this page to maintain the following objects in the certificate validation store:

  • Certificate Authority (CA) certificates

  • Certificate Revocation Lists (CRLs)

Surrounding text describes oiftrustca.gif.

Provide the following information:

  • Enable Certificate Validation - Check the box to enable the server to validate certificates.

    Click Apply to save the changes, or Revert to reset the field to its previous state.

  • Trusted Certificate Authorities - The table displays details of CAs trusted by Oracle Identity Federation.

    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

    Select a CA and click Delete to remove it from the store. Click Add to add a new trusted CA to the store.

  • Certificate Revocation Lists - The CRL table shows a list of Certificate Revocation Lists (CRLs) known to Oracle Identity Federation.

    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

    Select a CRL and click Delete to remove it from the store. Click Add to add a new CRL to the store.

5.11 Configuring Federations

See Section 4.3, "Managing Identity Federations".

5.12 Configuring Identities

See Section 4.4, "Configuring Identities".

5.13 Managing Data Stores

This section explains how to configure and manage the different data stores used by Oracle Identity Federation:

5.13.1 Manage the User Data Store

This section explains how to configure user data stores for Oracle Identity Federation:

5.13.1.1 Configuring Oracle Identity Federation for RDBMS User Data Store

In order for Oracle Identity Federation to use a database as the user data store, this database must have a table, referred to as the user table, that contains user information. The user table must have a column that contains the User ID with which the user will be identified in Oracle Identity Federation. The User ID must always be present and must be unique across all users. If Attribute Sharing or User Mapping with Attributes will be used, columns for these attributes must also be present in the user table.

To configure Oracle Identity Federation to use an RDBMS user data store:

  1. Create a JDBC Data Source

  2. Modify Oracle Identity Federation Data Store Configuration

Create a JDBC Data Source

Follow these steps to create a JDBC data source:

  1. Log in to the WebLogic Administration Console.

  2. Navigate to Services, then JDBC, then Data Sources.

  3. Click New.

  4. Choose a name and a JNDI name for the new data source, and enter the database information. Choose the WebLogic managed server where Oracle Identity Federation is deployed as the target of this data source.

Configure an RDBMS User Data Store

Surrounding text describes dbuds.gif.

Follow these steps to configure an RDBMS user data store:

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance

  2. Navigate to Administration, then Data Stores.

  3. In the User Data Store section, click Edit.

  4. Select Database from the Repository Type dropdown list.

  5. Enter the following properties:

    • JNDI Name: The JNDI of the data source created in the WebLogic Administration Console.

    • Login Table: The name of the user table.

    • User ID Attribute: The name of the User ID column in the user table.

    • User Description Attribute: The name of the User Description column in the user table.

  6. Click OK.

Example

Consider the following user table, named "UserInformation", and suppose the JNDI name of the data source is "MyCorpUserDS".

Username FirstName LastName FullName Email

alice

Alice

Smith

Alice Smith

alice@mycorp.com

bob

Robert

Jones

Robert Jones

bob@mycorp.com

charlie

Charles

Johnson

Charles Johnson

charlie@mycorp.com

david

David

Jones

David Jones

david@mycorp.com

robert

Robert

Williams

Robert Williams

williams@mycorp.com


Oracle Identity Federation configuration for the user data store might look like this:

  • JNDI Name: MyCorpUserDS

  • Login Table: UserInformation

  • User ID Attribute: Username

  • User Description Attribute: Full Name

Alternatively, the configuration could be:

  • JNDI Name: MyCorpUserDS

  • Login Table: UserInformation

  • User ID Attribute: Username

  • User Description Attribute: Username

5.13.1.2 Configuring Oracle Identity Federation for an LDAP User Data Store

Surrounding text describes ldapuds.gif.

Follow these steps to configure an LDAP user data store:

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Data Stores.

  3. In the User Data Store section, click Edit.

  4. Select LDAP Directory from the Repository Type dropdown list.

The fields to set up this configuration are as follows:

  • 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 - Administrator password to connect to LDAP server

  • UserID 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 LDAP server.

  • Connection Wait Timeout - This is the timeout, in minutes, to use when Oracle Identity Federation opens a connection to the LDAP server.

5.13.1.3 Configuring Oracle Virtual Directory as User Data Store

Oracle Identity Federation can be integrated with Oracle Virtual Directory; when using Oracle Virtual Directory as the user data store, ensure that the base DN, person object class, unique user id and user description attribute settings are valid for all directory structures connected to Oracle Virtual Directory.

5.13.1.4 Configuring a Redundancy User Data Store

Redundancy is supported for the user data stores; this section explains how to set up redundancy user data stores.

There are two ways to set up redundancy user data stores:

  1. In the user data store configuration, in the Server URL field, enter a list of space-separated ldap URLs.

    For example:

    ldap://ldap1.oif.mycorp.com ldap://ldap2.oif.mycorp.com ldap://ldap3.oif.mycorp.com
    

    or

  2. Set up a load balancer in front of the LDAP servers and set the "ldaphaenabled" property in Oracle Identity Federation configuration to true. For details about this task, see Section 6.4.1, "Configuring High Availability LDAP Servers".

5.13.1.5 Configuring No User Data Store

You can configure Oracle Identity Federation not to use a user data store at runtime. In this configuration, the only user information available to the server is the user identifier:

  • after local authentication, or

  • after the incoming assertion is mapped with the use of a federated identity record, when the server acts as a Service Provider

To configure Oracle Identity Federation not to use a user data store:

  1. Modify Oracle Identity Federation Data Store Configuration

  2. Modify Oracle Identity Federation Configuration to use the user identifier

Modify Oracle Identity Federation Data Store Configuration

Follow these steps to configure no user data store:

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Data Stores.

  3. In the User Data Store section, click Edit.

  4. Select None from the Repository Type dropdown list.

  5. Click OK.

Modify Oracle Identity Federation Configuration to use the User Identifier

When None is selected as the user data store, you can configure Oracle Identity Federation so that the user identifier will be used to populate assertion data, or to configure the federation data store.

If Oracle Identity Federation acts as an Identity Provider, you can configure the server to:

  • set the user identifier as the Assertion Name ID

    To achieve this, navigate to the NameID format table, and set the user attribute for the NameID format to orafed-userid.

  • add the user identifier as an assertion attribute

    To achieve this, navigate to the configuration screen for the remote Service Provider to which the assertion will be sent, define an attribute to be sent, and set the user attribute to orafed-userid.

If a federation data store is in use, be sure to configure Oracle Identity Federation to use orafed-userid as the user ID attribute and user description attribute in the section that configures the federation data store.

5.13.2 Manage the Federation Data Store

Oracle Identity Federation provides the option of configuring a back-end data store to store records containing federated identity information.

If configured to use a federation data store of type XML, LDAP, or RDBMS, Oracle Identity Federation will create a federation record for each user, store this record in the selected data store, and use it in Single Sign-On to create an assertion (if acting as the identity provider), or to map the assertion received from the IdP to a user (if acting as the service provider).

To use persistent Name IDs with the SAML 2.0 protocol requires a Federation Datastore, as an opaque identifier must be created for each user (that is, the Name ID used to identify the user cannot be an attribute from the user datastore, and must thus be created and stored separately).

Oracle Identity Federation will create the federation record on the first time that the user performs a Single Sign-On operation. If acting as a service provider and using persistent Name IDs, since the Name ID does not contain any user information, Oracle Identity Federation will prompt the user for local authentication and create a federation record taking user information from this authentication. Once the federation has been created, Oracle Identity Federation (acting as a service provider) will not ask the user to login locally, since it can automatically map the opaque Name ID in the assertion to the user, using the federation record.

If the Federation Datastore is set to None, then Oracle Identity Federation will not create, store, or use federation records, but rather use attributes in the user data store to identify users, either to create assertions, in the case when it is acting as the identity provider, or to map assertions to users, in the case when it is acting as the service provider.

Note:

Configuring XML as the federation store is not recommended for production environments. Use an RDBMS or LDAP store in production environments.

Note:

You can also set up redundancy federation data stores. For more information see Section 5.13.1.4, "Configuring a Redundancy User Data Store".

Guidelines

Here are some general guidelines:

  • If the Federation Datastore is set to None:

    • Persistent Name IDs cannot be used

    • If acting as an identity provider, Oracle Identity Federation will create an assertion by mapping the Name ID format to be used to an attribute in the user data store, and using the value of this attribute as the Name ID.

    • If acting as a service provider. Oracle Identity Federation will map the assertion received from the identity provider by either using an attribute query, or by mapping the Name ID in the assertion to an entry in the user data store.

  • If the Federation Datastore is set to XML, LDAP or RDBMS:

    • Persistent Name IDs can be used

    • If acting as an identity provider, Oracle Identity Federation will use the Name ID stored in the federation record created for the user, when creating the assertion.

    • If acting as a service provider, Oracle Identity Federation will map the assertion to a user by finding the federation record with the Name ID included in the assertion.

    • If acting as a service provider and using persistent Name IDs, Oracle Identity Federation will prompt for local authentication the first time SSO is performed with a given user and a given provider.

Subsequent sections cover these topics:

5.13.2.1 Configuring Oracle Identity Federation for an RDMBS Federation Data Store

The high-level steps to configure an RDBMS federation data store are:

  1. Create a JDBC data source.

  2. Run RCU to create the Oracle Identity Federation schema.

    Note:

    Be sure to write down the Oracle Identity Federation schema owner and password that is shown in RCU. It is of the form PREFIX_OIF; you will need to provide this information when configuring Oracle Identity Federation.

  3. Modify Oracle Identity Federation data store configuration.

    This involves configuring Oracle Identity Federation to use the new data source from Step 1, and configuring the federation data store.

We will now describe each step in detail.

Create a JDBC Data Source

Follow these steps to create a JDBC Data Source:

  1. Log in to the WebLogic Administration Console.

  2. Navigate to Services, then JDBC, then Data Sources.

  3. Click New.

  4. Choose a Name and a JNDI Name for the new data source, and enter the database information. Choose the WebLogic managed server where Oracle Identity Federation is deployed as the target of this data source.

Create Oracle Identity Federation Schema

Follow the steps described in Section 5.13.5, "Create the Oracle Identity Federation Schema Using RCU" to create the Oracle Identity Federation schema.

Modify Oracle Identity Federation Data Store Configuration

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Data Stores.

  3. In the Federation Data Store section, click Edit.

  4. Select Database from the Repository Type dropdown list.

  5. Enter the JNDI Name; use the JNDI of the data source created in the WebLogic Administration Console.

  6. Click OK.

5.13.2.2 Configuring Oracle Identity Federation for an LDAP Federation Data Store

Follow these steps to configure an LDAP federation data store:

Surrounding text describes fedds.gif.

Connection URL

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

ldap://ldap.oif.com:389

A space-separated list of LDAP connection URLs can be entered in this field.

Bind DN

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

cn=orcladmin

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

Note:

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

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

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.

5.13.2.3 Configuring Oracle Identity Federation for an XML Federation Data Store

Follow these steps to configure Oracle Identity Federation to use an XML file as the federation data sore.

Note:

Configuring XML as the federation store is not recommended in production environments. Use an RDBMS or LDAP store in production environments.

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Data Stores.

  3. In the Federation Data Store section, click Edit.

  4. Select XML file from the Repository Type dropdown list.

  5. Click OK.

5.13.2.4 Configuring Oracle Virtual Directory as Federation Data Store

When integrating Oracle Virtual Directory into the Oracle Identity Federation environment to serve as the federation data store, ensure that the fed record context and the LDAP container object class settings are valid for the particular directory structure used to store federation records; that is, they must be valid for the directory structure of the LDAP Server that is "referenced" by the federation record context.

5.13.3 Manage the Session Data Store and the Message Data Store

Oracle Identity Federation uses the message data store and the user session data store for storing transient data like federation protocol/session state. The message data store together with the user session data store is also referred to as the transient data store.

Transient data can be stored either in memory or in a relational database.

Surrounding text describes sesmsgds.gif.

Follow these steps to configure Oracle Identity Federation to use an in-memory session/message data store:

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Data Stores.

  3. In the Session Data Store and Message Data Store section, click Edit.

  4. Select Memory from the Repository Type dropdown list.

To configure Oracle Identity Federation to use an RDBMS session/message data store, the high-level steps are:

  1. Create a JDBC Data Source.

  2. Run RCU to create the Oracle Identity Federation schema.

    Note:

    Be sure to write down the Oracle Identity Federation schema owner and password that is shown in RCU. It is of the form PREFIX_OIF; you will need to provide this information when configuring Oracle Identity Federation.

  3. Modify the Oracle Identity Federation data store configuration.

    This involves configuring Oracle Identity Federation to use the new data source from Step 1, and configuring the federation data store.

We will now describe each step in detail.

Create a JDBC Data Source

Follow these steps to create a JDBC data source:

  1. Log in to the WebLogic Administration Console.

  2. Navigate to Services, then JDBC, then Data Sources.

  3. Click New.

  4. Choose a Name and a JNDI Name for the new data source, and enter the database information. Choose the WebLogic managed server where Oracle Identity Federation is deployed as the target of this data source.

Create Oracle Identity Federation Schema

Follow the steps described in Section 5.13.5, "Create the Oracle Identity Federation Schema Using RCU" to create the Oracle Identity Federation schema.

Modify Oracle Identity Federation Data Store Configuration

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Data Stores.

  3. In the Configuration Data Store section, click Edit.

  4. Select Database from the Repository Type dropdown list.

  5. Enter the JNDI Name; use the JNDI of the data source created in the WebLogic Administration Console.

  6. Click OK.

5.13.4 Manage the Configuration Data Store

Oracle Identity Federation uses the configuration data store to store its configuration artifacts. The configuration store can either be an XML file or a relational database. If your deployment is a High Availability deployment, you must use a relational database as the configuration data store.

This section contains these topics:

5.13.4.1 Using a File System Configuration Data Store

The configuration data is stored in the file system by default during a basic install. To change the store from database to file system:

  1. Navigate to Administration, then Data Stores.

  2. In the Configuration Data Store section, click Edit.

  3. Select File System from the Repository Type dropdown list.

5.13.4.2 Using an RDBMS Configuration Data Store

To configure Oracle Identity Federation to use an RDBMS configuration data store, the high-level steps are:

  1. Create a JDBC data source.

  2. Run RCU to create the Oracle Identity Federation schema.

    Note:

    Be sure to write down the Oracle Identity Federation schema owner and password that is shown in RCU. It is of the form PREFIX_OIF; you will need to provide this information when configuring Oracle Identity Federation.

  3. Modify Oracle Identity Federation data store configuration.

    This involves configuring Oracle Identity Federation to use the new data source from Step 1, and setting up the configuration data store.

We will now describe each step in detail.

Create a JDBC Data Source

Follow these steps to create a JDBC data source:

  1. Log in to the WebLogic Administration Console.

  2. Navigate to Services, then JDBC, then Data Sources.

  3. Click New.

  4. Choose a Name and a JNDI Name for the new data source, and enter the database information. Choose the WebLogic managed server where Oracle Identity Federation is deployed as the target of this data source.

Create Oracle Identity Federation Schema

Follow the steps described in Section 5.13.5, "Create the Oracle Identity Federation Schema Using RCU" to create the Oracle Identity Federation schema.

Modify Oracle Identity Federation Data Store Configuration

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Data Stores.

  3. In the Configuration Data Store section, click Edit.

  4. Select Database from the Repository Type dropdown list.

  5. Enter the JNDI Name; use the JNDI of the data source created in the WebLogic Administration Console.

  6. Click OK.

5.13.4.3 When the RDBMS Configuration Data Store is Down

If the configuration data store is integrated with an RDBMS, and if the database is down, Oracle Identity Federation can rely on the latest version of configuration data retrieved from the RDBMS, and runtime operations are not affected; nevertheless, you should not perform any configuration while the RDBMS is down, since the changes are not saved in the RDBMS, and so the configuration changes are not propagated to the database.

5.13.5 Create the Oracle Identity Federation Schema Using RCU

This section describes how to create an Oracle Identity Federation schema using RCU. You must create the schemas before data stores can be configured to use a database.

  1. Install RCU from the install CD or installer binaries.

  2. Run $RCU_HOME/bin/rcu.

    Note:

    Be sure to write down the Oracle Identity Federation schema owner and password that is shown in RCU. It is of the form PREFIX_OIF; you will need to provide this information when configuring Oracle Identity Federation.

  3. Select Create to create components in the database.

  4. Enter database connection details in the next screen.

  5. Select Oracle Identity Federation from Identity Management from the Select Component screen.

  6. Enter the password in the Schema Passwords screen.

  7. Proceed to finish the schema creation for Oracle Identity Federation.

5.14 Configuring Authentication Mechanisms

Authentication mechanisms contain the rules that specify how to use an entity's credentials to verify its identity.

Use these sections to learn about and configure authentication mechanisms for server protocols:

5.14.1 About Authentication Mechanisms

Authentication mechanisms specify the way a user should be challenged when authentication is required; options include username/password, kerberos, and others. A service provider can request that the identity provider challenge the user in a certain way by specifying an authentication method in its authentication request.

Because the SP and the IdP can communicate using different protocols, Oracle Identity Federation defines local authentication mechanisms to which the protocol-specific methods can be mapped.

For example, both the SAML 2.0 method urn:oasis:names:tc:SAML:2.0:ac:classes:Password and the SAML 1.x method urn:oasis:names:tc:SAML:1.0:am:password can be mapped to the local authentication mechanism oracle:fed:authentication:password.

Oracle Identity Federation will use these local authentication mechanisms in the following situations:

  1. The SP can specify in its request an authentication method that describes the way the user should be authenticated. When the Oracle Identity Federation IdP receives this request, it maps the requested method to a local authentication mechanism. If no authentication method was requested, the IdP uses the default authentication mechanism. This authentication mechanism is then mapped to an authentication engine, which determines the way the user is challenged.

  2. An SP engine can specify the authentication method the SP will request from the identity provider by specifying a local authentication mechanism. This local mechanism (or the default mechanism if the SP engine did not specify one) is mapped to a protocol-specific method, which is included in the authentication request that the SP sends to the identity provider.

  3. If an SP engine does not specify an identity provider to which to send the authentication request, the SP locates the IdP by mapping the authentication mechanism received from the SP engine (or using the default mechanism if the engine did not send a mechanism) to an identity provider.

  4. When creating an assertion, the identity provider determines the mechanism used to authenticate the user and specifies the corresponding protocol-specific authentication method in the assertion.

  5. When creating a user session, Oracle Identity Federation records the local authentication mechanism used to authenticate the user.

  6. When an Oracle Identity Federation IdP uses the Federation SSO Proxy authentication engine, it uses the requested authentication mechanism (or the default mechanism if no method was requested by the SP) to locate the identity provider to which to send the request. See Section 5.15.9.1, "About the Federated SSO Proxy Authentication Engine" for a description of this authentication engine.

Additional topics in this section include:

5.14.1.1 Setting the Default Authentication Mechanism

If a service provider does not specify an authentication method in its request, the Oracle Identity Federation IdP uses the default authentication mechanism in the cases described earlier.

Follow these steps to set the default authentication mechanism:

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Authentication Mechanisms.

  3. Select the default authentication mechanism and click Apply.

5.14.1.2 Mapping from Protocol-specific Methods to Local Mechanisms To Authentication Engines

As mentioned earlier, Oracle Identity Federation provides the ability to map:

  • protocol specific authentication methods to local authentication mechanisms, and

  • local authentication mechanisms to authentication engines

Thus, different authentication engines can be used depending on the authentication method specified by the service provider in its request.

For example, you can define the following mappings for the SAML 2.0 protocol:

urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos -> oracle:fed:authentication:kerberos

oracle:fed:authentication: kerberos -> Custom Kerberos Authentication Engine

and:

urn:oasis:names:tc:SAML:2.0:ac:classes:Password -> oracle:fed:authentication:password
 
oracle:fed:authentication:password  ->  Oracle Single Sign-On

If a SAML 2.0 SP requests that the user be authenticated with mechanism urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos, Oracle Identity Federation uses the custom authentication engine created to authenticate the user through Kerberos. But if the SP requests the urn:oasis:names:tc:SAML:2.0:ac:classes:Password mechanism, the user is authenticated with the Oracle Single Sign-On engine.

To configure:

  • the local authentication mechanism to authentication engine mappings and

  • protocol-specific authentication method to local authentication mechanism mappings

follow these steps:

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Authentication Mechanisms.

  3. In the Local Mechanisms tab, enable and map the local mechanisms to authentication engines and click Apply.

    For example, add the mappings:

    oracle:fed:authentication: kerberos -> Custom Kerberos Authentication Engine
     
    oracle:fed:authentication:password  ->  Oracle Single Sign-On
    
    
  4. In each of the protocol-specific tabs (SAML 2.0, SAML 1.x, WS-Federation 1.1), map protocol-specific authentication methods to local mechanisms and click Apply.

    For example, in the SAML 2.0 tab, add the mappings:

    urn:oasis:names:tc:SAML:2.0:ac:classes: Kerberos -> oracle:fed:authentication: kerberos
    
    urn:oasis:names:tc:SAML:2.0:ac:classes:Password -> oracle:fed:authentication:password
    

5.14.1.3 Mapping Local Authentication Mechanisms to Identity Providers

Follow these steps to configure mappings from local authentication mechanisms to identity providers:

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Service Provider.

  3. In Protocol Settings, click Configure SSO Authentication Mechanism to Identity Provider Mapping.

  4. Click Add, and select the authentication mechanism and the identity provider to which it will be mapped.

  5. When you are finished adding mappings, click OK. Then click Apply.

The Federation SSO Proxy authentication engine uses these mappings to determine the identity provider to which to send the request.

An Oracle Identity Federation service provider also uses these mappings to locate the identity provider to which to send the request, when the SP engine does not specify the target IdP in its request to the SP. For example, if using the Oracle Access Manager SP Engine, an Oracle Access Manager scheme can be mapped to an Oracle Identity Federation local authentication mechanism, which is then used to locate the identity provider to which to send the authentication request.

5.14.2 Configure Authentication Mechanisms - Local

Use this page to:

  • view, add or delete local authentication mechanisms

  • enable or disable selected authentication mechanisms

  • map local authentication mechanisms to authentication engines

  • update the relative order or the local authentication mechanisms. A mechanism with a higher order in the table has a higher authentication level.

Surrounding text describes authmelocal.gif.

The authentication mechanisms table displays these columns:

  • the name of the local authentication mechanism

  • the authentication engine currently associated with a mechanism

  • a check-box indicating whether the mechanism is currently active.

To enable (disable) a mechanism, check (uncheck) the corresponding box in the Enable column.

To change the displayed data, use the View drop-down to select the desired fields.

To add a new authentication mechanism, click Add.

To delete an existing authentication mechanism, select the row for that mechanism and click Delete. You will be asked to confirm the deletion.

To modify the order of the mechanisms, use the arrow keys at the top of the table after selecting a row.

Click Apply to save the changes, or Revert to reset the data to its previous state.

5.14.3 Configure Authentication Mechanisms - SAML 2.0

Use this page to:

  • view, add or delete SAML 2.0 authentication mechanisms

  • map SAML 2.0 authentication mechanisms to local authentication mechanisms

Surrounding text describes authmesaml2.gif.

The authentication mechanisms table displays these columns:

  • the name of the local authentication mechanism

  • the authentication engine currently associated with a mechanism

To change the displayed data, use the View drop-down to select the desired fields.

To add a new authentication mechanism, click Add.

To delete an existing authentication mechanism, select the row for that mechanism and click Delete. You will be asked to confirm the deletion.

Click Apply to save the changes, or Revert to reset the data to its previous state.

5.14.4 Configure Authentication Mechanisms - SAML 1.x

Use this page to:

  • view, add or delete SAML 1.x authentication mechanisms

  • map SAML 1.x authentication mechanisms to local authentication mechanisms

Surrounding text describes authmesaml1.gif.

The authentication mechanisms table displays these columns:

  • the name of the SAML 1.x authentication mechanism

  • the authentication engine currently associated with a mechanism

To change the displayed data, use the View drop-down to select the desired fields.

To add a new authentication mechanism, click Add.

To delete an existing authentication mechanism, select the row for that mechanism and click Delete. You will be asked to confirm the deletion.

Click Apply to save the changes, or Revert to reset the data to its previous state.

5.14.5 Configure Authentication Mechanisms - WS-Federation 1.1

Use this page to:

  • view, add or delete WS-Federation 1.1 authentication mechanisms

  • map WS-Federation 1.1 authentication mechanisms to local authentication mechanisms

Surrounding text describes authmewsfed.gif.

The authentication mechanisms table displays these columns:

  • the name of the WS-Federation 1.1 authentication mechanism

  • the authentication engine currently associated with a mechanism

To change the displayed data, use the View drop-down to select the desired fields.

To add a new authentication mechanism, click Add.

To delete an existing authentication mechanism, select the row for that mechanism and click Delete. You will be asked to confirm the deletion.

Click Apply to save the changes, or Revert to reset the data to its previous state.

5.15 Configuring Authentication Engines

Use this page to configure:

This page consists of tabs devoted to individual authentication engines. Updates on any tab are saved as you move to other tabs. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

5.15.1 Authentication Engines - HTTP Header

The HTTP Header authentication engine authenticates a user based on the value of an HTTP header.

The typical deployment for such an engine consists of:

  • Oracle Identity Federation server deployed in the domain

  • a web server (such as Oracle HTTP Server) fronting the WebLogic managed server where Oracle Identity Federation is running (see Section 3.2.1, "Deploying Oracle Identity Federation with Oracle HTTP Server" for details on how to deploy and integrate Oracle HTTP Server if it is not yet installed.)

  • a web agent integrated on the web server, protecting the HTTP header authentication engine URL (http(s)://oif-host:oif-port/fed/user/authnhttp)

  • a web agent policy for the HTTP header authentication engine URL that instructs the agent to set the user's identity as an HTTP header variable

  • Oracle Identity Federation configured to retrieve the HTTP header variable from the HTTP request that contains the user's identity

Since the Web agent protects the HTTP header authentication engine URL, any requests processed by the Oracle Identity Federation server on this URL means that the user was authenticated by the Web Access Management system to which the Web agent belongs.

5.15.1.1 Configuring the HTTP Header Authentication Engine

Surrounding text describes authenhttp.gif.

The HTTP Header tab contains these fields:

  • Enable Authentication Engine - Check this box to enable the engine, and uncheck the box to disable the engine. If enabled, this engine appears on the list of available engines (in the list-box associated with Default Authentication Engine).

  • User Unique ID Header - When Oracle Identity Federation uses the HTTP header engine as an authentication engine, a Web agent is integrated with Oracle HTTP Server/Oracle Identity Federation and protects an Oracle Identity Federation URL. The policy domain for the Oracle Identity Federation URL is configured to provide the user identifier as an HTTP header.

    Use this field to specify the name of the HTTP header containing the user identifier provided by the Web agent.

  • Logout Enabled - Check this box to enable logouts with this engine. When enabling logouts, related fields include:

    • Logout URL - The is the URL where Oracle Identity Federation needs to redirect the user for the Web Access Management system logout.

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

Note:

When the user must be redirected to a Web access management URL for logout (to perform some logout operations), you need to configure Oracle Identity Federation by checking Logout Enabled, and entering the URL to which the user is redirected. When Oracle Identity Federation redirects the user to that URL, it appends a return URL as a query parameter; this is the Oracle Identity Federation URL to which the user should be redirected after performing the Web access management logout operations.

Oracle Identity Federation appends the query parameter to the Logout URL referenced by returnurl.

5.15.1.2 Configuring HTTP Header Attributes

The HTTP Header Attributes module is invoked after a successful local authentication operation that extracts HTTP headers from the user's HTTP request and saves them as Oracle Identity Federation session attributes. These attributes in turn can be used to populate a SAML assertion when Oracle Identity Federation acts as an identity provider.

Take these steps to configure the HTTP Header Attributes module:

  1. In the Authentication Engines section, click Configure to manage the HTTP Header Attributes module.

    A window appears that lists the HTTP header attributes that are collected by Oracle Identity Federation after a successful local authentication operation.

  2. To add an HTTP header to be collected and saved as a session attribute:

    • Click Add.

    • To retrieve an HTTP header, enter its name in the new field. For example, to retrieve the Accept Language header, enter Accept-Language.

    • To retrieve the value of a cookie presented in the HTTP request, enter the name of the cookie, prefixed with orafed-cookie-. For example, to retrieve the value of the cookie called userLanguageCookie, enter orafed-cookie-userLanguageCookie; at runtime Oracle Identity Federation retrieves the cookie, extracts the value and sets the orafed-cookie-userLanguageCookie session attribute.

  3. To delete an HTTP header:

    • Select the HTTP header to remove.

    • Click Delete.

  4. Click OK to save the changes.

Once the HTTP Header Attributes module is configured, you can configure Oracle Identity Federation to use these session attributes when building assertions, to populate:

  • Name Identifier values in the assertion's Subject

  • Attributes in the assertion. For example, the "Accept-Language" and "orafed-cookie-userLanguageCookie" can be sent as assertion attributes by listing them in the Attribute Mappings and Filters section of a trusted service provider.

The run-time flow looks like this:

  1. Oracle Identity Federation determines that the user needs to be authenticated, and invokes an authentication engine to challenge and identify the user.

  2. The user provides some credentials or information by submitting data to the authentication engine URL (for example, username and password POST to the LDAP authentication engine credential processing URL).

  3. After the user data is validated, the engine internally forwards the user back to Oracle Identity Federation.

  4. The HTTP Header Attributes module analyzes the HTTP request submitted to the authentication engine (the module has access to it because of the internal forward operation). It extracts the required HTTP headers and/or cookie values from this request.

  5. Oracle Identity Federation saves the extracted data as session attributes.

  6. If configured to do so, during assertion creation Oracle Identity Federation/IdP uses the session attributes to populate the NameID or attribute elements.

5.15.2 Authentication Engines - Oracle Single Sign-On

Surrounding text describes authenosso.gif.

The tab contains these fields:

  • Default Authentication Engine - This is the engine used for authentications. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.

  • Enable Authentication Engine - Check this box to enable the engine, and uncheck the box to disable the engine. If enabled, this engine appears on the list of available engines (in the list-box associated with Default Authentication Engine).

  • User Unique ID Attribute - This is the attribute Oracle Identity Federation uses to identify the user.

    Notes:

    • For every user, this attribute value must equal the attribute value specified for Unique ID Attribute in the User Data Store configuration. For example, if the attribute configured here is mail, and the attribute configured as Unique ID Attribute in the user data store configuration is EmailAddress, then the value of mail in the authentication engine back-end must equal the value of EmailAddress in the user data store.

    • The attribute value you configure here must be unique across all users.

  • Logout URL - This is the Oracle Single Sign-On server URL to present at logout.

  • Logout Enabled - Check this box to indicate that Oracle Identity Federation will redirect the user to the Oracle SSO Logout URL when the Oracle Identity Federation logout flow is performed.

    The logout URL needs to be the Oracle SSO Logout URL:

    http(s)://sso-host:sso-port/sso/logout
    

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

5.15.3 Authentication Engines - Oracle Access Manager 11g

Surrounding text describes authenoam11g.gif.

Use this tab to configure the Oracle Access Manager 11g authentication engine.

The tab contains these fields:

  • Default Authentication Engine - This is the engine used for authentications. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.

  • Enable Authentication Engine - Check this box to enable the engine, and uncheck the box to disable the engine. If enabled, this engine appears on the list of available engines (in the list-box associated with Default Authentication Engine).

  • Agent Type - The agent must be one of: Webgate11g, Webgate10g or mod_osso.

  • User Unique ID Header - This is the attribute Oracle Identity Federation uses to identify the user. For a mod_osso agent, this is a drop-down list, and is set to Proxy Remote User by default. For Webgate10g or Webgate11g, the default is OAM_REMOTE_USER.

    Notes:

    • For every user, this attribute value must equal the attribute value specified for Unique ID Attribute in the user data store. For example, if the attribute configured here is mail, and the attribute configured as Unique ID Attribute in the user data store is EmailAddress, then the value of mail in the authentication engine back-end must equal the value of EmailAddress in the user data store.

    • The attribute value you configure here must be unique across all users.

  • Logout URL - This is the Oracle Access Manager server URL to present at logout. For example:

    http://oam_host:oam_port/oam/server/logout
    

    Note:

    If SP integration with OAM11g engine is enabled and configured for logout, you do not need to configure logout in the OAM11g authentication engine.

  • Logout Enabled - Check this box to indicate that Oracle Identity Federation will redirect the user to the Oracle Access Manager Logout URL when the Oracle Identity Federation logout flow is performed.

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

5.15.4 Authentication Engines - Oracle Access Manager 10g

Surrounding text describes authenoam.gif.

The tab contains these fields:

  • Default Authentication Engine - This is the engine used for authentications. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.

  • Enable Authentication Engine - Check this box to enable the engine, and uncheck the box to disable the engine. If enabled, this engine appears on the list of available engines (in the list-box associated with Default Authentication Engine).

  • User Unique ID Header - When Oracle Identity Federation uses Oracle Access Manager as an authentication engine, WebGate is integrated with Oracle HTTP Server/Oracle Identity Federation and protects an Oracle Identity Federation URL. The policy domain for the Oracle Identity Federation URL is configured so that it will provide the user identifier as an HTTP header.

    Use this field to specify the name of the HTTP header containing the user identifier provided by WebGate.

  • Logout Enabled - Check this box to enable logouts with this engine. When enabling logouts, related fields include:

    • Clear Cookie - If checked, resetting the Oracle Access Manager cookie is sufficient for Oracle Identity Federation to log the user out of the Oracle Access Manager domain.

    • Cookie Domain - Cookie domain that Oracle Identity Federation will set when creating the Oracle Access Manager cookie.

    • Redirect to Logout URL - Check this box and fill in the URL if Oracle Identity Federation needs to redirect the user to a specific URL for Oracle Access Manager logout.

    • Logout URL - This is the URL to present at logout.

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

5.15.5 Authentication Engines - LDAP Directory

Surrounding text describes authenldap.gif.

The tab contains these fields:

  • Default Authentication Engine - This is the engine used for authentications. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.

  • Enable Authentication Engine - Check this box to enable the engine, and uncheck the box to disable the engine. If enabled, this engine appears on the list of available engines (in the list-box associated with Default Authentication Engine).

  • Connection URL(s) - space-delimited list of LDAP server URLs - hostname and port

  • Bind DN - This is the DN used by the Oracle Identity Federation server to connect to the LDAP server. For example:

    cn=fedid,dc=mycompany,dc=com

  • Password - Server password

  • Confirm Password - Server password

  • Maximum Connections - This is the maximum number of concurrent connections made by Oracle Identity Federation to the LDAP server.

  • User Credential ID Attribute - This is the attribute with which Oracle Identity Federation will authenticate the user.

    For example, if the attribute configured here is mail, and the value of this attribute for a user is alice@mycorp.com, that user will need to authenticate with username alice@mycorp.com.

    Note:

    The attribute value configured here must be unique across all users.

  • User Unique ID Attribute - This is the attribute with which Oracle Identity Federation will identify the user.

    Notes:

    • For every user, the value of this attribute must equal the value of the attribute specified as Unique ID Attribute in the user data store. For example, if the attribute configured here is mail, and the attribute configured as Unique ID Attribute in the user data store is EmailAddress, then the value of mail in the authentication engine back-end must equal the value of EmailAddress in the user data store.

    • The attribute value configured here must be unique across all users.

  • Person Object Class - the LDAP object class representing a user in the LDAP 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 - the node under which LDAP user search will be performed. For example:

    dc=us,dc=oracle,dc=com

  • Connection Wait Timeout (sec) - the maximum number in seconds to wait until a connection is available, when the maximum number of connections opened by Oracle Identity Federation to the LDAP server has been reached.

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

For additional information relevant to configuring LDAP authentication engines, see:

5.15.5.1 Configuring Oracle Virtual Directory as the Authentication Engine

Oracle Identity Federation can be integrated with Oracle Virtual Directory; when using Oracle Virtual Directory as the LDAP authentication engine, ensure that the base DN, person object class, unique user id and user description attribute settings are valid for all directory structures connected to Oracle Virtual Directory.

5.15.6 Authentication Engines - Database Security

Surrounding text describes authendbs.gif.

The tab contains these fields:

  • Default Authentication Engine - This is the engine used for authentications. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.

  • Enable Authentication Engine - Check this box to enable the engine, and uncheck the box to disable the engine. If enabled, this engine appears on the list of available engines (in the list-box associated with Default Authentication Engine).

  • JDBC URL - the connection URL of the database.

  • JDBC Driver - Enter the JDBC driver string.

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

5.15.7 Authentication Engines - Database Table

Surrounding text describes authendbt.gif.

The tab contains these fields:

  • Default Authentication Engine - This is the engine used for authentications. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.

  • Enable Authentication Engine - Check this box to enable the engine, and uncheck the box to disable the engine. If enabled, this engine appears on the list of available engines (in the list-box associated with default authentication engine).

  • JNDI Name - The JNDI of the data source created in the Oracle WebLogic Server Administration Console.

  • Login Table - The name of the login table.

  • Login ID Column - The name of the Login ID column in the Login Table.

  • User Unique ID Column - The name of the User ID column in the Login Table.

  • Login Password Column - The name of the Login Password column in the Login Table.

  • Password Digests Algorithm - The digest algorithm applied to passwords in the Login Table. Select None if the password is stored in clear-text in the database, or select MD5 or SHA1 if the value in the database is an MD5 or SHA1 hash of the password.

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

5.15.7.1 Configuring Oracle Identity Federation for RDBMS Authentication Engine

In order for Oracle Identity Federation to use a database as the authentication engine, this database must have a table, referred to as the login table, that contains user login information. Each user in the login table must have these attributes:

  1. Login ID: The unique username with which the user will log in.

  2. Login Password: The password with which the user will log in. The value in this column can be the clear-text password or an MD5 or SHA1 hash of the password.

  3. User ID: The unique identifier with which the user will be identified in Oracle Identity Federation. The value of the User ID must match the value of the User ID in the user data store.

The attributes Login ID and User ID can be stored in two separate columns, or in one column if the Login ID is to be used as the User ID.

Example 1

Consider the following login table, named "UserLoginInfo1". In this table, the Login ID is under the column "Email", and the User ID is under the column "UserID".

UserID FirstName LastName Password Email

alice

Alice

Smith

gu*L3nb

alice@mycorp.com

bob

Robert

Jones

aqweb80

bob@mycorp.com

charlie

Charles

Johnson

b23thag

charlie@mycorp.com

david

David

Jones

094bshyq=

david@mycorp.com

robert

Robert

Williams

#)haba*(+

williams@mycorp.com


Example 2

Consider the following login table, named "UserLoginInfo2". In this table, both the Login ID and the User ID are under the "Username" column.

Username Password FullName

alice

gu*L3nb

Alice Smith

bob

aqweb80

Robert Jones

charlie

b23thag

Charles Johnson

david

094bshyq=

David Jones

robert

#)haba*(+

Robert Williams


To configure Oracle Identity Federation to use the RDBMS authentication engine, you will need to:

  1. Create a JDBC data source.

  2. Modify Oracle Identity Federation authentication engine configuration.

Create a JDBC Data Source

Follow these steps to configure an RDBMS user data store:

  1. Log in to the WebLogic Administration Console.

  2. Navigate to Services, then JDBC, then Data Sources.

  3. Click New.

  4. Choose a Name and a JNDI Name for the new data source, and enter the database information. Choose the WebLogic managed server where Oracle Identity Federation is deployed as the target of this data source.

Modify Oracle Identity Federation Authentication Engine Configuration

Follow these steps to configure the RDBMS authentication engine.

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Authentication Engines.

  3. In the Database Table tab, select Enable Authentication Engine and add the following properties:

    • JNDI Name: The JNDI of the data source created in the WebLogic Administration Console.

    • Login Table: The name of the login table.

    • Login ID Column: The name of the Login ID column in the login table.

    • User Unique ID Attribute: The name of the User ID column in the login table.

    • Login Password Column: The name of the Login Password column in the login table.

    • Password Digest Algorithm: The digest algorithm applied to passwords in the login table.

      Select None if the password is stored in clear-text in the database, or select MD5 or SHA1 if the value in the database is an MD5 or SHA1 hash of the password.

  4. Click Apply.

Example 1 Configuration

The configuration corresponding to the table "UserLoginInfo1" in Example 1 above is as follows. Suppose the JNDI name of the data source created for the database is "MyCorpUserDS".

  • JNDI Name: MyCorpUserDS

  • Login Table: UserLoginInfo1

  • Login ID Column: Email

  • User Unique ID Attribute: UserID

  • Login Password Column: Password

  • Password Digest Algorithm: none/MD5/SHA1

Example 2 Configuration

The configuration corresponding to the table "UserLoginInfo2" in Example 2 above is as follows. Suppose the JNDI name of the data source created for the database is "MyCorpUserDS".

  • JNDI Name: MyCorpUserDS

  • Login Table: UserLoginInfo2

  • Login ID Column: Username

  • User Unique ID Attribute: Username

  • Login Password Column: Password

  • Password Digest Algorithm: none/MD5/SHA1

5.15.8 Authentication Engines - Infocard

Surrounding text describes autheninfo.gif.

The tab contains these fields:

  • Default Authentication Engine - This is the engine used for authentications. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.

  • Enable Authentication Engine - Check this box to enable the engine, and uncheck the box to disable the engine. If enabled, this engine appears on the list of available engines (in the list-box associated with Default Authentication Engine).

  • Map Assertion to User - If checked, the incoming assertion is mapped to a user record based on the configuration on the SAML 2.0 / SAML 1.x Assertion tab of the Service Provider page.

  • Display one Entry per Infocard Provider - If checked, Oracle Identity Federation displays an infocard selection option for each Infocard provider configured in the Federations page.

  • Include Authentication Mechanism - If checked, Oracle Identity Federation adds the authentication mechanism as a required claim, enabling it to request a specific authentication method from the Infocard providers.

  • Authentication Mechanism Mapped to Personal Card Issuer - When the Infocard authentication engine is invoked for authentication with the authentication mechanism configured here, the personal issuer card is displayed on the login page. If invoked with an authentication mechanism different from the one configured here, all the Infocard providers are displayed.

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

5.15.9 Authentication Engines - Federated SSO Proxy

Surrounding text describes authenfedsso.gif.

The tab contains these fields:

  • Default Authentication Engine - This is the engine used for authentications. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.

  • Enable Authentication Engine - Check this box to enable the engine, and uncheck the box to disable the engine. If enabled, this engine appears on the list of available engines (in the list-box associated with Default Authentication Engine).

  • Authentication Mechanism - This is the authentication mechanism that Oracle Identity Federation will use to authenticate the user locally when using the Federated SSO proxy.

    WARNING:

    The authentication mechanism specified here must not map to the Federated SSO Proxy authentication engine.

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

Additional topics include:

5.15.9.1 About the Federated SSO Proxy Authentication Engine

When an identity provider uses the Federated SSO Proxy authentication engine to authenticate a user, it does this by taking the role of service provider, and initiating a Single Sign-On flow with a second identity provider that authenticates the user.

The flow is as follows:

Surrounding text describes sfsag030.gif.
  1. A service provider, SP-1, sends an authentication request to an Oracle Identity Federation identity provider, IdP-1.

  2. Oracle Identity Federation/IdP-1 is using the Federated SSO Proxy authentication engine; it selects a trusted identity provider, IdP-2, takes the role of a service provider, and sends a new authentication request for the specified user to IdP-2.

  3. IdP-2 authenticates the user.

  4. IdP-2 sends back an assertion to Oracle Identity Federation/IdP-1, who will then process this assertion.

  5. If necessary, Oracle Identity Federation/IdP-1 authenticates the user locally (for example when a federation creation operation needs to be performed).

  6. Oracle Identity Federation/IdP-1 sends back a new assertion to SP-1.

5.15.9.2 Selecting the Identity Provider to Use

When an identity provider using the Federated SSO Proxy authentication engine receives an authentication request from a service provider, it will select a trusted identity provider to which to send a new request. To select the identity provider, Oracle Identity Federation maps the authentication mechanism requested by the service provider (or the default mechanism if the SP did not request one) to an identity provider, and sends a new request to this IdP.

If the mechanism does not map to an identity provider, Oracle Identity Federation uses the default identity provider in configuration. (Refer to Section 5.14.1, "About Authentication Mechanisms" for more information on authentication mechanisms and how protocol-specific methods are mapped to local authentication mechanisms).

For example, suppose that the following mappings from local authentication mechanisms to identity providers are configured:

oracle:fed:authentication:internet-protocol -> http://corp-1.com/idp
oracle:fed:authentication:password-protected -> http://corp-2.com/idp

and that the default identity provider is: http://corp-3.com/idp.

Then, if the service provider requests an authentication method that maps to the oracle:fed:authentication:internet-protocol, Oracle Identity Federation selects http://corp-1.com/idp as the identity provider, but if the service provider requests oracle:fed:authentication:password-protected, Oracle Identity Federation chooses http://corp-2.com/idp. If the service provider does not request an authentication method, then Oracle Identity Federation sends the new authentication request to http://corp-3.com/idp.

You can define the mappings from local authentication mechanisms to identity providers by following these steps:

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Service Provider.

  3. In Protocol Settings, click on Configure SSO Authentication Mechanism to Identity Provider Mapping.

  4. Click Add, and select the authentication mechanism and the identity provider to which it maps.

  5. When you are done adding mappings, click OK. Then click Apply.

You can configure the default identity provider by following these steps:

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Service Provider.

  3. Select the Default SSO Identity Provider and click Apply.

5.15.9.3 Configuring the Federated SSO Proxy Authentication Engine

To correctly use the federated SSO proxy authentication engine, you need to configure authentication mechanisms. This might include:

  1. Setting the default authentication mechanism

  2. Mapping protocol-specific methods to local mechanisms and local mechanisms to authentication engines

  3. Mapping local authentication mechanisms to identity providers

In addition to configuring authentication mechanisms, you will need to configure the federated SSO proxy authentication engine itself. To do this, follow these steps:

  1. Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.

  2. Navigate to Administration, then Authentication Engines.

  3. In the Federated SSO Proxy tab, select Enable Authentication Engine and choose the authentication mechanism that will be used to authenticate the user locally when needed.

WARNING:

The local authentication mechanism to use when the user needs to be locally authenticated must not be mapped to the Federated SSO Proxy authentication engine. This will create a loop where IdP-1 continuously sends a request to IdP-2. (IdP-1 sends a request to IdP-2 and receives an assertion. It needs to authenticate the user locally, and thus maps the mechanism to the Federated SSO Proxy authentication engine, which will prompt it to send a new request to IdP-2).

Refer to Section 5.14.1, "About Authentication Mechanisms" for more information on authentication mechanisms and how authentication mechanisms are mapped to authentication engines.

5.15.10 Authentication Engines - JAAS

Surrounding text describes authenjaas.gif.

The JAAS authentication engine is the default authentication engine for the Oracle Identity Federation server.

Use the Enable Authentication Engine check-box to enable or disable this engine.

Since JAAS is the default engine, this box is checked by default. To disable the JAAS authentication engine, another engine must be available to serve as the default engine. If necessary, first set up a different authentication engine, then return to this tab to disable the JAAS engine.

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

Note:

The JAAS authentication engine does not support logout. This means that after you configure a provider to use the engine, perform single sign-on between IdP and SP, and issue the Oracle Identity Federation logout URL http://host:port/fed/user/logout, the user is not logged out and can repeat the SSO flow without having to log in again.

Creating and Adding Users to the oifusers Group

For a user to be authenticated by the JAAS authentication engine, a corresponding user entry must exist in the security realm of the WLS Domain where Oracle Identity Federation is deployed, and must be part of the oifusers group.

Follow these steps to create the oifusers group and add new users.

  1. Log in to Oracle WebLogic Server's Administration Server console.

  2. On the left-hand pane, select Security Realms and navigate to myrealm, then Users and Groups, then Groups.

  3. Click New and enter name oifusers.

  4. Navigate to Users and Groups, then Users.

  5. Click New and select a name and password.

  6. Click the user you just created and select the Groups tab.

  7. Select group oifusers and move it to the Chosen column. Click Save.

To enter additional users, repeat steps 4-7. After the group and users have been created, you must restart the Administration server and managed server where Oracle Identity Federation is running in order for the changes to take effect.

5.15.11 Authentication Engines - Custom

Surrounding text describes authencust1.gif.

On this tab, you can set up a custom authentication engine.

View Custom Engines

Use the View button to organize the table of custom engines. You can change the column order of the display and specify which fields to include or exclude. The Reorder Columns dialog allows you to select any field and use the arrows to reposition it in the table.

Surrounding text describes authencust2.gif.

Add an Engine

Click Add to add a new custom engine. You are asked to provide a unique engine name; an Engine ID is automatically generated. Once the engine is added, you can add this information:

  • Enabled - Check the box to enable the engine, or uncheck to disable it.

  • Web Context - Specifies the Web application context in which your custom authentication engine is deployed.

  • Authentication Relative Path - Specifies the path to your custom authentication engine, relative to the Web context.

  • Logout Relative Path - Specifies the path to the logout service (if any) for your custom authentication engine, relative to the Web context. For example, "/auth_engines/myAuthLogout.jsp".

The tab contains these fields:

  • Default Authentication Engine - This is the engine used for authentications. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.

  • Enable Authentication Engine - Check this box to enable the engine, or uncheck the box to disable the engine. If enabled, this engine appears on the list of available engines (in the list-box associated with Default Authentication Engine).

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

5.16 Configuring SP Integration Modules

Use this page to configure the SP integration module for Oracle Identity Federation.

This page consists of tabs devoted to individual SP integration module. Updates on any tab are saved as you move to other tabs. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

5.16.1 SP Integration Module - Oracle Single Sign-On

Use this tab to configure SP integration for Oracle Single Sign-On.

Surrounding text describes spintosso.gif.

The tab contains these fields:

  • Default SP Integration module - This is the module used for integration at the service provider. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.

  • Enable SP module - Check this box to enable the module, and uncheck the box to disable the module. If enabled, this module appears on the list of available modules (in the list-box associated with Default SP Integration module).

  • Authentication mechanism - authentication mechanism that will be used to locally authenticate users if Federated Identities are used during Federation SSO and if a Federation Record needs to be created during the SSO operation.

  • Username Attribute - Username Attribute that Oracle Identity Federation needs to provide to Oracle SSO. Default is uid.

  • Login URL - This is the Oracle Single Sign-On server URL to present at login. For example:

    http://sso_host:sso_port/sso/auth
    
  • Logout URL - This is the Oracle Single Sign-On server URL to present at logout. For example:

    http://sso_host:sso_port/sso/logout
    
  • Logout Enabled – Enable/disable logout for the Oracle Single Sign-On application.

The Regenerate button would create an encryption key that will be saved in a file and provided to the Oracle SSO Server.

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

5.16.2 SP Integration Module - Oracle Access Manager 11g

Use this tab to configure SP integration for Oracle Access Manager 11g.

Note:

In release 11.1.1.7.0, an additional step is needed before you regenerate the OAM 11g Secret Key from this page. See the release notes for details.

Surrounding text describes spintoam11.gif.

The tab contains these fields:

  • Default SP Integration module - This is the module used for integration at the service provider. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.

  • Enable SP module - Check this box to enable the module, and uncheck the box to disable the module. If enabled, this module appears on the list of available modules (in the list-box associated with Default SP Integration module).

  • Authentication mechanism - This is the authentication mechanism that will be used to locally authenticate users if federated identities are used during federation SSO and if a federation record needs to be created during the SSO operation.

  • Username Attribute - This is the username attribute that Oracle Identity Federation needs to provide to Oracle Access Manager. The default is cn.

  • Login URL - This is the Oracle Access Manager server URL to present at login. For example:

    http://oam_host:oam_port/oam/server/dap/cred_submit
    
  • Logout URL - This is the Oracle Access Manager server URL to present at logout. For example:

    http://oam_host:oam_port/oam/server/logout
    
  • Logout Enabled – Enable/disable logout for Oracle Access Manager.

The Regenerate button generates a keystore file that contains the keys used to encrypt and decrypt the tokens that are exchanged between the Oracle Access Manager and Oracle Identity Federation servers.

Note:

In release 11.1.1.7.0, an additional step is needed before you regenerate the OAM 11g Secret Key from this page. See the release notes for details.

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

5.16.3 SP Integration Module - Oracle Access Manager 10g

Use this tab to configure SP integration for Oracle Access Manager.

Surrounding text describes spintoam.gif.

See Also:

Section 3.2.4.3, "Integrate Oracle Access Manager as an SP Integration Module" for details about configuring Oracle Access Manager as an SP integration engine.

The tab contains these fields:

  • Default SP Integration module - This is the module used for integration at the service provider. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.

  • Enable SP module - Check this box to enable the module, and uncheck the box to disable the module. If enabled, this module appears on the list of available modules (in the list-box associated with Default SP Integration module).

  • Authentication mechanism - The authentication mechanism that will be used to locally authenticate users if federated identities are used during federation SSO and if a federation record needs to be created during the SSO operation.

  • Access Server SDK directory – Directory location of Access Server SDK. Absolute path or relative to DOMAIN_HOME.

  • Default Authentication Scheme – The authentication scheme in Oracle Access Manager that will be used as default scheme for the policy created by Oracle Identity Federation.

  • Cookie Domain - Cookie domain that Oracle Identity Federation sets when creating the Oracle Access Manager cookie.

  • Cookie duration - For a persistent cookie, the time in minutes during which the cookie will be valid; for a session cookie, enter 0.

  • Cookie Secured Flag Set - Check whether the cookie should be marked as secure: in this case, the browser will send the cookie over an HTTPS connection.

  • Logout Enabled – Enable/disable logout for the Oracle Access Manager application.

  • Clear Cookie – If checked, resetting the Oracle Access Manager cookie is enough for Oracle Identity Federation to log the user out of the Oracle Access Manager domain.

  • Redirect to Logout URL - Check Redirect to Logout URL and fill in the URL if Oracle Identity Federation needs to redirect the user to a specific URL for Oracle Access Manager logout.

Note:

When the user needs to be redirected to an Oracle Access Manager URL for logout (in case Oracle Access Manager needs to perform extra operations), you need to configure Oracle Identity Federation by checking the Redirect to Logout URL box, and entering the URL to which the user is redirected. When Oracle Identity Federation redirects the user to that URL, it appends a return URL as a query parameter; this is the Oracle Identity Federation URL to which the user is redirected after performing the extra Oracle Access Manager operations.

The query parameter to be appended to the Oracle Access Manager logout URL is referenced by returnurl.

The tab contains these fields needed to integrate Oracle Access Manager with Oracle Identity Federation:

  • Oracle Access Manager credentials needed to configure the policy domain

  • Oracle Identity Federation account information to enable that server to authenticate itself to Oracle Identity Federation

For details about using these features, see Section 3.2.4.3, "Integrate Oracle Access Manager as an SP Integration Module" and Section 3.2.5, "Oracle Identity Federation/SP Authenticating to Oracle Access Manager".

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

5.16.4 SP Integration Module - Test SP Engine

Use this tab to configure SP integration for the test SP engine.

Surrounding text describes spinttest.gif.

The tab contains these fields:

  • Default SP Integration module - This is the module used for integration at the service provider. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.

  • Enable SP module - Check this box to enable the module, and uncheck the box to disable the module. If enabled, this module appears on the list of available modules (in the list-box associated with Default SP Integration module).

  • Authentication mechanism - authentication mechanism that will be used to locally authenticate users if federated identities are used during federation SSO and if a federation record must be created during the SSO operation.

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.

5.16.5 SP Integration Module - Custom

Use this tab to configure SP integration for the custom SP engine.

Surrounding text describes spintcustom.gif.

The tab contains these fields:

  • Default SP Integration module - This is the module used for integration at the service provider. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.

  • Enable SP module - Check this box to enable the module, and uncheck the box to disable the module. If enabled, this module appears on the list of available modules (in the list-box associated with Default SP Integration module).

View SP integration modules

Use the View button to organize the table of SP integration modules. You can change the column order of the display and specify which fields to include or exclude. The Reorder Columns dialog allows you to select any field and use the arrows to reposition it in the table.

Add an Engine

Surrounding text describes spintaddcust.gif.

Click the Add button to add a new custom engine. You are asked to provide a unique engine name; an Engine ID is automatically generated. Once the engine is added, you can add this information:

  • Enabled - Check the box to enable the engine, or uncheck to disable it.

  • Authentication mechanism – authentication mechanism to use if a local authentication procedure needs to occur during the assertion processing

  • Web Context - Specifies the contextPath of the SP integration engine in the Web Context field. For example: /engine.

  • Authentication Relative Path - Specifies the relative path of the login service of the SP integration engine in the Login Relative Path field. For example: /application.jsp.

  • Logout Relative Path -Specifies the relative path of the logout service of the SP integration engine in the Logout Relative Path field.

Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.