0

Traditionally an SSO SAML request for the authentication works as follows:

  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 302 or 303
  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.

I have a couple of problems in understanding step#3 over here.

  1. When the IdP sends a SAML response back, shouldn't it send it back to the user agent? Because that is where the request came from. If a browser makes a request to the server, the server has to give some response back to the user browser, isn't it?

  2. AFAIK, SAML Idp and SAML SP don't communicate with each other directly. Isn't that being violated here if SP directly sends the SAML response to SP?

  3. The second part - response is POSTed to SP as a form - is this the same mechanism through which the the request was also posted in the first place? AKA SP sent back an HTML file to the user agent which is used to POST a request to the IdP. And now IdP sends back an HTML file to the user agent which is used to POST a response back to the IdP?

Credits to @identigral for these steps from here: https://security.stackexchange.com/a/214198/282123

P.S: It will be great if you can reply in simple language please. There's a lot to learn and I'm trying to understand the basics first.

Improve this question

1 Answer 1

Reset to default
2

  1. The IdP returns a 200 HTTP response to the browser. The content is an HTML form with the SAML response encoded as a hidden form variable. Typically there's also some JavaScript to automatically submit the form so the user doesn't have to click a button etc. The result is an HTTP Post of the SAML response and other post data to the SP. In other words, the IdP doesn't send the SAML response directly to the SP. It's sent via the browser.

  2. HTTP-Redirect and HTTP-Post are the most commonly used SAML bindings (ie transports). Both see messages between the IdP and SP being sent via the browser. There is no direct IdP - SP communication with these bindings.

  3. The SAML authn request sent to the IdP can be sent using with the HTTP-Redirect or HTTP-Post binding. If the HTTP-Post binding is used, it's exactly the same mechanism used by the IdP when it sends the SAML response.

For a more detailed explanation, refer to the "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0" specification.

Improve this answer
2
  • Thanks a lot for replying! I feel you have answered questions #1 and #3 perfectly. The only remaining one is #2. The problem is that there are indeed times when there's direct communication between IdP and SP. For this the SP exposes what is called as an ACS URL in order for the IdP to hit it. It's not clear why we allow this direct communication when they are supposed to have a "trust-based" communication. Or whether this violates the security in some way. I don't see a mention of ACS or Assertion Consumer Service in the specification document.
    – Mugen
    Aug 29, 2022 at 7:23
  • 2
    If you're using the HTTP-Post binding to send the SAML response, which is what most deployments do, there is no direct communication between the IdP and SP. The SAML response is sent via the browser to the SP's ACS endpoint. When the browser executes the JavaScript to submit the HTML form as an HTTP Post, it's sent to the SP's ACS URL. The IdP never opens a direct connection to the SP's ACS endpoint.
    – ComponentSpace
    Aug 31, 2022 at 2:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .