Oracle® Fusion Middleware Administrator's Guide for Oracle Identity Federation 11g Release 1 (11.1.1) E13400-02 |
|
![]() Previous |
![]() Next |
This chapter describes configuration tasks for Oracle Identity Federation. It contains these topics:
Configuring Identity Providers - Protocol-Specific Properties
Configuring Attribute Sharing with the Oracle Access Manager AuthZ Plug-in
Configuring Identity Provider to send attributes in SSO Assertions
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
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.
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:
using the LDAP server's or database's administration tools. For data stored in Oracle Internet Directory, see Oracle Identity Management User Reference to obtain more information.
using a command-line utility provided with Oracle Identity Federation. For details, see Chapter 9, "Oracle Identity Federation Command-Line Tools".
Server properties include:
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:
|
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:
|
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.
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.
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
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.
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.
This section describes how to configure IdP protocol-specific properties:
Assertion Properties
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:
|
Table 5-1 SAML 2.0 IdP NameID Formats
NameID Format | Default |
---|---|
X.509 Subject Name |
dn |
Email Address |
|
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
Enable SAML 2.0 Protocol - Check this box to enable the SAML 2.0 protocol.
Enable Single Sign-On Protocol - Check this box to enable the single sign-on protocol.
Enable NameID Management Protocol: Terminate
Check this box to enable the federation termination capability.
Note: This property affects server metadata. When updating this property, distribute the updated metadata to all trusted providers. |
Enable NameID Management Protocol: Register - Check this box to enable name ID registration.
Enable Attribute Query Responder
Check this box to enable the identity provider to act as an attribute authority.
Note: This property affects server metadata. When updating this property, distribute the updated metadata to all trusted providers. |
Use Identity Federation for Attribute Response
Check this box if you wish the user in the attribute request to be located in this identity provider using its federated identity. Note that if using this setting, the user must have a federation identity and its Name ID value and format must match the subject value and format specified in the AttributeQuery
.
When this box is checked, the attribute authority first tries to look up the user in the federation store; if no records are found, it locates the user by attribute value from the user data store.
This property may also be overridden on the Edit Trusted Provider page on the Oracle Identity Federation Settings tab.
Enable Authentication Query Responder
In SAML protocols, an identity provider may act as an authentication authority. A service provider may send an authentication query to an Authentication authority to ask "What assertions used for authentication have been issued for this subject"? The Authentication authority responds by providing the assertions that have been previously issued for authentication of the given subject.
Check this box to enable the identity provider to act as an Authentication authority.
Note: This property affects server metadata. When updating this property, distribute the updated metadata to all trusted providers. |
Enable Assertion ID Responder
In SAML protocols, an identity provider may act as an assertion ID authority. A trusted service provider may send an assertion ID request to an assertion ID authority in which it provides the unique ID of an assertion previously issued by the identity provider. The assertion ID authority responds by providing the assertion with the ID in the request.
Check this box to enable this identity provider to act as an assertion ID authority.
Note: This property affects server metadata. When updating this property, distribute the updated metadata to all trusted providers. |
Enable Protocol Bindings
In the drop down, select all protocol bindings you wish to enable.
Default Binding
Select the binding to be used as a default when the identity provider sends a request or response (excluding SSO Responses) and no preferred binding was specified. e.g. in Name ID Management Protocol messages.
Default SSO Response Binding
Select the binding to be used as a default when the identity provider sends an SSO Response and no preferred binding was specified in the AuthnRequest.
Messages to Send/Require Signed
specify the messages that Oracle Identity Federation sends, in IdP mode, that it must sign; and the messages it receives, in IdP mode, that it requires signed.
Note: The Require AuthnRequest Signed property affects server metadata. When updating this property, distribute the updated metadata to all trusted providers. |
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
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:
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.
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.
Use this page to configure Oracle Identity Federation to use the WS-Federation 1.1 protocol when acting as an identity provider.
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.
This section describes how to edit and update the protocol-specific service provider (SP) properties in Oracle Identity Federation. It contains these sub-sections:
Use this table to configure SP properties common to all protocols.
Assertion Settings
Enable Map Assertion to User Account - Check this box if you wish Oracle Identity Federation to map the assertion to a user account. Disable it if you wish to implement a custom SP Engine to do the mapping instead.
Anonymous User ID - Enter the User ID that will be passed to the SP engine if the assertion received cannot be mapped to a user account, either because mapping assertions to user accounts is disabled or the format of the Name ID in the assertion is 'transient'.
Ignore Unknown Condition - Check this box to have the service provider ignore any conditions it does not recognize in the assertion sent by the identity provider.
Require Signed Assertions - Check this box to require assertions received from identity providers to be signed.
Protocol Settings
Default SSO Identity Provider - Select the identity provider to which requests should be sent as a default when an SSO operation is initiated and no preferred identity provider is specified.
Unsolicited SSO RelayState - When an Oracle Identity Federation SP receives an unsolicited assertion, it sends the user to the relay state specified by the assertion following the SSO operation; if the relay state field in the assertion is empty, it will use the Unsolicited SSO RelayState to redirect the user.
Include Signing Certificate in XML Signatures - check this box to have Oracle Identity Federation include the signing certificate in the signature when signing XML messages.
Enable Identity Provider Discovery Service
Oracle Identity Federation provides a service, called the Identity Provider Discovery Service, in which the user can be redirected to a custom page in which he can select the identity provider from which he wishes to authenticate.
Check this box to enable the Identity Provider Discovery Service, and enter the Service URL of the custom page where the user can select the identity provider to be used.
Enable Common Domain Cookie Service
When an identity federation network contains multiple identity providers, a service provider needs to have a way to determine the identity provider(s) in use by a principal. This is achieved by utilizing a domain that is common to IdPs and SPs in the federation network, and sending to the user's browser a cookie, written in this domain, that lists all the IdPs where the user is logged in. Such a domain is known as a common domain, and the cookie identifying the IdPs is called a common domain cookie or introduction cookie.
Check this box to specify that this SP should read the introduction cookie, and enter the Service URL where Oracle Identity Federation will read the introduction cookie.
Enable Attribute Requester Service - check this box to enable this service provider to act as an Attribute Requester.
Note: This property affects server metadata. When updating this property, distribute the updated metadata to all trusted providers. |
Configure Attribute Requester Service
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.
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.
Use this tab to maintain Oracle Identity Federation properties in service provider mode under the SAML 2.0 protocol.
Assertion Settings
Choose one of these methods of assertion mapping by checking the associated box:
Federated Identity
Attribute Query
Subject NameID
If mapping users through federated identity, check the box labeled Enable Auto Account Linking.
If mapping users through attribute query, enter the query string in the associated box.
If mapping users through subject NameID, check the box and select the applicable NameID formats from the table titled Assertion Subject NameID Formats. Provide this information in the table:
Check the corresponding Enabled box to enable the desired format(s) that the Oracle Identity Federation instance will support in SP mode.
NameID Format - This column displays the available SAML 2.0 NameID formats.
User Attribute Mapping - Enter the attribute name for the selected name ID format. Oracle Identity Federation will use this attribute name to perform a lookup in the user data store for a name ID in this format.
The name identifier formats are as follows:
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
Provide the following information:
Enable SAML 2.0 Protocol - Check the box to enable this protocol for the SP.
Enable Single Sign-On Protocol - Check the box to enable the single sign-on protocol.
Enable NameID Management Protocol: Register - Check the box to enable NameID registration.
Enable Federation Termination Protocol - Check this box to enable the federation termination protocol.
See Section 1.2.4.8, "Federation Termination Profile" for an explanation of this feature.
Send Encryption NameIDs - Check this box to enable Oracle Identity Federation to send encrypted name identifiers to peer providers.
Send Encryption Attributes - Check this box to enable Oracle Identity Federation to send encrypted attributes to peer providers.
Allow Federation Creation - Check this box to allow federation creation. This is required if you configure the SP to request persistent NameID format as described below.
Force User Consent - Check this box to force consent for setting up a new federation. A user who is redirected to the federation server will explicitly have to accept or deny account linking in order to proceed.
User Consent URL - Enter the URL to be displayed to the user to obtain consent for federation.
The server passes a number of query parameters to this URL:
See Also: Section 5.4.1, "Configure SAML 2.0 IdP Properties" for an example showing how the query parameters are used. |
Table 5-5 Parameters Passed to User Consent URL (Local Setting)
Parameter | Description |
---|---|
providerid |
This is the peer provider id. |
description |
This is the description of the peer provider id. |
returnurl |
This is the URL to which the user should be directed once a consent decision has been made. |
refid |
This is passed as a query parameter to the returnurl. Oracle Identity Federation require this parameter in order to resume the operation the server had been performing prior to redirection to the consent URL. |
Enable Protocol Bindings - Specify the valid bindings using the drop-down list.
Default Binding - Specifies the preferred binding to use, when possible, in sending messages to peer providers. Valid values are:
HTTP Redirect
HTTP POST
HTTP Post Simple Sign
SOAP
Default SSO Request Binding - Specifies the preferred binding for the service provider to use, when possible, in sending authentication requests to the identity provider. Use only if this server instance is acting as a service provider. Valid values are:
HTTP Redirect
HTTP POST
HTTP Post Simple Sign
Default SSO Response Binding - Specifies the preferred binding for the identity provider to use, when possible, in sending an assertion to the service provider. Valid values are:
Artifact
HTTP POST
HTTP POST Simple Sign
Default Authentication Request NameID Format - Use the list box to select a default name ID format for authentication requests. Choices are:
X.509 Subject Name
Email Address
Windows Domain Qualified Name
Kerberos Principal Name
Persistent identifier
Transient/one-time identifier
Unspecified
If the default authentication request NameID format at the SP is unspecified, the IdP will use the default assertion NameID format when creating the assertion (for example, email NameID format).
Request Authentication Context Mechanism - Use this list box to select the authentication mechanism that this service provider will specify in the AuthnRequest to the identity provider.
Request Authentication Context Comparison - Use the list box to select the authentication context comparison that this service provider will specify in the AuthnRequest sent to the identity provider.
Messages to Send/Require Signed
Use this table when configuring a service provider to specify which message types that provider should send signed and/or require signed.
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. |
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.
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:
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. |
Use this page to configure Oracle Identity Federation to use the WS-Federation 1.1 protocol when acting as a service provider.
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.
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:
Configuring Oracle Identity Federation as an SP Attribute Requester
Configuring Oracle Identity Federation as an IdP Attribute Responder
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.
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.
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. |
Log in to the Access Server host as the user who installed the Access Server.
Create the directory INSTALLDIR/oblix/config/attributePlug-in
, if it does not already exist.
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.
Edit the attributes and elements of the config.xml
file as required.
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:
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
.
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
.
Restart the Access Server to ensure that the plug-in uses the PEM
files.
This section explains how to configure Oracle Access Manager schemes and policies for Oracle Identity Federation. It contains these sections:
Take these steps:
See Also: Oracle Access Manager Access Administration Guide for details about the Web-based user interface. |
Log in to the Oracle Access Manager System Console as a Master Access Administrator. Select the Access System Configuration panel and Authentication Management.
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 theObSSOCookie , 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.
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)))" |
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 |
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 |
Return to the Steps panel and remove the now-unused Default step.
Return to the General panel and enable the authentication 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. |
Log in to the Oracle Access Manager System Console as a Master Access Administrator. Select the Access System Configuration panel and Authorization Management.
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.
Take these steps to configure an Oracle Access Manager policy using the Attribute Sharing profile:
Log in to Oracle Access Manager as a Master or Delegated Access Administrator. Select Create Policy Domain.
Fill out the General panel form:
Name: as appropriate (for example, Oracle Identity Federation Attribute Sharing Test)
Description: as appropriate
Click Save.
Select the Resource panel and add one or more resource URL prefixes to protect (for example, /attribute-test
).
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.
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.
Select the Default Rules panel and add the default authentication rule:
Name: as appropriate
Description: as appropriate
Authentication Scheme: OIF Attribute Sharing
Click Save.
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.
Alternatively, you can add policies to the policy domain with authorization expressions for subsets of the protected URLs.
Take these steps to configure Oracle Identity Federation as an attribute requester in service provider mode:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
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. |
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.
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.
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. |
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. |
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:
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
If using HTTP Basic Authentication without Oracle HTTP Server, see Section 6.9.2, "HTTP Basic Authentication".
If using client certificate authentication, see Section 8.2, "Configuring SSL for Oracle Identity Federation".
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
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. |
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.
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.
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. |
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. |
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.
To configure SSL for the server, see Section 8.2, "Configuring SSL for Oracle Identity Federation".
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:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Federations.
Select the service provider with which you want to configure attribute sharing, and click Edit.
Select Update Manually.
Under the Oracle Identity Federation Settings tab, check Enable Attributes in Single Sign-On.
Below, check the boxes to specify the Name ID formats for which attributes will be sent in assertions.
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.
This section describes the Oracle Identity Federation's Attribute Requester Service Interface. It contains these topics:
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:
The web service client sends an AttributeRequest message using the SOAP protocol.
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
.
Oracle Identity Federation applies, for the specific remote IdP, the attribute value mapping for the optional attribute values listed in the AttributeRequest.
Oracle Identity Federation applies, for the specific remote IdP, the attribute name mapping for the optional attribute listed in the AttributeRequest.
Oracle Identity Federation sends the AttributeQuery
to the remote IdP.
Oracle Identity Federation receives the response containing the assertion, along with the attributes sent by the IdP.
Oracle Identity Federation applies, for the specific remote IdP, the attribute name mapping for the attribute names listed in the assertion's AttributeStatement
.
Oracle Identity Federation applies, for the specific remote IdP, the attribute value mapping for the attribute values listed in the assertion's AttributeStatement
.
Oracle Identity Federation builds the AttributeResponse
message, and returns it to the web service client in a SOAP response 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:
|
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.
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>
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, athttp://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).
This section explains how to configure the attribute mapping functionality in Oracle Identity Federation. It contains these topics:
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:
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.
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.
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
In addition to these comparison types, filtering supports regular expressions, allowing the user to match the attribute value against a regular expression. See Section 5.9.2.3.1, "Filtering Conditions" in the sectionSection 5.9.2.3, "Configuring Attribute Value Filtering" for details.
The filtering rules allow you to specify whether the comparison will be case-sensitive.
Oracle Identity Federation exercises attribute value filtering when acting as a:
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.
This section explains how to configure mapping and filtering:
Configuration of attribute name mapping serves these purposes:
On the IdP side:
mapping attribute names contained in assertions to local attribute names
determining which local attributes can be sent to the peer provider. Defining an attribute name mapping for a peer provider will authorize Oracle Identity Federation to send this attribute to the remote server.
On the SP side
mapping attribute names contained in SOAP client requests to names in Attribute Queries to the attribute authority
Take these steps to define attribute name mappings:
On the IdP Side
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Federations.
Select the Attribute Requester with which you want to configure attribute sharing, and click Edit.
Click Edit Attribute Mappings and Filters.
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
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Federations.
Select the attribute authority with which you want to configure attribute sharing, and click Edit.
Select Update Manually; under Oracle Identity Federation Settings, click Edit Attribute Mappings and Filters.
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 |
emailaddress | |
id | idnumber |
Name Mapping in IdP:
Assertion Attribute | User Attribute |
---|---|
lastname | sn |
idnumber | employeenumber |
telephone | telephonenumber |
title | title |
username | uid |
emailaddress | |
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 |
emailaddress | emailaddress | |||
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
.
Take these steps to define attribute value mappings:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Federations.
Select the peer provider with which you want to configure attribute sharing, and click Edit.
Select Update Manually; under Oracle Identity Federation Settings, click Edit Attribute Mappings and Filters.
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.
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Federations.
Select the Attribute Requester with which you want to configure attribute sharing, and click Edit.
Select Update Manually; under Oracle Identity Federation Settings, click Edit Attribute Mappings and Filters.
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.
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, theignoreCase 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) |
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 |
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:
Signing and encryption certificates for this server instance are stored in wallets. Use this page to manage the signing and encryption wallets.
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.
Use this page to:
specify metadata signing requirements
generate updated metadata
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.
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)
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.
This section explains how to configure and manage the different data stores used by Oracle Identity Federation:
This section explains how to configure user data stores for use by Oracle Identity Federation:
Configuring Oracle Identity Federation for RDBMS User Data Store
Configuring Oracle Identity Federation for an LDAP 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:
Create a JDBC Data Source
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. |
Log in to the WebLogic Administration Console.
Navigate to Services, then JDBC, then Data Sources.
Click New.
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
Follow these steps to configure an RDBMS user data store:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance
Navigate to Administration, then Data Stores.
In the User Data Store section, click Edit.
Select Database from the Repository Type dropdown list.
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.
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 | |
---|---|---|---|---|
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
Follow these steps to configure and LDAP user data store:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance
Navigate to Administration, then Data Stores.
In the User Data Store section, click Edit.
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.
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.
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:
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
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".
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:
Configuring Oracle Identity Federation for an RDMBS Federation Data Store
Configuring Oracle Identity Federation for an LDAP Federation Data Store
Configuring Oracle Identity Federation for an XML Federation Data Store
Configuring Oracle Virtual Directory as Federation Data Store
The high-level steps to configure an RDBMS federation data store are:
Create a JDBC data source.
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 formPREFIX _OIF ; you will need to provide this information when configuring Oracle Identity Federation. |
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. |
Log in to the WebLogic Administration Console.
Navigate to Services, then JDBC, then Data Sources.
Click New.
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
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Data Stores.
In the Federation Data Store section, click Edit.
Select Database from the Repository Type dropdown list.
Enter the JNDI Name; use the JNDI of the Data Source created in the WebLogic Administration Console.
Click OK.
Follow these steps to configure an LDAP federation data store:
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:
|
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.
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. |
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Data Stores.
In the Federation Data Store section, click Edit.
Select XML file from the Repository Type dropdown list.
Click OK.
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.
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.
Follow these steps to configure Oracle Identity Federation to use an in-memory session/message data store:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Data Stores.
In the Session Data Store and Message Data Store section, click Edit.
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:
Create a JDBC Data Source.
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 formPREFIX _OIF ; you will need to provide this information when configuring Oracle Identity Federation. |
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. |
Log in to the WebLogic Administration Console.
Navigate to Services, then JDBC, then Data Sources.
Click New.
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
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Data Stores.
In the Configuration Data Store section, click Edit.
Select Database from the Repository Type dropdown list.
Enter the JNDI Name; use the JNDI of the Data Source created in the WebLogic Administration Console.
Click OK.
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:
The configuration data is stored in file system by default during a basic install. To change store from database to file system:
Navigate to Administration, then Data Stores.
In the Configuration Data Store section, click Edit.
Select File System from the Repository Type dropdown list.
To configure Oracle Identity Federation to use an RDBMS configuration data store, the high-level steps are:
Create a JDBC data source.
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 formPREFIX _OIF ; you will need to provide this information when configuring Oracle Identity Federation. |
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. |
Log in to the WebLogic Administration Console.
Navigate to Services, then JDBC, then Data Sources.
Click New.
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
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Data Stores.
In the Configuration Data Store section, click Edit.
Select Database from the Repository Type dropdown list.
Enter the JNDI Name; use the JNDI of the Data Source created in the WebLogic Administration Console.
Click OK.
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.
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.
Install RCU from the install CD or installer binaries.
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 formPREFIX _OIF ; you will need to provide this information when configuring Oracle Identity Federation. |
Select Create to create components in the database
Enter database connection details in the next screen.
Select Oracle Identity Federation from Identity Management from the Select Component screen.
Enter the password in the Schema Passwords screen.
Proceed to finish the schema creation for Oracle Identity Federation.
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:
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:
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.
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.
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.
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.
When creating a user session, Oracle Identity Federation records the local authentication mechanism used to authenticate the user.
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:
Mapping from Protocol-specific Methods to Local Mechanisms To Authentication Engines
Mapping Local Authentication Mechanisms to Identity Providers
If a service provider does not specify an authentication method in its request, the Oracle Identity Federation IdP uses the default authentication mechanism in the cases described earlier.
Follow these steps to set the default authentication mechanism:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Authentication Mechanisms.
Select the default authentication mechanism and click Apply.
As mentioned earlier, Oracle Identity Federation provides the ability to map:
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:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Authentication Mechanisms.
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
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
Follow these steps to configure mappings from local authentication mechanisms to identity providers:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Service Provider.
In Protocol Settings, click Configure SSO Authentication Mechanism to Identity Provider Mapping.
Click Add, and select the authentication mechanism and the identity provider to which it will be mapped.
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.
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.
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.
Use this page to:
view, add or delete SAML 2.0 authentication mechanisms
map SAML 2.0 authentication mechanisms to local authentication mechanisms
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.
Use this page to:
view, add or delete SAML 1.x authentication mechanisms
map SAML 1.x authentication mechanisms to local authentication mechanisms
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.
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
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.
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.
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:
|
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.
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.
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:
|
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:
Section 5.13.1.4, "Configuring a Redundancy User Data Store" which explains how to configure a load balancer in front of LDAP servers.
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.
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.
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.
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:
Login ID: The unique username with which the user will log in.
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.
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 | |
---|---|---|---|---|
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:
Create a JDBC data source.
Modify Oracle Identity Federation authentication engine configuration.
Create a JDBC Data Source
Follow these steps to configure an RDBMS user data store:
Log in to the WebLogic Administration Console.
Navigate to Services, then JDBC, then Data Sources.
Click New.
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.
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Authentication Engines.
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.
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
The tab contains these fields:
Default Authentication Engine - This is the engine used for authentications. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.
Enable Authentication Engine - Check this box to enable the engine, and uncheck the box to disable the engine. If enabled, this engine appears on the list of available engines (in the list-box associated with Default Authentication Engine).
Map Assertion to User - If checked, the incoming assertion is mapped to a user record based on the configuration on the SAML 2.0 / SAML 1.x Assertion tab of the Service Provider page.
Display one Entry per Infocard Provider - If checked, Oracle Identity Federation displays an infocard selection option for each Infocard provider configured in the Federations page.
Include Authentication Mechanism - If checked, Oracle Identity Federation adds the authentication mechanism as a required claim, enabling it to request a specific authentication method from the Infocard providers.
Authentication Mechanism Mapped to Personal Card Issuer - When the Infocard authentication engine is invoked for authentication with the authentication mechanism configured here, the personal issuer card is displayed on the login page. If invoked with an authentication mechanism different from the one configured here, all the Infocard providers are displayed.
Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.
The tab contains these fields:
Default Authentication Engine - This is the engine used for authentications. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.
Enable Authentication Engine - Check this box to enable the engine, and uncheck the box to disable the engine. If enabled, this engine appears on the list of available engines (in the list-box associated with Default Authentication Engine).
Authentication Mechanism - This is the authentication mechanism that Oracle Identity Federation will use to authenticate the user locally when using the Federated SSO proxy.
WARNING: The authentication mechanism specified here must not map to the Federated SSO Proxy authentication engine. |
Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.
Additional topics include:
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:
A service provider, SP-1, sends an authentication request to an Oracle Identity Federation identity provider, IdP-1
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.
IdP-2 authenticates the user
IdP-2 sends back an assertion to Oracle Identity Federation/IdP-1, who will then process this assertion
If necessary, Oracle Identity Federation/IdP-1 authenticates the user locally (for example when a federation creation operation needs to be performed)
Oracle Identity Federation/IdP-1 sends back a new assertion to SP-1
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:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Service Provider.
In Protocol Settings, click on Configure SSO Authentication Mechanism to Identity Provider Mapping.
Click Add, and select the authentication mechanism and the identity provider to map it to.
When you are done adding mappings, click OK. Then click Apply.
You can configure the default identity provider by following these steps:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Service Provider.
Select the Default SSO Identity Provider and click Apply.
To correctly use the Federated SSO Proxy Authentication Engine, you need to configure authentication mechanisms. This might include:
Setting the default authentication mechanism
Mapping protocol-specific methods to local mechanisms and local mechanisms to authentication engines
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:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Authentication Engines.
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.
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 URLhttp://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 |
Log in to Oracle WebLogic Server's Administration Server console.
On the left-hand pane, select Security Realms and navigate to myrealm, then Users and Groups, then Groups.
Click New and enter name oifusers
.
Navigate to Users and Groups, then Users.
Click New and select a name and password.
Click the user you just created and select the Groups tab.
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.
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.
Add an Engine
Click Add to add a new custom engine. You are asked to provide a unique engine name; an Engine ID is automatically generated. Once the engine is added, you can add this information:
Enabled - Check the box to enable the engine, or uncheck to disable it.
Web Context - Specifies the Web application context in which your custom authentication engine is deployed.
Authentication Relative Path - Specifies the path to your custom authentication engine, relative to the Web Context.
Logout Relative Path -Specifies the path to the logout service (if any) for your custom authentication engine, relative to the Web Context. For example, "/auth_engines/myAuthLogout.jsp
".
The tab contains these fields:
Default Authentication Engine - This is the engine used for authentications. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.
Enable Authentication Engine - Check this box to enable the engine, or uncheck the box to disable the engine. If enabled, this engine appears on the list of available engines (in the list-box associated with Default Authentication Engine).
Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.
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.
Use this tab to configure SP integration for Oracle Single Sign-On.
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.
Use this tab to configure SP integration for Oracle Access Manager.
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 |
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.
Use this tab to configure SP integration for the test SP engine.
The tab contains these fields:
Default SP Integration module - This is the module used for integration at the service provider. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.
Enable SP module - Check this box to enable the module, and uncheck the box to disable the module. If enabled, this module appears on the list of available modules (in the list-box associated with Default SP Integration module).
Authentication mechanism - 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.
Use this tab to configure SP integration for the custom SP engine.
The tab contains these fields:
Default SP Integration module - This is the module used for integration at the service provider. The list-box contains all the currently enabled engines; selecting an engine from the list makes it the default engine.
Enable SP module - Check this box to enable the module, and uncheck the box to disable the module. If enabled, this module appears on the list of available modules (in the list-box associated with Default SP Integration module).
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
Click the Add button to add a new custom engine. You are asked to provide a unique engine name; an Engine ID is automatically generated. Once the engine is added, you can add this information:
Enabled - Check the box to enable the engine, or uncheck to disable it.
Authentication mechanism – authentication mechanism to use if a local authentication procedure needs to occur during the assertion processing
Web Context - Specifies the contextPath
of the SP Integration Engine in the Web Context field. For example: /engine
.
Authentication Relative Path - Specifies the relative path of the login service of the SP integration engine in the Login Relative Path field. For example: /application.jsp
.
Logout Relative Path -Specifies the relative path of the logout service of the SP integration engine in the Logout Relative Path field.
Updates you make on this tab are saved if you move to tabs for other authentication engines. When you are done, click Apply to save the changes, or Revert to reset the data to its previous state.