No IDP Response Data SAML Identity Provider [SOVLED]

I am trying to setup an SSO sign-on method for our Ignition 8.1 gateway. We tested SAML2 in our lab environment and even without attribute mapping I could get a clear response. When I updated the attribute mapping, everything went to the correct place.

Now I am attempting to do the same in production environment and I see the following behavior:

  1. After clicking test login, the browser momentarily switches to the SSO login screen but before I can see any of the text entry fields, it re-directs back the Ignition gateway.

  2. Back at the gateway, I get the message “No IdP Response Data” I have attached the full log message but the last line says "Expected response destination to be ‘https://removed for security:8043/data/federate/callback/saml’ but got ‘null’.

When creating the identity provider, all I am doing is importing the metadata from the url provided by our IT department. I have tried all combinations of validate response/assertion signatures but it doesn’t make any difference.

Does anyone with experience on this same issue have any advice or things we might try for trouble shooting?


error log.txt (6.3 KB)

You’ll want to grab the actual SAML Response that is being sent back to Ignition to further troubleshoot the issue. Ignition is not getting back a response with attributes that it expects.

Some folks use a browser plugin called “SAML Tracer” to help grab the response. You can also use chrome dev tools to record network activity, and then find the redirect request back to Ignition’s /data/federate/callback/saml route. The response will be base64 encoded in the POST body as SAMLResponse attribute value (or as the same in the query params in case it is an HTTP GET redirect binding back to Ignition, which is more rare).

Feel free to DM me the response. If you’re having trouble grabbing this, I’d reach out to support for further assistance.

@jspecht thanks for your advice. Just writing here so everyone else can see.

After adding SAML trace to a chrome browser, We could see in the response coming back from the IDP that there was no destination specified. Then after our IT modified it, we could see and parse the response without issue.