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

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

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

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

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

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

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

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