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?
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 <
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?
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 RelayStateIDP 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?
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?
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.
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.