Introducing Identity Federation in Oracle Access Management

28 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.3) 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 topics

28.1 Integrating Identity Federation with Access Manager

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

Based on your setup, perform one of the following:.

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.

Note:

The topics in this book presume familiarity with federation 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. This current document is limited to describing Oracle Identity Federation functionality as it has been integrated with Access Manager in 12c.

Benefits of using the new Identity Federation 12c 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.

28.2 Deploying Identity Federation with Oracle Access Management

From a functional perspective, the components 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, Oracle WebLogic server hosts, and data stores.

Access Manager Server

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

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

Data Stores

Data stores, including the identity store, 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.

28.3 Understanding How Identity Federation Works

A federation can comprise any number of identity providers and service providers. An instance of Identity Federation in a federated network can serve as either an identity provider, a service provider, or both.

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.

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

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

This section describes the following topics:

28.4.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.) See Initiating Federation SSO for details.

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

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

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

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

28.4.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, Identity Federation maps SAML assertion to the local user:

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.

28.4.7 Platform Dependencies

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

28.5 Initiating Federation SSO

Federation SSO process can be initiated when Identity Federation is working as an IdP or SP.

This section describes the following topics:

28.5.1 IdP Initiated Federation SSO Service

The IdP Initiated Federation SSO Service has three query parameters: providerid, returnurl, and acsurl.

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)

Multivalue Attributes in SAML Assertion

28.5.1.1 Multivalue Attributes in SAML Assertion

The default behavior of the feature is, during SSO, IDP sends the Group attributes in comma separated format if the user belongs to multiple groups and always send is set to true. As an enhanced behavior, During SSO, IdP sends the Group attributes in separate SAML statements instead of comma separated if the multivaluegroups flag is set to true.

The following SSO protocols support Multi-Valued Groups SAML Attributes

SAML 2.0
SAML 1.1

To enable this feature, OAM configuration should be updated depending on the requirement. Themultivaluegroups attribute setting is disabled by default and is not present in oam-config.xml. The User has to add this setting in oam-config.xml using WLST commands and set it to true to enable multiple attribute statements for Group attribute.
Add multivaluegroups attribute setting to oam-config.xml at the Partner level or Partner Profile level or Global level using WLST commands and set it to true.

<Setting Name="multivaluegroups" Type="xsd:boolean">true</Setting>
- Enable or disable the multivaluegroups at partner level
  
  updatePartnerProperty(partnerName="spPartnername", partnerType="SP",propName="multivaluegroups",propValue="true/false",type="boolean");
- Enable or disable the multivaluegroups at partner profile level
  
  putBooleanProperty("/fedpartnerprofiles/saml20-sp-partner-profile/multivaluegroups","true/false");
- Enable or disable the multivaluegroups at global level
  
  putBooleanProperty("/idpglobal/multivaluegroups","true/false");

28.5.2 SP Initiated Federation SSO Service

The SP Initiated Federation SSO Service has two query parameters: providerid and returnurl.

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)

28.5.3 Attribute Consuming Service

OAM Federation service is enhanced to support standard SAML2v-based interfaces and elements.

This section describes the following topics:

28.5.3.1 Elements Of Attribute Consuming Service

The attribute consuming service includes three elements: AttributeConsumingService, AttributeConsumingServiceIndex, and NameQualifier.

AttributeConsumingService

The AttributeConsumingService element is included in the SP metadata. This element contains the following fields:

ServiceName
ServiceDescription
index
isDefault
RequestedAttribute contains the following fields:
- acsIndex
- rqstAttrName
  
  Note:
  The rqstAttrName field can be any user defined value such as name, fiscal number, email, and so on.
- rqstAttrNameFormat
- rqstAttrFriendlyName
- rqstAttrIsRequired

Sample SP metadata:

<md:AttributeConsumingService index="1" isDefault="false">
	<md:ServiceName xml:lang="en_US">serviceName1</md:ServiceName> 
	<md:ServiceDescription xml:lang="en_US">serviceDesc1</md:ServiceDescription> 
	<md:RequestedAttribute FriendlyName="friendlyName1" Name="email" NameFormat="sample:urn:format" isRequired="true"/>
</md:AttributeConsumingService>
 
<md:AttributeConsumingService index="1" isDefault="true"> 
	<md:ServiceName xml:lang="eng">Updated-Service-Name1</md:ServiceName>
	<md:ServiceDescription xml:lang="eng">updatedServiceDesc</md:ServiceDescription>
	<md:RequestedAttribute FriendlyName="friendlyName1" Name="email" NameFormat="sample:urn:format" isRequired="true"/>
	<md:RequestedAttribute FriendlyName="" Name="empNum" NameFormat="empFormat1" isRequired="false"/>
	<md:RequestedAttribute FriendlyName="fname" Name="empFirstName" NameFormat="firstnameformat1" isRequired="true"/> 
</md:AttributeConsumingService>

AttributeConsumingService

TheAttributeConsumingServiceIndex element is included in the SAML 2.0 authentication request. In the runtime SSO, pass the attributeconsumingserviceindex parameter in the SP initiated URL, so that AttributeConsumingServiceIndex is displayed in the authnrequest.

For example, http://sp-host:sp-managed-port/oamfed/sp/initiatesso?providerid=http://idp-host:idp-managed-port/oam/fed&returnurl=http://sp-host:webgate-port/cgi-bin/headers.cgi&attributeconsumingserviceindex=1

Sample authentication request:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
	<samlp:AuthnRequest xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AttributeConsumingServiceIndex="1" ID="id-atMY1jR9Vh7PBcWSjdqmyxIc1JNMSFD-zQ1d7lf8" Version="2.0" IssueInstant="2016-09-15T22:32:37Z" Destination="http://slc05ynv.us.oracle.com:21328/oamfed/idp/samlv20">
		<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://slc06fcv.us.oracle.com:23768/oam/fed</saml:Issuer>
		<samlp:NameIDPolicy AllowCreate="true"/>
	</samlp:AuthnRequest>

NameQualifier

The NameQualifier element is included in the <samlp:issuer> tag.

Example:

<saml:Issuer NameQualifier=" http://spid-sp.it" Format=" urn:oasis:names:tc:SAML:2.0:nameid format:entity"> SPID-sp-test </saml:Issuer>

By default, NameQualifier is set to false. You can set NameQualifier to true in the oam-config.xml file using the WLST commands. For more information on WLST commands, see the WLST Command Reference for WebLogic Server.

The following table illustrates how to enable or disable the NameQualifier element using the WLST commands:

Action	WLST Command Examples
Enable `NameQualifier` at the partner level.	updatePartnerProperty(partnerName="idp-partner",partnerType="IDP",propName="samlrequestissuernamequalifier",propValue="http://sample.sp.it",type="string")
Enable `NameQualifier` at the partner profile level.	putStringProperty("/fedpartnerprofiles/saml20-idp-partner-profile/samlrequestissuernamequalifier","http://profile-sample.it")
Enable `NameQualifier` at the global level.	putStringProperty("/spglobal/samlrequestissuernamequalifier","http://spglobal.it")
Disable `NameQualifier` at the partner level.	deletePartnerProperty(partnerName="idp-partner",partnerType="IDP",propName="samlrequestissuernamequalifier")
Disable `NameQualifier` at the partner profile level.	deleteStringProperty("/fedpartnerprofiles/saml20-idp-partner-profile/samlrequestissuernamequalifier")
Disable `NameQualifier` at the global level.	deleteStringProperty("/spglobal/samlrequestissuernamequalifier")

28.5.3.2 WLST Commands For Attribute Consuming Service

Attribute Consuming Service is supported with ten WebLogic Scripting Tool (WLST) commands.

More information in the following sections:

28.5.3.2.1 getDefaultACS

This command retrieves the default attribute consuming service.

Description

The getDefaultACS command retrieves the default attribute consuming service.

Syntax

getDefaultACS()

Example

This example illustrates the use of getDefaultACS command.

getDefaultACS()

28.5.3.2.2 getAllRqstAttrsForACS

This command retrieves the list of requested attributes under specified attribute consuming service, acsIndex.

Description

The getAllRqstAttrsForACS command retrieves the list of requested attributes under the specified attribute consuming service, acsIndex.

Syntax

getAllRqstAttrsForACS(acsIndex)

Arguments	Definition
`acsIndex`	[Mandatory] Index of the attribute consuming service.

Example

This example illustrates the use of the getAllRqstAttrsForACS(acsIndex) command.

getAllRqstAttrsForACS(1)

28.5.3.2.3 getAllACS

This command retrieves the list of all attribute consuming service configured.

Description

The getAllACS command retrieves the list of all attribute consuming service configured.

Syntax

getAllACS()

Example

This example illustrates the use of the getAllACS() command.

getAllACS()

28.5.3.2.4 getACS

This command retrieves the specified attribute consuming service, acsIndex.

Description

The getACS command retrieves the specified attribute consuming service, acsIndex.

Syntax

getACS(acsIndex)

Arguments	Definitions
`acsIndex`	[Mandatory] Index of the attribute consuming service.

Example

This example illustrates the use of the getACS(acsIndex) command.

getACS(1)

28.5.3.2.5 addACS

This command creates a new entry of attribute consuming service with acsIndex, serviceName, attributeConsumingIsDefault, rqstAttrName, rqstAttrNameFormat, rqstAttrFriendlyName, rqstAttrIsRequired, and serviceDescription.

Description

It is mandatory to provide details of at least one requested attribute when you create an attribute consuming service. The <xml:lang> parameter is updated with the server locale automatically.

Note:

you must create addACS with acsIndex to execute GET and DELETE WLST commands.

Syntax

addACS(acsIndex, serviceName, rqstAttrName, rqstAttrNameFormat, rqstAttrFriendlyName="", rqstAttrIsRequired="false", serviceDescription="", attributeConsumingIsDefault="false")

Arguments	Definitions
`acsIndex`	[Mandatory] Specifies the index of the attribute consuming service.
`serviceName`	[Mandatory] Specifies the name of the service.
`rqstAttrName`	[Mandatory] Specifies the name of the requested attribute.
`rqstAttrNameFormat`	[Mandatory] Specifies the format of the requested attribute.
`rqstAttrFriendlyName`	[Optional] Specifies the friendly name of the attribute consuming service.
`rqstAttrIsRequired`	[Optional] Determines if the requested attribute is required. The valid values are `true` and `false`.
`serviceDescription`	[Optional] Provides the description of the service. The default value is “ “.
`attributeConsumingIsDefault`	[Optional] Accepts the value to set the default attribute consuming service. The default value is `false`.

Example

This example illustrates the use of the addACS command.

addACS(1, "Updated-Service-Name1", "email", "sample:urn:format", rqstAttrFriendlyName="", rqstAttrIsRequired="false", serviceDescription="updatedServiceDesc", attributeConsumingIsDefault="true")

28.5.3.2.6 addRqstAttrToACS

This command adds a new requested attribute such as rqstAttrName, rqstAttrNameFormat, rqstAttrFriendlyName, and rqstAttrIsRequired under the list of specified attribute consuming service, acsIndex.

Description

The addRqstAttrToACS command adds a new requested attribute such as rqstAttrName, rqstAttrNameFormat, rqstAttrFriendlyName, and rqstAttrIsRequired under the list of specified attribute consuming service, acsIndex.

Syntax

addRqstAttrToACS(acsIndex, rqstAttrName, rqstAttrNameFormat, rqstAttrFriendlyName=None, rqstAttrIsRequired="false"):

Arguments	Definitions
`acsIndex`	[Mandatory] Specifies the index of the attribute consuming service.
`rqstAttrName`	[Mandatory] Specifies the name of the requested attribute.
`rqstAttrNameFormat`	[Mandatory] Specifies the format of the requested attribute.
`rqstAttrFriendlyName`	[Optional] Specifies the friendly name of the attribute consuming service.
`rqstAttrIsRequired`	[Optional] Determines if the requested attribute is required. The valid values are `true` and `false`.

Example

This example illustrates the use of the addRqstAttrToACS command.

addRqstAttrToACS(1, "empNumber", "empFormat1", rqstAttrFriendlyName=None, rqstAttrIsRequired="false"):

28.5.3.2.7 updateACS

This commands updates any or all fields of the specified attribute consuming service, oldACSIndex.

Description

The updateACS command updates any or all fields (that is, newServiceName, newServiceDescription, newAttributeLang, newIsDefault, and newACSIndex) of the specified attribute consuming service, oldACSIndex.

Syntax

updateACS(oldACSIndex, newServiceName=None, newServiceDescription=None, newAttributeLang=None, newIsDefault=None, newACSIndex=None)

Arguments	Definitions
`oldACSIndex`	[Mandatory] Specifies the name of the existing attribute consuming service index.
`newServiceName`	[Optional] Specifies the updated name for the attribute consuming service.
`newServiceDescription`	[Optional] Specifies the updated description of the attribute consuming service.
`newAttributeLang`	[Optional] Specifies the updated "xml:lang" for the attribute consuming service name and description.
`newIsDefault`	[Optional] Accepts the values such as `true` or `false` to set the new default value to attribute consuming service. The valid values are `true` and `false`.
`newACSIndex`	[Optional] Specifies the name of the new attribute consuming service index.

Example

This example illustrates the use of theupdateACS command.

Note:

At least one optional parameter is required with acsIndex to successfully update the ACS.

To update only the newServiceName field, use the following command:
```
updateACS(1, newServiceName="SampleAttributeName");
```

To update both newServiceName and isdefault, use the following command:

updateACS(1, newServiceName="SampleAttributeName", newIsDefault="true");

28.5.3.2.8 updateRqstAttrForACS

This command updates all the fields of the specified requested attribute, oldRqstAttrName under the specified attribute consuming service, acsIndex.

Description

The updateRqstAttrForACS command updates all the fields of the specified requested attribute, oldRqstAttrName under the specified attribute consuming service, acsIndex.

Syntax

updateRqstAttrForACS(acsIndex, oldRqstAttrName, newRqstAttrName=None, newRqstAttrFriendlyName=None, newRqstAttrNameFormat=None, newRqstAttrIsRequired=None)

Arguments	Definitions
`acsIndex`	[Mandatory] Specifies the index of the attribute consuming service.
`oldRqstAttrName`	[Mandatory] Specifies the name of the existing requested attribute that updates the fields.
`newRqstAttrName`	[Optional] Specifies the updated name of the requested attribute.
`newRqstAttrFriendlyName`	[Optional] Specifies the updated friendly name of the requested attribute.
`newRqstAttrNameFormat`	[Optional] Specifies the updated format of the requested attribute name.
`newRqstAttrIsRequired`	[Optional] Determines if the requested attribute is required from the attribute consuming service. The valid values are `true` and `false`.

Example

This example illustrates the use of the updateRqstAttrForACS command.

Note:

At least one optional parameter is required with acsIndex to successfully update the specified requested attribute.

To update only newRqstAttrName, use the following command:

updateRqstAttrForACS(acsIndex, oldRqstAttrName, newRqstAttrName="SAMPLE_RQST_ATTR");

To update newRqstAttrName and newRqstAttrNameFormat of the requested attribute, use the following command:

updateRqstAttrForACS(acsIndex, oldRqstAttrName, newRqstAttrName="SAMPLE_RQST_ATTR", newRqstAttrNameFormat="urn:oasis:sample");

28.5.3.2.9 deleteACS

This command deletes the specified attribute consuming service, acsIndex.

Description

The deleteACS command deletes the specified attribute consuming service, acsIndex.

Syntax

deleteACS(acsIndex)

Arguments	Definition
`acsIndex`	[Mandatory] Specifies the index of the attribute consuming service.

Example

This example illustrates the use of the deleteACS command.

deleteACS(1)

28.5.3.2.10 deleteRqstAttrForACS

This command deletes the requested attribute, rqstAttrName, from the specified Attribute Consuming Service, acsIndex.

Description

The deleteRqstAttrForACS command deletes the requested attribute, rqstAttrName, from the specified attribute consuming service, acsIndex.

Syntax

deleteRqstAttrForACS(acsIndex, rqstAttrName)

Arguments	Definition
`acsIndex`	[Mandatory] Specifies the index of the attribute consuming service.
`rqstAttrName`	[Mandatory] Specifies the name of the requested attribute.

Example

This example illustrates the use of the deleteRqstAttrForACS command.

deleteRqstAttrForACS(1, rqstAttrName="empFirstName")

28.6 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, OpenID 2.0 or WS-Federation 1.1.

This section describes the following topics:

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.

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

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

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

28.6.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 28-1 are supported in both IdP and SP mode.

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

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

28.6.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 the Oracle Access Management Console.

The Metadata can also be retrieved 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 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 28-2 documents the SAML 2.0 URLs for use when Identity Federation is configured to act as an IdP.

Table 28-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 28-3 documents the SAML 2.0 URLs for use when Identity Federation is configured to act as an SP.

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

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

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

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

28.6.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 28-4 are supported in both IdP and SP mode.

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

28.6.2.4 About SAML 1.1 Data Security

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.

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

For more information, see 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 28-5 documents the SAML 1.1 URLs for use when Identity Federation is configured to act as an IdP.

Table 28-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 28-6 documents the SAML 1.1 URL for use when Identity Federation is configured to act as an SP.

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

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

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

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

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

28.6.3.4 About OpenID 2.0 Data Security

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.

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

28.6.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 28-7 documents the OpenID 2.0 URLs for use when Identity Federation is configured to act as an IdP.

Table 28-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 28-8 documents the OpenID 2.0 URLs for use when Identity Federation is configured to act as an SP.

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

28.6.4 Using WS-Federation 1.1

Access Manager now supports features of the WS-Federation 1.1 protocol.

WS-Federation 1.1 partners can be created using the new addWSFed11IdPFederationPartner and addWSFed11SPFederationPartner WLST commands. After creating the partners, the profiles can be configured using the existing WLST Identity Federation commands. For details, see the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference for Identity and Access Management.

Note:

Partial administration of the WS-Federation 1.1 partners is available using the Oracle Access Management Console.

28.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 28-9 summarizes the types of information that you can configure for Identity Federation using Oracle Access Management Console.

Table 28-9 Configuring Identity Federation Settings

Configuring ...	Description
Federation Administrators	Administrators who can manage federated partners and related configuration.
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 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 Administering Identity Federation As A Service Provider or 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".
Policies for Use with Federation	Manage policies for use with federation partners. See "Managing Access Manager Policies for Use with Identity Federation".

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

Table 28-10 Implementing Identity Federation

Task	Reference
Enable the Identity Federation service.	Enabling Identity Federation
Configure federation settings.	Managing General Federation Settings
Identity IdP and/or SP partners, and configure attributes for them.	Administering Identity Federation As A Service Provider
Configure an authentication or authorization policy.	Managing Federation Schemes and Policies
Protect a resource with this policy.	Managing Policies to Protect Resources and Enable SSO

28.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 28-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 WebLogic Scripting Tool Command Reference for Identity and Access Management

Figure 28-1 Available Services Page

Description of "Figure 28-1 Available Services Page"

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

A Confirmation window is displayed.
Click OK.
Enable Access Manager: Click Enable beside Access Manager (or confirm that the green Status check mark displays).

A Confirmation window is displayed.
Click OK.