SP vs. IdP Initiated SSO

This article discusses about the concepts of SP and IdP Initiated SSO between two Federation deployments, and what the differences between those two flows are.

This article also explains the concept of a user state or a return URL shared between the IdP and the SP during the Federation SSO, which is called:

• RelayState for SAML 2.0 TARGET for SAML 1.1 wctx for WS-Fed 1.1

• openid.return_to for OpenID 2.0 (the return SSO

• URL can contain a query parameter representing the user state at the SP)

This article showcases examples using the SAML 2.0 protocol, though the same applies for the other protocols.

Federation SSO Flows

Topology

A typical Federation deployment is made of the following entities:

• A security domain for the IdP Server, where the user has an account and where authentication occurs

• A security domain for the SP server with

  • An SP Federation Server

  • An SSO server (sometimes, the SSO Server and the SP Federation Server are the same entity)

  • SSO Web Agents integrated with the SSO Server, protecting resources and ensuring that the user is authenticated and authorized to access a resource. Failure to do so might result in an authentication flow or an authorization failure

  • Resources or Web Applications

  

  Description of the illustration Federation_deployment_Screen.jpg

SP Initiated SSO

An SP Initiated SSO flow is a Federation SSO operation that was started from the SP Security Domain, by the SP Federation server creating a Federation Authentication Request and redirecting the user to the IdP with the message and some short string representing the operation state:

• The Federation Authentication Request varies depending on the protocol used:

  • SAML 2.0: AuthnRequest

  • SAML 1.1: a URL with a parameter representing the SP

  • WS-Fed: a URL with a wtrealm parameter representing the SP and other optional parameters

  • OpenID 2.0: OpenID 2.0 Request

• The operation state (what the user was doing before the Federation SSO operation started) is conveyed in the message sent to the IdP with the user, not as the whole state, but instead as a pointer to the state in the SP Server’s runtime storage. This information is conveyed differently depending on the protocol:

  • SAML 2.0: RelayState parameter

  • SAML 1.1: TARGET parameter

  • WS-Fed: wctx parameter

  • OpenID 2.0: openid.return_to parameter which is an SP URL where the user is redirected after authentication at the IdP, which is generated at runtime by the SP, and as such can contain a query parameter referencing an operational state

Note about the operational state: Generally, the state shared in the message should not be too long, as it might break the redirect flows with the redirect URL length exceeding the maximum length that browsers can handle for URLs. As such it is always preferable during SP Initiated SSO to have the SP

• Store the operational state in memory/DB storage at the SP

• Send as the RelayState/TARGET/wctx a pointer to the operational state

There are two ways for an SP Initiated SSO flow to be triggered:

• The user requests access to a resource, which starts a Federation SSO flow. Once the Federation SSO operation is performed, the user will be redirected back to the resource requested in the first place.

• Or the user accesses directly a service on the SP server to specifically start a Federation SSO flow with a remote IdP. In this case, the user typically provides the URL where the user should be redirected after the Federation SSO operation is performed

Accessing a Resource

This is the most common flow for Federation SSO operations, where the user attempts to access a protected resource, and the SSO system at runtime determines that the user needs to be authenticated via Federation SSO.

The use cases where this flow is used can be:

• User clicks on a link on any page referencing the protected resource

• User clicks on a link on a portal page referencing the protected resource

• User has a bookmark for the protected resource

The flow involves the following steps:

1. User’s browser request access to a protected resource

2. The SSO Web Agent intercepts the call, determines that the user needs to be authenticated and issues a redirect back to the user’s browser

3. The user’s browser accesses the SSO server, being redirected by the SSO Web Agent

4. The SSO Server determines that the user should be authenticated via Federation SSO, selects an IdP, creates a SAML 2.0 AuthnRequest message, saves the operational state in the SSO server store and redirects the user’s browser to the IdP with the SAML message and a string referencing the operational state at the SP

5. The user’s browser accesses the IdP SAML 2.0 service with the AuthnRequest message.

Description of the illustration Accessing_Resources_Screen.jpg

Once the IdP receives the SAML 2.0 AuthnRequest message, the server determines if the user needs to be challenged (not authenticated yet, session timed out…). After the possible identification of the user, the Federation SSO flow resumes.

1. The IdP creates an SSO Response with a SAML 2.0 Assertion containing user information as well as authentication data, and redirects the user’s browser to the SP with the message and the RelayState parameter

2. The user’s browser presents the SSO response to the SP server

3. The SP validates the SAML 2.0 Assertion and creates an SSO session for the user. The SSO server is then redirect the user’s browser back to the resource originally requested

4. The user’s browser requests access to the resource. This time the SSO Web Agent grants access to the resource

5. The Web Application returns a response to the user’s browser

Description of the illustration Accessing_Resources_Response_Screen.jpg

As mentioned previously, this flow is the most commonly used, as the Federation SSO is only triggered by the SSO server at runtime, without any other components in the SP Security Domain needing to be aware of Federation.

Invoking a Federation SP Service

This flow is not widely used, as it implies that the Federation SSO will be started at the SP by accessing a service at the SP server, and by disregarding any existing valid session the user could already have. As such this should be avoided as it incurs a performance impact on:

• The servers as Federation SSO is expensive (XML for some protocols, digital signatures to protect the messages, communications between servers)

• The user’s experience as the browser will be redirected across different domains resulting in a delay before the user can get access to the targeted protected resource.

The use cases where this flow is used can be:

• User clicks on a link on any page referencing the protected resource (unusual)

• User clicks on a link on a portal page referencing the protected resource

The use cases where this flow is used involves the following steps:

1. The user’s browser accesses the SP to start a Federation SSO flow by optionally specifying

   1. The URL where the user’s browser should be redirected after the Federation SSO is complete

   2. The IdP to be used

2. The SSO Server selects an IdP if not provided and selects the default return URL if not provided, creates a SAML 2.0 AuthnRequest message, saves the operational state in the SSO server store and redirects the user’s browser to the IdP with the SAML message and a string referencing the operational state at the SP

3. The user’s browser accesses the IdP SAML 2.0 service with the AuthnRequest message.

Description of the illustration IdP_Service_with_AuthnRequest_Screen.jpg

Once the IdP receives the SAML 2.0 AuthnRequest message, the server determines if the user needs to be challenged (not authenticated yet, session timed out…). After the possible identification of the user, the Federation SSO flow resumes:

1. The IdP creates an SSO Response with a SAML 2.0 Assertion containing user information as well as authentication data, and redirects the user’s browser to the SP with the message and the RelayState parameter

2. The user’s browser presents the SSO response to the SP server

3. The SP validates the SAML 2.0 Assertion and creates an SSO session for the user. The SSO server is then redirect the user’s browser back to the resource originally requested

4. The user’s browser requests access to the resource. This time the SSO Web Agent grants access to the resource

5. The Web Application returns a response to the user’s browser

Description of the illustration IdP_Service_with_Response_Screen.jpg

This flow should be rarely used, as the Federation SSO is triggered statically, even if the user already has a valid SSO session. Also, it implies that some components in the SP Security Domain to be aware of the SP service.

IdP Initiated SSO

An IdP Initiated SSO flow is a Federation SSO operation that was started from the IdP Security Domain, by the IdP Federation server creating a Federation SSO Response and redirecting the user to the SP with the response message and an optional operational state:

• The Federation SSO Response varies depending on the protocol used:

  • SAML 2.0: SAMLResponse with Assertion

  • SAML 1.1: Response with Assertion

  • WS-Fed: Response with Assertion

  • OpenID 2.0: OpenID 2.0 Response

• The optional operation state in this flow conveys the URL where the user should be redirected after the Federation SSO is complete at the SP. If missing, the SP must determine where the user should be redirected. This information is conveyed differently depending on the protocol:

  • SAML 2.0: RelayState parameter

  • SAML 1.1: TARGET parameter

  • WS-Fed: wctx parameter OpenID 2.0: this protocol does not support IdP Initiated SSO flow.

As noted in the previous section, the state shared in the message should not be too long, as it might break the redirect flows with the redirect URL length exceeding the maximum length that browsers can handle for URLs.

This flow is commonly used when IdP users need to access resources hosted by an SP, but it is not the best approach for Federation SSO, as it disregards any existing valid session at the SP the user could already have. As such this should be avoided as it incurs a performance impact on:

• The servers as Federation SSO is expensive (XML for some protocols, digital signatures to protect the messages, communications between servers)

• The user’s experience as the browser will be redirected across different domains resulting in a delay before the user can get access to the targeted protected resource.

The use cases where this flow is used can be:

• User clicks on a link on an IdP portal page referencing the protected resource at the SP.

The use cases where this flow is used involves the following steps:

1. The user’s browser accesses the IdP to start a Federation SSO flow by specifying

   1. The SP to be used

   2. Optionally the URL where the user’s browser should be redirected after the Federation SSO is complete

2. After having identified the user, the IdP creates an SSO Response with a SAML 2.0 Assertion containing user information as well as authentication data, and redirects the user’s browser to the SP with the message and the RelayState parameter

3. The user’s browser presents the SSO response to the SP server

4. The SP validates the SAML 2.0 Assertion and creates an SSO session for the user. The SSO server is then redirect the user’s browser back to the resource originally requested

5. The user’s browser requests access to the resource. This time the SSO Web Agent grants access to the resource

6. The Web Application returns a response to the user’s browser

Description of the illustration SSO_Response_Screen.jpg

Conclusion

As seen in the various flows, the best approach in a Federation deployment is for the Federation SSO to be triggered by the SSO server, at runtime, when it is deemed required by the SSO server. The other cases have a static approach and always exercise a Federation SSO flow, even if it is not required (if the user has already a valid session for example), and performing unnecessary Federation operations impact:

• The servers’ performances (CPU, LDAP/RDBMS interactions…)

• The user’s response time, based on the time it takes to perform a Federation SSO operation with the redirects involved.

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.

---

Title and Copyright Information

SP vs IdP Initiated SSO

F60244-01

September 2022

Copyright © 2022, Oracle and/or its affiliates.