X

Tips and HowTos for Single Sign-On & Federation Oracle Identity Management Integrations

  • February 29, 2016

SP vs. IdP Initiated SSO

In today's article, I will discuss about the concepts of SP and IdP Initiated SSO between two Federation deployments, and what the differences between those two flows are.

I will also explain 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)

In this article, I will showcase examples using the SAML 2.0 protocol, though the same would apply for the other protocols.

Enjoy the reading!

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 will occur
  • 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

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 will be 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 speaking, 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 will start 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 would involve 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.

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

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

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

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

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

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 will convey the URL where the user should be redirected after the Federation SSO is complete at the SP. If missing, the SP will need to 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 would involve 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 will 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

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

Cheers,
Damien Carru

 

Join the discussion

Comments ( 16 )
  • Avid Golfer Thursday, March 3, 2016

    Good detailed explanation.

    Have two questions:

    1. In SP Initiated SSO flow, after user authentication completed, the IdP send SAMLResponse with operational state as RelayState, which is a pointer to the state in the SP Server's runtime storage and not the protected resource URL. Is this correct?

    2. In IdP Initiated SSO flow, how come SP recognize SAMLResponse sent by IdP, where there is no corresponding SAMLRequest made?


  • Damien Friday, March 11, 2016

    Hi,

    To answer your questions:

    1. That is correct, the RelayState sent by the IdP to the SP is the one that the SP specified at the beginning of the flow, when redirecting the user from the SP to the IdP with the AuthnRequest and RelayState parameters

    2. This is defined by the SAML 2.0 specifications: the InResponseTo attribute is not set in the SAML Response

    Regards,

    Damien


  • richard Tuesday, April 19, 2016

    Hi,

    I have 2 questions :

    1) During SSO, OIF consumes SAML message from IDP. As part of this , OIF needs to validate xml signature sent by IDP partner. As per document , OIF can consume messages signed by IDP partner using either SHA1 or SHA2. But does this operation depend on the certificate ( SHA1/SHA2) stored on keystore ? Does this certificate , stored in keystore, get used during xml signature verification ?

    2) When OIF signs outgoing SAML message , it either can use SHA1 or SHA2 algorithm based on configuration . But whatever algorithm is configured , does it have any dependency on the certificate ( SHA1/SHA2) stored on keystore ?

    Thanks


  • guest Friday, July 15, 2016

    Is it possible in IdP initiaed SSO flow to authenticate and get at the assertion XML response alone separately.

    I want to use the assertion XML and pass it along with the request to a Service Provider app.


  • raj Friday, July 15, 2016

    Can we directly submit to IdP Site with the credentials and get back a assertion response instead of using the IdP login page.


  • Abhijit Wednesday, October 19, 2016

    Hi,

    Could you please tell me the SP server architecture and what it contains.

    Thanks & regards,

    Abhijit


  • Damien Wednesday, November 30, 2016

    Hi,

    Responses to your questions:

    1. No, the signature on the certificate has no incidence on the signature on the incoming SAML message. OIF will use the certificate stored in the partner entry to verify the signature on the message generated by the partner

    2. No, it has no dependency, as in #1

    Damien


  • Damien Wednesday, November 30, 2016

    Hi,

    To answer the question about using the Assertion XML for other flows, this not currently supported by OIF: this service implements the SAML SSO protocol, and the SAML messages generated by OIF are specifically designed for this SSO protocol, while interacting with the user's browser.

    Damien


  • Damien Wednesday, November 30, 2016

    Hi Raj,

    You should not try to programmatically submit the user's credentials to the IdP Login page.

    The idea behind SAML SSO is to delegate the whole authentication to the IdP, without the SP being forced to understand how the IdP is challenging the user.

    The IdP might decide to change how the user is challenged, by introducing captcha features, or 2 factor authentication, and that would break the SP integration.

    Damien


  • Damien Wednesday, November 30, 2016

    Hi Abhijit,

    I am not sure I understand your question. This article was aimed at explaining the differences between SP Initiated SSO and IdP Initiated SSO operations in generic Federation deployments.

    Damien


  • guest Thursday, January 19, 2017

    Hi,

    As far as I Understand,and based on this:

    https://social.msdn.microsoft.com/Forums/vstudio/en-US/af6dc3dc-d24a-48de-a83e-b173af2a7e6f/how-can-i-specify-the-target-url-directly-in-the-saml-request-and-have-ad-fs-20-automatically?forum=Geneva

    There si no such IDP-initiated in WS-federation,So my question is : is this true?

    Also according to this : https://technet.microsoft.com/es-es/library/jj127245(v=ws.10).aspx

    The Only way to achieve it is by this path :

    entity provider security token server (STS) -> relying party STS (configured as a SAML-P endpoint) -> SAML relying party App

    Identity provider STS -> relying party STS (configured as a SAML-P endpoint) -> WIF (WS-Fed) relying party App

    Identity provider STS -> SAML relying party App

    Is this true ?

    Regards and thanks in advance


  • Damien Monday, February 6, 2017

    Hi Akram,

    IdP initiated SSO for WS-Fed 1.1 is supported on a per implementation basis I would guess. Regarding OAM/OIF, WS-Fed IdP initiated SSO is supported, both with OIF acting as an IdP and OIF acting as an SP:

    - The wctx query/post parameter would contain the URL where the user should be redirected after the Federation SSO operation is completed

    - To start an IdP initiated SSO operation from OAM/OIF, one would use the same URL as the one to start a SAML 2.0 IdP initiated SSO: /fed/idp/initiatesso?providerid=...&returnurl=...

    Regards,

    Damien


  • guest Thursday, March 2, 2017

    Hi Damien,

    We are facing an issue in 11G PS3 where SP initiated federation is working well with GET but failing in POST. Any idea if this is the expected behavior?

    Regards,

    Prashanth.


  • Damien Thursday, March 2, 2017

    Hi Prashanth,

    What kind of error are you facing, and what is OAM/OIF acting as, SP or IdP? If the federation partner is a homegrown implementation, I would suspect incorrect encoding and/or XML signature generation to the be issue, when the user is redirected to OAM/OIF from the remote federation partner.

    Regards,

    Damien


  • One Lite Nutrition Garcinia Saturday, August 11, 2018
    I was excited to find this great site. I want to
    to thank you for your time for this wonderful read!! I definitely savored every
    little bit of it and I have you saved to fav to look at new
    stuff in your website. http://y.saudhosting.com/onelitegarciniareviews209752
  • One Lite Nutrition Garcinia Saturday, August 11, 2018
    I was excited to find this great site. I want to to thank you for your
    time for this wonderful read!! I definitely savored every little bit of it
    and I have you saved to fav to look at new stuff in your website. http://y.saudhosting.com/onelitegarciniareviews209752
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.