[IGN-2502] Azure SSO identity provider error: Relay state is empty

Hello, I’ve run into an error setting up Azure as an Identity provider for SSO. When I try to launch Ignition from Microsoft MyApps, I get this error:

https://ignition.myCompany.com:8043/data/federate/callback/saml
404 Bad Request
Unable to parse relay state

com.inductiveautomation.ignition.gateway.auth.web.strategy.WebAuthStrategyAdapterException: RelayState is empty
at com.inductiveautomation.ignition.gateway.auth.web.strategy.saml.SAMLWebAuthStrategyAdapter.lambda$parseState$0(SAMLWebAuthStrategyAdapter.java:393)

  • When I test the Azure connection under Identity Providers, I get a valid saml response and I’ve mapped the user attributes (except roles).
  • I’ve setup SSL and HTTPS URLs work.
  • I’m using HTTP_POST for my SSO Service Binding

Do I need to setup a Relay State somewhere?

Version 8.1.2
Web browser: Firefox or Chrome on Windows 10
Only a single gateway

Ignition does not yet support IdP-initiated SSO. We do have an internal ticket tracking this feature, and I’ll link it to this thread.

For now, users will have to log into your IdP by navigating to Ignition first and initiating the login from there (SP-initiated SSO).

Thanks for the response! I have have got SSO to work from Ignition directly, so that will work.

I'm interesting for the functionality in OKTA.

Hey Jspecht. I wanted to know if this feature has been developed. Can you please let me know?

No, this feature is still in the backlog.

Just curious for those interested in IdP-initiated SSO support...where do you expect the user should land in Ignition when starting from an IdP-initiated login? We have an idea of how we want to build this feature, but I would like to understand what the community expects...

Ideally we would want the user to land in the home page of the Ignition Application after starting from an IdP-initiated login.

How will the gateway know which application to use?

I think we will have just one application / project in a gateway with IdP settings configured for it. I am still unsure but this might work.

That might work in your case, but that isn't a general solution to the question. :frowning_face:

That is something for the developers to take into consideration. Good point.

Thanks for the responses. One avenue we have looked at is using the Relay State parameter to drive where in Ignition the user is logged in (i.e. Gateway Web Interface vs Perspective Project). Seems like most IdPs support the concept of a default relay state which can be sent with the IdP-initiated login. Some IdPs also support adding multiple launch actions per single Service Provider (SP) where each launch action is tied to a distinct default relay state. I could imagine that users could use this to set up launch actions for multiple perspective projects.

Ok, didn't realize there could be aux info in the relay. Can such aux info simply indicate the project name? (Exposing my ignorance of the standard....)

Or perhaps, assuming the IdP can be disambiguated, look for a single project that has that specific IdP defined?

Or prioritize explicit relay state, but fall back to IdP matching?

Yes, that's what is attractive about the Relay State - in SP-initiated flows, the SP provides the IdP with the value, and after logging in, the IdP must provide the same value. This is how most SP's (including Ignition) correlate SAML requests with responses in addition to knowing where to send the user after they log in (usually back to the page they were on when they initiated the login).

In IdP-initiated flows, the standard allows for any arbitrary Relay State (it could be blank or it could be some fixed string). We could come up with a Relay State encoding to disambiguate an unsolicited SAML response (IdP-initiated) vs a solicited response (SP-initiated) in addition to other variables such as the IdP name and "Log into the Gateway Home/Status/Config Page" or "Log into Perspective Project named 'foo' and then navigate to page 'x/y/z'".

If an unsolicited SAML Response is received with a Relay State pointing to a target which is not configured to use the SAML IdP for authentication purposes (for example: maybe the target is Perspective Project named 'foo' which is configured with an OIDC IdP), then we would probably just throw an error page up.

1 Like