How do I debug my SSO SAML integration with zendesk

Question

I am setting up a single sign on SAML service with zendesk. I am writing a custom SAML server using node/express and using node-samlp.

Zendesk is the SP, My SAML server has its own IdP

The user steps are as follows:

Navigates to account.zendesk.com and gets redirected to account.com/login?SAMLRequest=asdfasdfafsd

User then enters credentials and posts to the node server. At the server I am able to parse* the SAMLRequest, verify the user and give the user a SAMLResponse.

The user receives from the node server a SAMLResponse and is redirected to: account.zendesk.com?SAMLResponse=asdfasdf&RelayState=xxx

At that point the user gets a page not found. I am not sure what I'm doing wrong, at this point I'm guessing that my SAMLResponse is either badly formatted or I am redirecting the user to the wrong address.

PS: initially samlp didn't work right out of the box, I forked the repo and updated a couple dependencies and it started to work.

*I was unable to parse the SAMLRequest from zendesk initially. When I used decodeURIComponent on the query param, there were new line characters and white spaces which I replaced with a '+' which made it work. Then I realized that their query param seems to not be URI encoded...

Answer 1

Indeed, as @hans-z already mentioned, a SAMLResponse is always sent over POST! You can trigger this browser POST by serving a page that automatically submits a form (containing the SAMLResponse) on page load (through JavaScript).

Since you're sending over POST, your SAMLResponse should not be URL encoded anymore.

Answer 2

For one thing there is no such thing as a SAML Redirect Binding for the SAML Response. You can send the SAML Response as a form-encoded parameter in an HTTP POST, but you cannot pass it as a query parameter in a redirect. Your SAML IDP implementation is not spec-compliant and Zendesk may be rejecting the message because of that.

See http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf#page=16 :

5. Identity Provider issues to Service Provider In step 5, the identity provider issues a message to be delivered by the user agent to the service provider. Either the HTTP POST, or HTTP Artifact binding can be used to transfer the message to the service provider through the user agent. The message may indicate an error, or will include (at least) an authentication assertion. The HTTP Redirect binding MUST NOT be used, as the response will typically exceed the URL length permitted by most user agents.