3

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?

  • RFC 2616 is about HTTP in general. It is not about SAML specific semantics. But in general a redirect at the HTTP level consists of a Location field in the header and a 3xx status code. – Steffen Ullrich Jul 25 '19 at 15:17
  • thanks for the clarification Steffen. i mis-worded the question then, but my original question still stands: can we issue a HTTP 200 response to a SAMLResponse post to a SP? – Brett Jul 25 '19 at 15:27
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.

| improve this answer | |
1

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.

| improve this answer | |
  • I think that an alternative way of asking the question is that an IDP provides a SAMLResponse to the user agent, and that SAMLResponse is then posted to the SP. What step in the diagram in 3.4.5 does this request from user agent to SP refer to? is it step 5 or step 2? – Brett Jul 25 '19 at 16:07
  • @Brett: I see this as a different question. But to answer this part: the SAML requester is the SP, the SAML responder the IDP. Thus the step you ask about is 4, i.e. neither 2 nor 5. In 4 the IDP provides the response to the SP by using the user agent (browser) as a trampoline with a redirect. – Steffen Ullrich Jul 25 '19 at 18:13
  • Yes, I understand that - not sure if I am sill misphrasing the question. If I inspect requests in the user agent (e.g. browser debugging). a) The browser sends a request to the IDP. b) The response is sent back to the browser - it is a form with an auto-submit to the SP, with a SAMLResponse field. c) My browser POSTs the form the the inbound SAML endpoint. d) The SP validates the assertion, authenticating the user, and then sends a 302 redirect back to the browser. point "d" - when the browser sends back a 302 - can that be a 200 and still conform to SAML spec? – Brett Jul 26 '19 at 9:24
  • I've updated the question. – Brett Jul 26 '19 at 9:35
  • @Brett: I'm not sure what you are asking. It clearly says that steps 2 and 4 are HTTP redirect's which also means that they cannot have a status code of 200. – Steffen Ullrich Jul 26 '19 at 9:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.