HTTP Response to a SAMLResponse POST by user agent

Question

Looking at RFC2616, is it acceptable to return an HTTP 200 (page load) as a response to a SAMLResponse post to the SP? i.e. the user-agent loads a page instead of redirecting via a 302 / 303?

Looking for clarity on 3.4.5 here https://www.oasis-open.org/committees/download.php/35387/sstc-saml-bindings-errata-2.0-wd-05-diff.pdf - does the response to a SAMLResponse POST refer to point 2 or 5?

In other words:

1. The browser sends a request to the IDP.
2. The response is sent back to the browser - it is a form with an auto-submit to the SP, with a SAMLResponse field.
3. My browser does a POST of the form to the inbound SAML endpoint at the SP
4. The SP validates the assertion, authenticating the user, and then sends a 302 redirect back to the browser.

In step 4 above, are there any concerns or issues with the response being a "200" that loads a page? Is this step 5 of the above document, and effectively outside of the SAML flow at this point? Or is this step 2 or 4 that is still within the saml flow and should be maintained as a redirect?

Answer 1

TL;DR: 200 is ok. The status code of the HTTP response after SP processes the SAML response is not defined in the SAML spec. Most SPs will do a 302 but a 200 is legal.

---

3.4.5 in the SAML Bindings portion of spec is HTTP-Redirect binding. The Redirect binding is meant for encoding SAML messages into a URL for transmission over HTTP GET. Talking about the binding as a stand-alone concept is certainly possible within the narrow context of the spec...but you really need to think about the overall flow as defined by SAML profiles. Web Browser SSO profile is the most common profile used and we presume it's the one you're interested in.

Traditional use of a HTTP-Redirect binding in Web Browser SSO profile is to request the authentication context:

1. The user agent sends the request to the SP asking for some resource
2. SP sends a SAML authentication request to IdP. This can be done using a HTTP-Redirect binding. The spec mandates a 302 or 303 for this step and this binding only. (HTTP-POST or HTTP-Artifact bindings are also legal here).
3. IdP authenticates the user (if not already done so..) and and sends a SAML response back to SP. If this leg uses HTTP-POST binding, the response is POSTed to SP as a form via the user agent.
4. SP reads the SAML response and then...it does whatever it wants, regardless of the binding.

Step 4 above, section 3.4.5 (HTTP-Redirect binding):

Upon receiving the SAML response, the SAML requester returns an arbitrary HTTP response to the user agent

Step 4 above, section 3.5 (HTTP-POST binding):

Upon receiving the SAML response, the SAML requester returns an arbitrary HTTP response to the user agent

Step 4 above, section 3.6 (HTTP-Artifact binding):

[you can probably guess by now]

The sequence of steps in your question if interpreted via the Web Browser SSO profile is IdP-initiated SSO. Our example above is SP-initiated SSO. The very last step in the sequence when the SP responds back to the requester is the same regardless of which flow is used, IdP-initiated or SP-initiated.

Answer 2

I think you refer to the descriptions like "returned in HTTP Redirect URL to SAML responder, encoded into Location header". This talks about a normal redirect at the HTTP level, which consists of a Location header in the HTTP response header and a status code of 3xx, specifically 301, 302, 307 or 308. There are no semantics defined for a Location header with status code 200.

For more see RFC 7231, 7.1.2 Location and RFC 7231, 6.4 Redirection 3xx.