What is exactly RelayState parameter used in SSO (Ex. SAML)?

Question

I am trying to understand SSO using SAML. I have come across the RelayState parameter and am very confused exactly why it comes first in SSO to send encoded URLs? What exactly does it mean?

Please read the following from the Google Developer documentation:

Google generates a SAML authentication request. The SAML request is encoded and embedded into the URL for the partner's SSO service. The RelayState parameter containing the encoded URL of the Google application that the user is trying to reach is also embedded in the SSO URL. This RelayState parameter is meant to be an opaque identifier that is passed back without any modification or inspection

Solution 1

The original meaning of RelayState is that the SP can send some value to the IDP together with the AuthnRequest and then get it back. The SP can put whatever value it wants in the RelayState and the IDP should just echo it back in the response.

This RelayState parameter is meant to be an opaque identifier that is passed back without any modification or inspection

There is also another, de facto standard use for RelayState when using Idp-initiated log on. In that case, there is no incoming request from the SP, so there can be no state to be relayed back. Instead, the RelayState is used by the IDP to signal to the SP what URL the SP should redirect to after successful sign on. In the standard (Bindings 4.1.5) it is stated that RelayState "MAY be the URL of a resource at the service provider."

It looks like Google is using RelayState for the target URL even on SP-initiated sign on, which is perfectly fine. But the IDP should, as the documentation says, just relay it back.

Solution 2

RelayState is an identifier for the resource at the SP that the IDP will redirect the user to (after successful login). It is a way to make the process of SSO more transient to the user because they are redirected again to the same page they originally requested at the SP.

Solution 3

As per official SAML document,

Some bindings define a "RelayState" mechanism for preserving and conveying state information. When such a mechanism is used in conveying a request message as the initial step of a SAML protocol, it places requirements on the selection and use of the binding subsequently used to convey the response. Namely, if a SAML request message is accompanied by RelayState data, then the SAML responder MUST return its SAML protocol response using a binding that also supports a RelayState mechanism, and it MUST place the exact RelayState data it received with the request into the corresponding RelayState parameter in the response.

Solution 4

This below flow diagram may help you step by step. ACS URL and relayState both are different. relayState gives you one more info/url to handle where exactly user want to go. more details

View more solutions

Comments

[dey.shin]

I'm glad the 'de facto standard use' was pointed out here. I've been struggling to understand why redirect URL was sent under RelayState.

[Florian Winter]

So some IdPs (like Google) use RelayState for non-standard purposes, which can cause validation to fail on the SP's consumer endpoint? This is important, as one might want to implement the SP to reject SAML responses with invalid RelayState, as it may be used maliciously (similar to the open redirector problem in OAuth). To support IdPs like Google, the SP would have to ignore an invalid RelayState, but not reject the response altogether.

[Mark]

Just for reference, SP = Service Provider (generally the web app/service a user is authenticating to) and IDP/IdP = Identity Provider (the service where a user has an existing identity or account).

[Christian Davén]

No, this is incorrect. You are describing the Assertion Consumer Service URL.

[Yasser Afifi]

RelayState is a parameter of the SAML protocol that is used to identify the specific resource the user will access after they are signed in and directed to the relying party’s federation server. blogs.technet.microsoft.com/askds/2012/09/27/…

[Christian Davén]

In "Idp-initiated" authentication, RelayState can be used almost as you say. See Anders Abel's answer above, he is correct.

[Risto]

IdP signaling to SP with RelayState is a valid use case in the SAML 2 standard. 5.1.1.Introduction|outline 5.1.1 Introduction Sometimes a binding-specific field called RelayState is used to coordinate messages and actions of IdPs and SPs, for example, to allow an IdP (with which SSO was initiated) to indicate the URL of a desired resource when communicating with an SP.

[Anders Abel]

@Risto Thanks for commenting. Since I wrote that answer I've learnt that it is indeed mentioned in the standard, I updated my answer.