RelayState

[Ankur Taneja]

Hello All,

 

I would like to understand where exactly the RelayState is stored i.e. When SP send the SAML Authn Request to the IDP with RelayState, then IDP authenticates the user and then posts the SAML Assertion/Response and Relaystate back the the SP ACS URL. I understand IDP treats Relaystate is Opaque object and forwards it as it is, but it must store it somewhere where it can fetch it again to be sent with the SAML Assertion/Reponse as a separate parameter?

 

Thank You

Ankur Taneja

[Ujwol Shrestha]

I believe you are referring to HTTP POST binding, if so the RelayState is

stored in session store.

On Wed, 8 Aug 2018 at 11:10 pm, ankurtaneja85 <

[Ankur Taneja]

Hello Ujwol,

 

Yes, i am referring to HTTP POST binding. But i have seen environments processing RelayState even when they don't have a Session Store in place (tested myself). So how and where IDP is maintaining the RelaySyate?

 

Thanks

Ankur Taneja

[Koichi Ikarashi]

Hi,

 

It is explained by a KB document:

KB000037757 : How does the "InResponseTo" Attribute in SAMLResponse impact the Federation flows ?

SP initiated transaction : we will use the SMFED_TEMPORARY_STATE cookie for the RelayState
IDP initiated transaction : we will use the RelayState present in the URL to redirect

Here is another KB:

KB000039777: What is the content of SMFED_TEMPORARY_STATE or FED_TEMPORARY_STATE cookie?

 

Regards,

Koichi Ikarashi

[Ankur Taneja]

Thanks Koichi_Ikarashi for the KB documents and information. This is what i needed. 

 

Is there any we we can see these cookies in browser SMFED_TEMPORARY_STATE or FED_TEMPORARY_STATE cookie?

[Legacy User]

Ankur

 

You'll only see SMFED_TEMPORARY_STATE or FED_TEMPORARY_STATE Cookie when CA SSO is acting as SP. I don't think this cookie is applicable OR generated when CA SSO is acting as IdP.

 

The scenario mentioned at the start of this blog is where CA SSO is acting as IdP.

• CA SSO is IdP and IdP initiated flow - In that case the relaystate must be in the encoded in the URL as a query parameter.
• CA SSO is IdP and SP initiated flow with HTTP REDIRECT Binding for SAML AuthnRequest - In that case the relaystate must be in the encoded in the URL as a query parameter.
• CA SSO is IdP and SP initiated flow with HTTP POST Binding for SAML AuthnRequest - In that case I believe the relaystate is saved into the SStore along side the SAML REQUEST. Then pulled out from the SStore along with the SAML REQUEST after authentication is completed by IdP.

 

What I'd recommend is using a FIDDLER and checking the flow. It'd tell you exactly where the relaystate is in the entire flow and how it is being passed across.

 

Regards

Hubert