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:

  • Server Configuration Data, which includes properties that determine the runtime behavior of a federation server instance

  • User Federation Data, including details about individual users' federated identities and usage information

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

Caution:

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

The federation data can be deleted:

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.

  • 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.4, "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 will redirect the user to the returnURL once the logout operation is done, and it will append 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 will only log the user out of the Authentication Engines and Identity and Access Management framework, and it will destroy the Oracle Identity Federation session.

  • Parallel Logout

    By default, when performing a SAML/WS-Fed Global Logout operation, Oracle Identity Federation will sequentially redirect the user to all the providers that the user needs to be logged out from. This can become a time consuming operation and if the logout flow is broken at one point because a provider is unresponsive, then the logout flow will not be finished. 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:

  • Check the Enable Identity Provider box.

  • Specify the Provider ID.

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

    Note:

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

Assertion Settings

Specify assertion parameters as follows:

  • Send Signed Assertion

    This determines whether the assertions issued by the identity provider will be signed.

  • Assertion Validity

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

  • Reauthenticate After

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

Protocol Settings

Specify protocol settings as follows:

  • Artifact Timeout

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

  • Include Signing Certificate in XML Signatures

    If checked, Oracle Identity Federation will add its signing certificate to the XML Digital Signature element of outgoing messages. This can be useful when the remote provider needs the signing certificate included in the message to be able to verify the signature created by Oracle Identity Federation.

  • Common Domain

    See Also.:

    Section 6.10, "Configuring the SAML 2.0 IdP Discovery (Common Domain Cookie) Profile"

    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 Enable Common Domain to specify that this IdP should set the introduction cookie. After every local authentication, Oracle Identity Federation redirects the user to the common domain, where the server can add its identifier to the introduction cookies at the user's browser.

    Setting the common domain requires these parameters:

    • Common Domain URL

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

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

      Set this value only if you enabled the common domain.

    • Name

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

    • Cookie Lifetime

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

  • SSO User Opt-In/Opt-Out

    Determines if a user has given (or denied) permission to perform federated single sign-on for the user, based on the value of an attribute in the user's directory record.

    See Also:

    Section 6.18, "User Opt-In and Opt-Out for Single Sign-On" for details

  • Reauthenticate when Missing User Session Attributes

    When Oracle Identity Federation acts as an IdP, it can use attributes stored in the session to populate the assertion. The session attributes are set:

    • during authentication, where a custom authentication engine provides attributes to be stored in the Oracle Identity Federation user session

    • when Oracle Identity Federation acts as a service provider. The content of the assertion (NameID, attributes...) can be saved in the user session; by default that data is not saved.

    When the assertion is created, Oracle Identity Federation/IdP will list the attributes it needs to retrieve from the user session and include in the assertion. If some attributes required in the assertion are missing from the user session, Oracle Identity Federation can be configured to either dismiss those attributes, or to invoke the authentication framework so that the custom authentication engine can provide those attributes to Oracle Identity Federation.

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.

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

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.

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

  

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

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.

    See Also:

    Section 1.2.4.8, "Federation Termination Profile"

    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.

    See Also:

    Section 1.2.4.5, "Name Identifier Management Profiles"

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

    See Also:

    Section 5.6.6, "Configuring Oracle Identity Federation as an IdP Attribute Responder"

  • 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 to 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 to is found in the session created when the user is authenticated.

  • NameID Format - This column displays the available NameID formats.

  • User Attribute Mapping - Lists the available name ID formats. 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. The name identifier 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

    		  

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

    See Also:

    Section 6.11, "Configuring the Identity Provider Discovery Service"

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

    See Also:

    Section 6.10, "Configuring the SAML 2.0 IdP Discovery (Common Domain Cookie) Profile"

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

    See Also:

    Section 5.6.5, "Configuring Oracle Identity Federation as an SP 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.

    See Also:

    Section 5.6.5, "Configuring Oracle Identity Federation as an SP Attribute Requester"

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.

See Also:

Section 5.14, "Configuring Authentication Mechanisms"
Surrounding text describes oifspcomssoadd.gif.

5.5.2 Configure Service Provider - SAML 2.0

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.

See Also:

Section 6.17, "Automatic Account Linking Based on Attribute Query Mapping"

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.

    See Also:

    Section 1.2.4.5, "Name Identifier Management Profiles"

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

    See Also:

    Section 5.14, "Configuring Authentication Mechanisms"

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

Note:

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

Note:

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.

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.3 Configure Service Provider - SAML 1.x

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 Service Provider - WS-Federation 1.1

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

    • authz_attribute Authorization Plugin - uses the Attribute Requester Service to retrieve attribute values for the user's SubjectDN and evaluates a rule expression with the attribute values to determine if access is allowed

    Note:

    The authentication and authorization 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 Access Manager Access Administration Guide 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 Access Manager Access Administration Guide 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 Access Manager Access Administration Guide 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.2, "Configuring SSL for Oracle Identity Federation".

5.6.6 Configuring Oracle Identity Federation as an IdP Attribute Responder

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

  • the attributes to send

  • attribute name mapping

  • attribute value mappings

  • attribute value filters

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:sequence>
                                        <xs:element ref="orafed-arxs:Value" minOccurs="0" maxOccurs="unbounded"/>
                                </xs:sequence>
                                <xs:attribute name="Name" type="xs:ID"/>
                        </xs:complexType>
                        <xs:element name="Attribute" type="orafed-arxs:AttributeType"/>
 
                        <xs:complexType name="AttributeRequestType">
                <xs: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://stadm04.us.oracle.com:7778/fed/ar/soap"/>
                </wsdl:port>
        </wsdl:service>
</wsdl:definitions>

The types and message sections define the contents of the AttributeRequest and AttributeResponse messages.

The built-in XML Scheme type ID is used for the Name attribute of the Attribute elements; this type approximates the desired syntax for attribute names (letters, numbers, '"_", "-", and ".") However, ID (which is derived from the XML NCName type) also includes a number of Unicode combining characters and extenders.

See Also:

The W3C specification, Namespaces in XML, at http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName

The binding and service sections specify how the messages are to be sent over SOAP and HTTP(S).

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

Oracle Identity Federation supports attribute mapping for the following:

  • Attribute Authority

  • Attribute Requester

  • Identity Provider, when sending attributes in SSO assertions

Oracle Identity Federation provides the following attribute mapping capabilities:

  • Attribute Name Mapping: maps local attribute names to external attribute names used in 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.

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

See Also:

Section 5.11, "Configuring Federations"

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

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

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

    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

  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

Some examples of value filter configuration are presented in this section.

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.

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

See Also:

Getting Started with Oracle WebLogic Server Administration Console in the Oracle Fusion Middleware Administrator's Guide.

  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 created 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 and 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.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 about redundancy data stores, 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:

See Also:

Getting Started with Oracle WebLogic Server Administration Console in the Oracle Fusion Middleware Administrator's Guide.

  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

See Also:

A Note About the LDAP Schema in Section 2.4.1, "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 Store.

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:

See Also:

Getting Started with Oracle WebLogic Server Administration Console in the Oracle Fusion Middleware Administrator's Guide.

  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 file system by default during a basic install. To change 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:

See Also:

Getting Started with Oracle WebLogic Server Administration Console in the Oracle Fusion Middleware Administrator's Guide.

  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 is able to 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 will not get saved in the RDBMS, and thus the configuration changes will not get 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.7.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.

See Also:

Section 5.14.1, "About Authentication Mechanisms"

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:

See Also:

Section 5.5, "Configuring Service 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 authentication engines for the Oracle Identity Federation server.

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 - 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.2 Authentication Engines - Oracle Access Manager

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

See Also:

Getting Started with Oracle WebLogic Server Administration Console in the Oracle Fusion Middleware Administrator's Guide.

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

See Also:

Section 6.12, "Setting up Infocard".

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

    See Also:

    Section 5.15.7.1, "About 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.7.1 About the Federated SSO Proxy Authentication Engine

When an identity provider uses the Federated SSO Proxy authentication engine to authenticate a user, it will do this by taking the role of service provider, and initiating a Single Sign-On flow with a second identity provider that will authenticate 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.7.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 will use 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 will select http://corp-1.com/idp as the identity provider, but if the service provider requests oracle:fed:authentication:password-protected, Oracle Identity Federation will choose http://corp-2.com/idp. If the service provider does not request an authentication method, then Oracle Identity Federation will send 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:

See Also:

Section 5.5, "Configuring Service 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 on Configure SSO Authentication Mechanism to Identity Provider Mapping.

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

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

See Also:

Getting Started Managing Oracle Fusion Middleware

  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.9 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".

See Also:

Section 3.2.5.2, "Creating a Custom 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, 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

Use this tab to configure SP integration for Oracle Access Manager.

Surrounding text describes spintoam.gif.

See Also:

Integrate Oracle Access Manager as an SP Integration Module for details about configuring Oracle Access Manager as an SP integration module.

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.

  • Access Server SDK directory – Directory location of Access Server SDK. Absolute path or relative to DOMAIN_HOME.

  • Default Authentication Scheme – The authentication scheme in the Oracle Access Manager that will be used as default authentication scheme for the policy created by Oracle Identity Federation.

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

  • Cookie duration - For a persistent cookie, enter 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 will append 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.

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 - 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 needs to 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.4 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.

See Also:

Section 3.2.5.3, "Creating a Custom SP Integration 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.