<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
0D51Y0000AIrSkcSQFOkta Classic EngineIntegrationsAnswered2024-04-02T16:02:14.000Z2021-01-20T00:21:27.000Z2021-01-22T14:02:27.000Z

RobM.62038 (Customer) asked a question.

Trouble with RelayState in IdP-initiated SSO scenario

I have configured an okta SAML 2.0 IdP to support our OIDC application for inbound IdP-initiated SSO. When we test with the customer we get the error:

 The recipient specified in the SubjectConfirmation did not match our service provider entity id. Found "{0}", expected "{1}"

the URL is:

 /sso/saml2/0oa740yy8rMG35uRr357?RelayState=https://pressganey.okta.com/home/oidc_client/0oa16oxmsbp1dkHyz357/aln177a159h7Zf52X0g8

When we take off the RelayState parameter there is no error but we are routed to the okta products page rather than directly to our application. We've used the RelayState parameter successfully in the past to route directly to our application (rather than to okta). Why is it failing this time? Should we be sending RelayState some other way?

 

Thanks for the help.


    • RobM.62038 (Customer)

      The problem is fixed. The issue was caused by the manner in which RelayState was configured at the customer IdP (implemented in Azure). Previously they had been configuring their ACS URL with an appended RelayState parameter. The parameter was causing the SAML request to be rejected at okta as described in this case. The customer found a separate configuration setting for RelayState in their Azure configuration, removed RelayState from their ACS URL, and configured it at the separate setting. Everything worked as expected after that.
      Expand Post
This question is closed.
Loading
Trouble with RelayState in IdP-initiated SSO scenario