30 Introducing Identity Federation in Oracle Access Management

A federation is defined as "an association formed by merging several groups or parties". A federated environment (as defined in the identity management realm) is one in which organizations that provide services and identity data (business partners) have established trust in order to share access to a set of protected resources while protecting the same from unauthorized access. Oracle Identity Federation enables business partners to achieve this by providing the mechanism with which companies can form a federation and securely share services and data across their respective security domains.

With the 11g Release 2 (11.1.2.2) of Oracle Access Management, the standalone Oracle Identity Federation product has begun it's integration with Oracle Access Manager. This chapter introduces the integrated Identity Federation and includes the following sections.

Understanding Identity Federation Concepts
Integrating Identity Federation with Access Manager
Deploying Identity Federation with Oracle Access Management
Exchanging Identity Federation Data
Understanding How Identity Federation Works
Using Identity Federation
Administrating Identity Federation
Enabling Identity Federation

30.1 Understanding Identity Federation Concepts

The Identity Federation topics in this book presume familiarity with federation in general and how it works. See "Introduction to Oracle Identity Federation" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation for background and conceptual information.

30.2 Integrating Identity Federation with Access Manager

The Oracle Identity Management framework supports either of the following approaches to cross-domain single sign-on. You cannot mix-and-match these approaches as each stands on its own.

Beginning with the 11g Release 2 (11.1.2), the Oracle Access Management Access Manager server (OAM Server) has been integrated with an Oracle Access Management Identity Federation server. All configuration for the Identity Federation server is performed using the Oracle Access Management Console.
Previous, separate releases of Oracle Identity Federation (11.1.1) and Oracle Access Manager can still be deployed to provide federation capabilities. Both servers must be configured and managed for this integration. This approach existed in 11g Release 1 (11.1.1) and is still available.

This current document is limited to describing Oracle Identity Federation functionality as it has been integrated with Access Manager in 11g Release 2 (11.1.2.2). For details about the previous separate release of Oracle Identity Federation, see Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.

Benefits of using the new Identity Federation 11g Release 2 (11.1.2.2) server integrated with Access Manager include:

Eliminating the need to install and maintain separate servers.
Simplifying post-install configuration of the federation features, particularly when accessing those features through the Oracle Access Management Console.
Improving the scalability of the two services working together.
Providing enhanced diagnostics and troubleshooting.

30.3 Deploying Identity Federation with Oracle Access Management

From a functional perspective, the components in an 11g Release 2 (11.1.2.2) scenario using the Identity Federation service (when a user attempts to log in to a protected resource using a Web browser) include:

The Access Manager server contains all the components needed to provide access management services in the federated context, including:
- a credential collector
- a federation authentication plugin
- the Identity Federation engine to generate and process assertions
- a federation data cache
Oracle WebLogic Server hosts and provides key infrastructure services, including:
- the authorization engine, which interacts with Oracle Entitlement Server
- federation data including circle of trust details and other configuration
- the Coherence map store
Data stores, including the identity store and Coherence database, maintain the identity data needed for authentication tasks. Identity Federation supports the Access Manager common user store and provides multiple identity store support. Federation data for persistent account linking can be stored in a database.

Note:

Calls are routine HTTP calls.

30.4 Exchanging Identity Federation Data

The integrated Identity Federation server supports the transport and receipt of request and response messages using either the Security Access Markup Language (SAML) 2.0 specifications, SAML 1.1 or OpenID 2.0. The following sections contain more information.

Using SAML 2.0
Using SAML 1.1
Using OpenID 2.0
Initiating Federation SSO

Note:

The specification describing how SAML might be used in a given context is referred to as a SAML profile. The specification describing how a SAML assertion and/or message is conveyed in, or transported over, another protocol is referred to as a SAML Binding.

30.4.1 Using SAML 2.0

SAML uses an eXtensible Markup Language (XML) framework to define a simple request-response protocol in order to achieve interoperability between vendor platforms that provide SAML assertions. A SAML requester sends a SAML Request element to a responder. Similarly, a SAML responder returns a SAML Response element to the requester.

Within the SAML 2.0 protocol, Identity Federation supports the functionality described in the following sections.

SAML 2.0 Bindings for SSO and Federation
SAML 2.0 Bindings for Single Logout
SAML 2.0 NameID Formats
Securing SAML 2.0 Data
SAML 2.0 Service Details

30.4.1.1 SAML 2.0 Bindings for SSO and Federation

SSO and Federation relies on SAML artifacts and assertions to relay authentication information. The following bindings are supported for the exchange of data regarding SSO and federation.

The HTTP Artifact Binding uses the Artifact Resolution Protocol and the SAML SOAP Binding (over HTTP) to resolve a SAML message by reference. The IdP will store the Assertion in its repository and redirect the user to the SP with a string (artifact) that references the stored Assertion. The SP will retrieve the Assertion by connecting to the IdP directly over SOAP/HTTP and presenting the artifact
The HTTP POST Binding relies on an HTML form to communicate authentication information between providers. For example, the service provider may use HTTP Redirect to send a request while the identity provider uses HTTP POST to transmit the response. The IdP can also redirect the user to the SP in an HTML FORM that contains the Assertion itself.
The Reverse SOAP binding (PAOS) is only supported when Access Manager is configured as an IdP. In this flow, the client sends a SOAP request containing a SAML 2.0 Authn Request message to the IdP. The IdP authenticates the user locally, and returns a SOAP response containing a SAML 2.0 Assertion. The client then presents the results to the remote SP.

30.4.1.2 SAML 2.0 Bindings for Single Logout

Single Logout defines how providers notify each other of logout events. This message exchange terminates all sessions when a logout occurs at the SP or IdP. The following profiles are supported for exchanging data regarding single logout.

The HTTP Redirect profile relies on HTTP redirects between providers. For example, the IdP redirects the user to the SP using a 302 redirect operation with the URL containing the Logout Request/Response message. This profile can be used for sending and receiving data regarding single logout.
The HTTP POST profile occurs when the IdP redirects the user to the SP using an HTML FORM containing the Logout Request/Response message. This profile can be used for sending and receiving data regarding single logout.
The SOAP Binding Profile allows the IdP to connect directly with the SP and send a Logout Request message. During logout, the IdP redirects the user to the various SPs in a sequential manner. The SP will respond with a Logout Response message. This profile relies on asynchronous SOAP over HTTP messaging calls between providers and can be used only for sending data regarding single logout.

30.4.1.3 SAML 2.0 NameID Formats

The Name Identifier Mapping defines how an SP can obtain name identifiers assigned to a principal that has authenticated in the name space of a different SP. When a principal authenticated to one SP requests access to a second site, the second SP can use this protocol to obtain the name identifier and communicate with the first SP about the principal - even though no federation for the principal exists between them. The SAML 2.0 NameID formats listed in Table 30-1 are supported in both IdP and SP mode.

Table 30-1 Supported SAML 2.0 NameID Formats

NameID Format	Description
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified	SP/IdP will use the applicable user attribute to populate/process the NameID value
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress	SP/IdP will use the applicable user attribute to populate/process the NameID value
urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName	SP/IdP will use the applicable user attribute to populate/process the NameID value
urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName	SP/IdP will use the applicable user attribute to populate/process the NameID value
urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos	SP/IdP will use the applicable user attribute to populate/process the NameID value
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent	SP/IdP will use either: A user attribute to populate the NameID value A user attribute (such as DN) to set the value (same for every operations) A random value and will store that value in the Federation Data Store (only this mode will require the use of a Federation Data Store)
urn:oasis:names:tc:SAML:2.0:nameid-format:transient	IdP will generate a random value
custom value	When this NameID format is used, OIF/IdP will use a user attribute to populate the NameID value

30.4.1.4 Securing SAML 2.0 Data

Regarding the security of identity data transported using the SAML 2.0 specifications,the following is true.

All outgoing Assertions will be signed.
All outgoing responses containing Assertions will not be signed.
All outgoing requests/responses not containing Assertions will be signed.
The signing certificate will not be included in the messages.
Identity Federation (acting as the IdP) will not require signatures on any messages except when specified in the SP Partner metadata.
NameIDs, attributes and Assertions will not be encrypted.
Information on the default XML Encryption algorithm is located at http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#aes128-cbc
The hashing algorithm for signatures is SHA-1 by default. Identity Federation can be configured to use SHA-256.

30.4.1.5 SAML 2.0 Service Details

The SAML 2.0 Metadata for the IdP and SP is contained in a single XML document and can be retrieved using either the Oracle Access Management Console or by accessing either of the following URLs:

http://public-oam-host:public-oam-port/oamfed/idp/metadata
http://public-oam-host:public-oam-port/oamfed/sp/metadata

The certificates used for signature and encryption operations are published via the SAML 2.0 Metadata. The certificates can be retrieved by using a Service URL that specifies the Key ID of the key/certificate entry as defined in the Keystore Settings. (See Section 32.5, "Defining Keystore Settings for Federation.") For example,

http://public-oam-host:public-oam-port/oamfed/idp/cert?id=osts_signing

The Provider ID and the Issuer ID of the IdP and SP profiles are identical and can be retrieved from the applicable Provider Partner profile using the Oracle Access Management Console.

Table 30-2 documents the SAML 2.0 URLs for use when Identity Federation is configured to act as an IdP.

Table 30-2 SAML 2.0 URLs for Identity Federation Acting As Identity Provider

Description	URL
Single Sign On Service URL for HTTP Redirect binding	http://public-oam-host:public-oam-port/oamfed/idp/samlv20
Single Sign On Service URL for HTTP POST binding	http://public-oam-host:public-oam-port/oamfed/idp/samlv20
Single Sign On Service URL for SOAP binding	http://public-oam-host:public-oam-port/oamfed/idp/soap
Artifact Resolution Service URL for SOAP binding	http://public-oam-host:public-oam-port/oamfed/idp/soap
Single Logout Service URL for HTTP Redirect binding	http://public-oam-host:public-oam-port/oamfed/idp/samlv20
Single Logout Service URL for HTTP POST binding	http://public-oam-host:public-oam-port/oamfed/idp/samlv20
Attribute Authority Service URL for SOAP binding	http://public-oam-host:public-oam-port/oamfed/aa/soap

Table 30-3 documents the SAML 2.0 URLs for use when Identity Federation is configured to act as an SP.

Table 30-3 SAML 2.0 URLs for Identity Federation Acting as Service Provider

Description	URL
Assertion Consumer Service URL for Artifact binding	http://public-oam-host:public-oam-port/oam/server/fed/sp/sso
Assertion Consumer Service URL for HTTP POST binding	http://public-oam-host:public-oam-port/oam/server/fed/sp/sso
Single Logout Service URL for HTTP Redirect binding	http://public-oam-host:public-oam-port/oamfed/sp/samlv20
Single Logout Service URL for HTTP POST binding	http://public-oam-host:public-oam-port/oamfed/sp/samlv20

30.4.2 Using SAML 1.1

Although the standards address the same use case, SAML 2.0 and SAML 1.1 get there in different ways. The most important type of SAML 1.1 request is a query. A SP makes a query directly to an IdP over a secure back channel (using SOAP). Within the SAML 1.1 protocol, Identity Federation supports the features described in the following sections.

SAML 1.1 Profiles for Web Browser SSO
SAML 1.1 Logout Profile
SAML 1.1 NameID Formats
Securing SAML 1.1 Data
SAML 1.1 Service Details

30.4.2.1 SAML 1.1 Profiles for Web Browser SSO

SAML 1.1 profiles rely on pushing SAML artifacts and assertions to an SP to relay authentication information. The following profiles are supported.

The Browser/Artifact Profile passes a SAML assertion from the IdP to the SP by reference (through the browser using HTTP Redirect). This artifact is subsequently dereferenced through a back-channel exchange in which the SP retrieves the assertion from the IdP using SAML over SOAP over HTTP.
The Browser/POST Profile passes an SSO assertion to an SP through the browser using HTTP POST. We say that the identity provider "pushes" the assertion to the service provider.

30.4.2.2 SAML 1.1 Logout Profile

The SAML 1.1 specifications do not define a logout profile thus Identity Federation is not able to notify remote partners regarding a user logging out.

30.4.2.3 SAML 1.1 NameID Formats

When a principal authenticated to one SP requests access to a second site, the second SP can obtain the name identifier and communicate with the first SP regarding the principal - even though no federation for the principal exists between them. The SAML 1.1 NameID formats listed in Table 30-4 are supported in both IdP and SP mode.

Table 30-4 Supported SAML 1.1 NameID Formats

NameID Format	Description
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified	SP/IdP will use the applicable user attribute to populate/process the NameID value
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress	SP/IdP will use the applicable user attribute to populate/process the NameID value
urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName	SP/IdP will use the applicable user attribute to populate/process the NameID value
urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName	SP/IdP will use the applicable user attribute to populate/process the NameID value
urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos	SP/IdP will use the applicable user attribute to populate/process the NameID value
custom value	When this NameID format is used, OIF/IdP will use a user attribute to populate the NameID value

30.4.2.4 Securing SAML 1.1 Data

Regarding the security of identity data transported using the SAML 1.1 specifications,the following is true.

All outgoing Assertions will be signed.
All outgoing responses containing Assertions will not be signed.
The signing certificate will not be included in the messages.
Identity Federation (acting as the IdP) will not require signatures on any messages.
The hashing algorithm for signatures is SHA-1 by default. Identity Federation can be configured to use SHA-256.

30.4.2.5 SAML 1.1 Service Details

The certificates used for signature and encryption operations can be retrieved by using a Service URL that specifies the Key ID of the key/certificate entry as defined in the Keystore Settings. (See Section 32.5, "Defining Keystore Settings for Federation.") For example,

http://public-oam-host:public-oam-port/oamfed/idp/cert?id=osts_signing

The Provider ID and the Issuer ID of the IdP and SP profiles are identical and can be retrieved from the applicable Provider Partner profile using the Oracle Access Management Console.

Table 30-5 documents the SAML 1.1 URLs for use when Identity Federation is configured to act as an IdP.

Table 30-5 SAML 1.1 URLs for Identity Federation Acting As Identity Provider

Description	URL
Single Sign On Service URL	http://public-oam-host:public-oam-port/oamfed/idp/samlv11sso
Artifact Resolution Service URL	http://public-oam-host:public-oam-port/oamfed/idp/soapv11

Table 30-6 documents the SAML 1.1 URL for use when Identity Federation is configured to act as an SP.

Table 30-6 SAML 1.1 URL for Identity Federation Acting as Service Provider

Description	URL
Assertion Consumer Service URL	http://public-oam-host:public-oam-port/oam/server/fed/sp/sso

30.4.3 Using OpenID 2.0

OpenID 2.0 allows users to create accounts with a preferred OpenID IdP and use the account as the basis for signing on to any website that accepts OpenID authentication. Identity data is communicated through the exchange of an OpenID identifier (a URL or XRI chosen by the end-user) and the IdP provides OpenID authentication. Within the OpenID protocol, Identity Federation supports the functionality described in the following sections.

OpenID 2.0 Authentication/SSO
OpenID 2.0 Logout
OpenID 2.0 NameID Format
Securing OpenID 2.0 Data
Using OpenID 2.0 Extensions
OpenID 2.0 Service Details

30.4.3.1 OpenID 2.0 Authentication/SSO

OpenID 2.0 allows a user to sign into a new web site using a special OpenID URL. For example, if you have a blog at myblog.com, you might have created the OpenID URL, yourname.myblog.com. Then if you navigate to a second web site that accepts OpenID logins and click on the OpenID button, you can type in the URL and click to log in. The second SP discovers the OpenID IdP URL with this OpenID identifier. When the OpenID IdP redirects the authenticated user to the SP, it includes the OpenID Assertion which contains the result of the operation, the NameID of the user and (optional) attributes.

30.4.3.2 OpenID 2.0 Logout

The OpenID 2.0 specifications do not define a logout profile thus Identity Federation is not able to notify remote partners regarding a user logging out.

30.4.3.3 OpenID 2.0 NameID Format

OpenID defines the NameID as being a random string thus Identity Federation will use one of the following as the value for the NameID.

A hashed user attribute (such as DN)
A generated, random value that will be stored in the Federation Data Store; this mode requires the use of a Federation Data Store

30.4.3.4 Securing OpenID 2.0 Data

Regarding the security of identity data transported using the OpenID 2.0 specifications,the following is true.

All outgoing Assertions will be signed.
The default Association Algorithm is HMAC SHA-1.
The default Session Agreement Algorithm is Diffie-Hellmann SHA-1.

30.4.3.5 Using OpenID 2.0 Extensions

OpenID is an extensible specification. The following extensions are available when using the integrated Identity Federation.

Attribute Exchange (AX): If enabled, a SP can request attributes to be included in the OpenID Assertion response. The IdP can include the requested attributes or attributes configured to be in the response. (Default: enabled)
Provider Authentication Policy Extension (PAPE): If enabled, advanced authentication methods can be defined and specified. This might include, for example, a phishing-resistant authentication method or multi-factor authentication. (Default: disabled)
GSA Level 1: identifier in the OpenID Assertion indicating if this server is compliant with the http://www.idmanagement.gov/schema/2009/05/icam/openid-trust-level1.pdf policy. If enabled and if PAPE is enabled, OIF will include this policy in the OpenID response (Default: disabled)
Level Of Assurance (LOA): identifier in the OpenID Assertion indicating if this server is compliant with the http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf policy. If enabled, OIF/IdP will use the mapping between Level of Assurance and schemeID to determine the value to use for LOA in the OpenID response (see 2.5.2 for more information) (Default: disabled)
No Private Identifier Information (NoPII): identifier in the OpenID Assertion indicating if this server is compliant with the http://www.idmanagement.gov/schema/2009/05/icam/no-pii.pdf policy. Note, if enabled, OIF will not include attributes in the OpenID Assertion
Persistent Personal Identifier (PPID): identifier in the OpenID Assertion indicating if this server is compliant with the http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier policy. If enabled and if PAPE is enabled, OIF will include this policy in the OpenID response (Default: disabled)
Registration (SReg): extension for attributes in the OpenID Assertion. If enabled, the SP can request attributes to be included in the response, and the IdP can include requested attributes or attributes configured to be in the response (Default: disabled)
UI Extension (UIExt): extension for UI. In OIF/IdP, support for this extension is limited to advertisement in the XRDS metadata (Default: disabled)

30.4.3.6 OpenID 2.0 Service Details

The following URL is the realm of the OpenID 2.0 SP component.

http://public-oam-host:public-oam-port

Table 30-7 documents the OpenID 2.0 URLs for use when Identity Federation is configured to act as an IdP.

Table 30-7 OpenID 2.0 URLs for Identity Federation Acting As Identity Provider

Description	URL
Single Sign On Service URL	http://public-oam-host:public-oam-port/oamfed/idp/openidv20
Discovery Service URL	http://public-oam-host:public-oam-port/oamfed/idp/openidv20

Table 30-8 documents the OpenID 2.0 URLs for use when Identity Federation is configured to act as an SP.

Table 30-8 OpenID 2.0 URLs for Identity Federation Acting as Service Provider

Description	URL
Single Sign On Service URL	http://public-oam-host:public-oam-port/oam/server/fed/sp/sso
Discovery Service URL	http://public-oam-host:public-oam-port/oamfed/sp/openidv20
Realm URL	http://public-oam-host:public-oam-port

30.4.4 Initiating Federation SSO

The following sections contain details about initiating the Federation SSO process.

IdP Initiated Federation SSO Service
SP Initiated Federation SSO Service

30.4.4.1 IdP Initiated Federation SSO Service

When Identity Federation is working as an IdP, the URL for initiating Federation SSO is:

http://public-oam-host:public-oam-port/oamfed/idp/initiatesso

The query parameters are:

providerid: name of the SP partner with which to perform Federation SSO or the issuer ID / provider ID of the SP partner with which to perform Federation SSO. (required)
returnurl: the SP URL where the user will be redirected after a successful Federation SSO (optional)
acsurl: the SAML 2.0 Assertion Consumer Service URL where Identity Federation will redirect the user with the SAML 2.0 Assertion. This URL must be declared in the SP SAML 2.0 Metadata. (optional)

30.4.4.2 SP Initiated Federation SSO Service

When Identity Federation is working as an SP, the URL for initiating Federation SSO is:

http://public-oam-host:public-oam-port/oamfed/sp/initiatesso

The query parameters are:

providerid: name of the IdP partner with which to perform Federation SSO or the issuer ID / provider ID of the IdP partner with which to perform Federation SSO. (required)
returnurl: the URL where the user will be redirected after a successful Federation SSO (optional)

30.5 Understanding How Identity Federation Works

A federation can comprise any number of identity providers and service providers. One common federated network topology is referred to as the hub-and-spoke model. In this topology, there is either a single service provider accepting authentication from multiple identity providers, or a single identity provider authenticating users for multiple service providers. An instance of Identity Federation in a federated network can serve as either an identity provider, a service provider, or both.

A service provider (SP) is a commercial or not-for-profit organization that offers a web-based service such as a news portal, a financial repository, or retail outlet. When configured as the SP in a federated network and a user wants to access a resource protected by an authentication engine such as Oracle Access Manager, Identity Federation redirects the user to an IdP for global authentication. The IdP will obtain credentials, authenticate the user, and redirect the user back to the Identity Federation server instance - which retrieves the asserted identity from the IdP and redirects the authenticated user to the authentication engine which provides access to the protected resource.
An identity provider (IdP) is a service provider that stores identity profiles. (Identity providers might also offer services above and beyond those related to identity profile storage.) When configured as the IdP in a federated network and a user wants to access a protected resource, the resource's SP directs the user to the Identity Federation server instance - which uses the Access Manager authentication engine to obtain credentials and authenticate the user. Following successful authentication, the Identity Federation instance can assert the user's identity to the resource's SP - which then authenticates the user itself and provides access to the requested resource.

The integrated Identity Federation server can operate as an IdP or an SP. See Chapter 31, "Managing Identity Federation Partners" for information on configuring Identity Federation to operate in one of these provider modes and communicate with remote partners in the federation.

Note:

If the Administrator terminates a user session using the Oracle Access Management Console, the logout is not propagated to any remote identity providers involved in the session. This could result in a logged-out user being automatically re-authenticated to Access Manager through Identity Federation.

The OIF WLST Authentication commands configure authentication based on specific Service Providers. See the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference for details.

30.6 Using Identity Federation

In SP-initiated SSO, the federated SSO process begins when the SP sends an authentication request to the IdP. In IdP-initiated SSO, the IdP sends the SP an unsolicited assertion response (in the absence of an authentication request from the SP). Supported runtime flows in both modes include SSO, Logout (initiated from a remote federation partner or Access Manager protected application) and Attribute Query. The following sections have more information.

Achieving SSO
Logging Out
Authorizing
Forcing Authentication
Indicating a Passive Identity Provider
User and Assertion Mapping
Platform Dependencies

Note:
The OIF WLST Authentication commands configure authentication based on specific Service Providers. See the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference for details.

30.6.1 Achieving SSO

When the Identity Federation (acting as an IdP) is performing federated SSO with an SP, the Access Manager server authenticates the user or ensures an authenticated user doesn't need to be challenged due to inactivity. Additionally, the Access Manager server will check that any requested federation authentication method specified by the SP does not require a challenge based on authentication level. The Authentication Scheme mappings to the authentication methods will determine this. (If the SP does not specify a Federation Authentication Method, the IdP will use the one specified for the SP partner in the defaultschemeid property.)

30.6.2 Logging Out

With Identity Federation, a logout operation is dissociated from the authentication operation. Logout can be initiated by user the (Access Manager server) or a partner in the federation.

When initiated by the user accessing the Access Manager Logout service, Access Manager kills the user's Access Manager session and displays a logout page that will instruct the various WebGate agents to remove the user cookies. Access Manager then redirects the user to the Identity Federation Logout service which notifies each partner involved in this session by either redirecting the user with a Logout Request message via HTTP Redirect or HTTP POST or by directly sending a Logout Request message via SOAP. Identity Federation then kills the OIF session and redirects the user to the defined return URL.
When initiated by the user on a web site from a partner in the federation, the partner redirects the user to the Identity Federation server which marks the user session as logging out. Identity Federation then redirects the user to the Access Manager server which kills the user's Access Manager session. Access Manager then displays a logout page that will instruct the various WebGate agents to remove the user cookies, and redirects the user back to Identity Federation to resume the Federation logout process by notifying each partner involved in this session (except the one who first redirected the user) by either redirecting the user with a Logout Request message via HTTP Redirect or HTTP POST or by directly sending a Logout Request message via SOAP. Identity Federation then kills the OIF session and redirects the user with a Logout Response message to the partner who first redirected the user to the Identity Federation server.

30.6.3 Authorizing

When the Identity Federation server acts as an IdP, it has the need to issue an Identity Token to the SP during the Federation SSO operation. The Identity Token will contain user information as well as session information. By default, the authorization feature is turned off. It can be enabled or disabled using the configureFedSSOAuthz WLST command. You also need to create a resource of type TokenServiceRP (with the Resource URL set to the SP Partner ID) and a Token Issuance Policy to which the Resource is added. The Token Issuance Policy indicates the conditions under which the token should be issued.

30.6.4 Forcing Authentication

SAML 2.0 and OpenID 2.0 provide a way for a SP to indicate during Federation SSO whether the user should be challenged by the IdP, even if a valid user session already exists. In this case, the SP will send an authentication request with a parameter indicating that the IdP should re-challenge the user or force authentication.

30.6.5 Indicating a Passive Identity Provider

SAML 2.0 and OpenID 2.0 provide a way for the SP to indicate during Federation SSO whether the Identity Provider should interact with the user. In this case, the SP will send an authentication request with a parameter indicating that the IdP should not interact with the user or is passive. The IdP recognizes the parameter and returns to the SP:

An error if the IdP must interact with the user but cannot because of this parameter.
A Federation Assertion that indicates whether the user has a valid session.

30.6.6 User and Assertion Mapping

In Identity Federation, after a SP validates the SAML assertion created by it's IdP partner, it can map the assertion to the local user in one of the following ways.

By mapping the SAML subject to a user record with a user attribute (for example, mail).
By mapping a SAML Assertion Attribute to a user record with a user attribute (for example, the SAML Assertion Attribute emailAddress mapped to mail).
By mapping one or more attributes contained in the SAML assertion's AttributeStatement element or the SAML subject with an LDAP query. You must configure both the SAML attribute name and the user attribute to which it is mapped.

30.6.7 Platform Dependencies

This architecture leverages the Oracle Fusion Middleware platform for the Credential Store Framework (CSF). CSF securely stores keystore passwords as well as server credentials such as HTTP Basic Authentication usernames and passwords.

30.7 Administrating Identity Federation

Identity Federation integrated with Access Manager can be administered with a combination of configurations using the Oracle Access Management Console and Oracle WebLogic Scripting Tool (WLST) commands. Use the Oracle Access Management Console to enable the Identity Federation service, manage IdP and SP partner profiles, and work with federated authentication schemes and policies. Use the WLST utilities to manage additional server and partner configuration properties.

Note:

Not all WLST command functionality is duplicated in the Oracle Access Management Console and not all console functionality is duplicated on the command line.

The Oracle Access Management Console enables Administrators to manage configuration related to the federation service and partners. Table 30-9 summarizes the types of information that you can configure for Identity Federation using Oracle Access Management Console.

Table 30-9 Configuring Identity Federation Settings

Configuring ...	Description
Federation Administrators	Administrators who can manage federated partners and related configuration. See "Understanding the Controls".
Federation Service	Enable and disable the Identity Federation service in Access Manager. See "Enabling Identity Federation".
Federation Settings	Manage basic Identity Federation service configuration properties. See Chapter 32, "Managing Settings for Identity Federation".
Providers for Federation	IdP partners are managed within the context of administering Identity Federation as a SP. Conversely, SP partners are managed within the context of administering Identity Federation as an IdP. See Section 31.3, "Administering Identity Federation As A Service Provider" or Section 31.4, "Administering Identity Federation As An Identity Provider.".
Authentication Schemes and Modules for Federation	Manage federation authentication schemes. See "Using Authentication Schemes and Modules for Identity Federation 11g Release 2 (11.1.2.2)".
Policies for Use with Federation	Manage policies for use with federation partners. See "Managing Access Manager Policies for Use with Identity Federation".

Table 30-10 outlines the tasks required to implement identity federation using the Oracle Access Management Console.

Table 30-10 Implementing Identity Federation

Task	Reference
Enable the Identity Federation service.	Section 30.8
Configure federation settings.	Section 32.3
Identity IdP and/or SP partners, and configure attributes for them.	Section 31.3
Configure an authentication or authorization policy.	Chapter 33
Protect a resource with this policy.	Chapter 20

30.8 Enabling Identity Federation

Identity Federation is an authentication module in Oracle Access Management so both the Access Manager service and Identity Federation must be enabled. Figure 30-1 illustrates the Available Services page in Oracle Access Management Console with the Access Manager service and Identity Federation aleady enabled. Use this page to enable (or disable) Identity Federation together with the Access Manager service.

Note:

Once enabled, it is possible to enable or disable specific Federation features such as IdP, SP, Attribute Authority and/or Attribute Requester. Use the configureFederationService() WLST command as documented in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

Figure 30-1 Available Services Page

Surrounding text describes Figure 30-1 .

To enable the Identity Federation service with Access Manager

Log in to the Oracle Access Management Console.
```
     https://hostname:port/oamconsole/
```
From the Welcome page, under Configuration, click Available Services.
Enable Identity Federation: Click Enable beside Identity Federation (or confirm that the green Status check mark displays).
Enable Access Manager: Click Enable beside Access Manager (or confirm that the green Status check mark displays).