ADFS integration with Thingworx - Error : urn:oasis:names:tc:SAML:2.0:status:Responder

Understanding the Error:

The error message "Response has invalid status code urn:oasis:names:tc:SAML:2.0:status:Responder, status message is null" indicates that ADFS is returning an unexpected response. The SAML response is likely missing a valid status message. This usually happens due to misconfiguration in either ADFS or the ThingWorx SAML configuration.

Troubleshooting Steps:

1. Check ADFS Configuration:

   • Certificate Validation: Ensure that the certificate used by ADFS is valid and trusted by ThingWorx.
     • Verify Certificate: Go to your ADFS server's metadata endpoint (usually https://<ADFS HOST>/federationmetadata/2007-06/federationmetadata.xml) and download the certificate.
     • Import in ThingWorx: Import the certificate into the ThingWorx SAML configuration.
   • Binding: Double-check that the ADFS binding settings (HTTP-Redirect, HTTP-POST) match the ThingWorx SAML configuration. In particular, verify that the binding used in the Relying Party trust (ThingWorx) in ADFS matches the one configured in ThingWorx.
   • Identifier: The Entity ID (Identifier) configured in ADFS for the relying party trust (ThingWorx) must match the URL specified in ThingWorx under the SAML configuration.
   • Name ID Format: Ensure that the Name ID format configured in ADFS matches the one expected by ThingWorx. Common formats are:
     • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
     • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
     • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
   • Attributes:
     • User Identification: Ensure that the ADFS configuration includes the necessary attribute(s) to uniquely identify users in ThingWorx. This is often done with the UPN (User Principal Name) or email attribute.
     • Attribute Mapping: The ADFS attribute names must be correctly mapped to the corresponding ThingWorx attribute names in the ThingWorx SAML configuration.

2. Check ThingWorx SAML Configuration:

   • Entity ID (Identifier): The Entity ID configured in ThingWorx must match the one set in ADFS for the relying party trust.
   • Assertion Consumer Service URL: Make sure this URL in ThingWorx points to the correct location where the ADFS SAML response should be sent (usually /sso/saml/acs).
   • Single Sign-On Service URL: Verify that the URL configured in ThingWorx points to the ADFS Single Sign-On service endpoint (usually /adfs/ls/ or /adfs/ls/idpinitiatedsignon).
   • Certificate: The certificate you imported into ThingWorx must be the correct public certificate for ADFS.
   • Binding: Double-check the binding setting (HTTP-Redirect, HTTP-POST) to ensure it matches the ADFS configuration.

3. Enable Debugging:

   • ADFS Logging: Enable detailed logging on the ADFS server to capture the SAML request/response exchanges. Analyze the logs for errors or unusual behaviors.
   • ThingWorx Logging: Enable detailed logging in ThingWorx (you might have to configure logging levels specifically for SAML or security components). Look for errors related to SAML parsing or processing.

4. Verify Network Connectivity:

   • Firewall: Ensure there are no firewall rules blocking communication between ThingWorx and ADFS on the required ports (typically port 443 for HTTPS).
   • Network Connectivity Tests: Use tools like ping or telnet to test connectivity between ThingWorx and ADFS.

Additional Tips:

• Test with a Browser: If you have the necessary access permissions, try logging into ThingWorx using a browser that supports SAML authentication. This can help you isolate whether the issue is with the SAML configuration itself or with the ThingWorx server.
• Use a SAML Tracer: Tools like the SAML Tracer (available as a browser extension) can be helpful to visualize and troubleshoot the SAML request/response flow.

Example: Partial Code Example (ThingWorx SAML Configuration)

Let me know if you need additional help with specific configuration details, I can provide more targeted assistance.