Configuring Identity Providers - Common Properties

Configuring Oracle Identity Federation 5-11 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 providers 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-InOpt-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. ■ 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 FederationIdP 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: See Also: Section 6.18, User Opt-In and Opt-Out for Single Sign-On for details 5-12 Oracle Fusion Middleware Administrators Guide for Oracle Identity Federation ■ Configure SAML 2.0 IdP Properties ■ Configure SAML 1.x IdP Properties ■ Configure WS-Federation IdP Properties ■ Configure OpenID IdP Properties

5.4.1 Configure SAML 2.0 IdP Properties

Assertion Properties Use this part of the page to maintain assertion name identifier formats for the SAML 2.0 protocol. Provide the following information in the table: ■ Enabled - Check a box to enable the desired formats that the Oracle Identity Federation instance will use as the SAML 2.0 name identifier value in IdP mode. ■ Default - Use the radio button to select a default NameID format. ■ Get Value from User Session - Check a box to specify that the attribute, to which the corresponding NameID maps, is found in the session created when the user is authenticated. ■ NameID Format - This column displays the available name identifier formats. The formats are as follows: Table 5–1 SAML 2.0 IdP NameID Formats NameID Format Default X.509 Subject Name dn Email Address mail Windows Domain Qualified Name empty Kerberos Principal Name empty Custom Configuring Oracle Identity Federation 5-13 ■ User Attribute Mapping - Enter the attribute name for the selected name ID format. Oracle Identity Federation uses the attribute name to perform a lookup in the user data store or user session if Get Value from User Session is checked for a name ID in this format. Name of Custom Format - This is the format to use in the NameID, when creating an assertion that will use the custom NameID format. UserID as the NameID You can set the user attribute in the Assertion Subject NameID Formats table to orafed-userid to use the UserID to populate the NameID element. This feature is particularly useful when there is no user store configured for the IdP, and thus, no user store attributes available. Unspecified Persistent Identifier TransientOne-Time Identifier None Note: You can set the user attribute in the Assertion Subject NameID Formats table to orafed-userid to use the UserID to populate the NameID element. This is specially useful when no user store is configured for the IdP and thus no user store attributes are available. Note: This table is used when creating an outgoing assertion. Depending on the NameID format, Oracle Identity FederationIdP 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 Cont. SAML 2.0 IdP NameID Formats NameID Format Default