Slingshot an AuthnRequest XML document to an Identity Provider via a browser using HTTP Redirect [was: I have created a sample SSO scenario; Am I understanding correctly how SAML is to be used?]

["Costello, Roger L." <costello@mitre.org>]

Hi Folks,

 

I believe that I now understand the mechanism for browser-based single sign-on.  Below I have described the mechanism in considerable detail.  Do I have a correct understanding?  /Roger

 

Suppose that John Doe, with his browser, follows the link that is provided by the airline service:

 

    http://www.CarRentalInc.com

 

The car rental service won’t give John Doe anything until he has been “authenticated”.  Recall that the car rental agency has a business partnership with AirlineInc.com, which is responsible for doing all authentications.

 

The car rental service needs to tell the airline service, “Hey AirlineInc.com, please authenticate the person that has just entered my Web site”.

 

That is, the car rental service must send to the airline service an authentication request XML document:

 

   <saml:AuthnRequest>…</saml:AuthnRequest>

 

Here’s how the car rental service does this:

 

The car rental service responds to John Doe’s browser with an HTTP Redirect, redirecting John Doe’s browser to the airline service.  And the AuthnRequest XML document is attached onto the HTTP Redirect, thereby, in effect, “slingshotting” the XML document to the airline service, via John Doe’s browser! 

 

Pretty cool, aye?

 

Here are the nitty-gritty details of how this slingshotting works:

 

When John Doe clicks on this link:

 

    http://www.CarRentalInc.com

 

his browser creates this HTTP message:

 

GET / HTTP/1.1

Host: www.CarRentalInc.com

 

This HTTP message gets routed through the Internet until it finally gets to the car rental service.  The car rental service then creates an AuthnRequest XML document, and replies to the HTTP message with this HTTP Redirect:

 

HTTP/1.1 307 Temporary Redirect

Location: https://www.AirlineInc.com?XML=<AuthnRequest>...</AuthnRequest>

 

Notice that the Authentication Request XML document is part of the URL (it’s the value of a query parameter).

 

The browser receives the HTTP Redirect message … and then what happens? 

 

Answer: The browser will automatically create another HTTP GET message, using the value of the HTTP Location field as the new URL. 

 

That is, John Doe’s browser will receive the HTTP Redirect message from the car rental service, and then create this new HTTP GET message:

 

GET / HTTP/1.1

Host: www.AirlineInc.com?XML=<AuthnRequest>...</AuthnRequest>

 

This HTTP message gets routed through the Internet until it gets to the airline service.

 

Thus, the XML document gets slingshotted to the airline by embedding it within the URL, using HTTP Redirect. 

 

QUESTION: Can you confirm that I have a correct understanding thus far?  I suspect that the angle brackets in the XML document have to be escaped for it to be a legal URL, right?

 

Recall that before going to the car rental service John Doe had already authenticated with the airline service.  Consequently, (this is important) he still has an open HTTP connection with the airline server.  Thus, when John Doe’s browser slingshots the AuthnRequest to the airline server there is no need for the airline server to re-authenticate John Doe. 

 

Cool!

 

The airline server parses the AuthnRequest XML document, and creates an authentication response XML document:

 

    <saml:Response>…</saml:Response>

 

Now the airline service needs to send the Response XML document back to the car rental server. This XML document is too big to put on the URL (there are limitations on the length of a URL), so the airline service cannot slingshot it back to the car rental service using another HTTP Redirect. 

 

Instead, the airline HTTP POSTs it directly to the car rental server:

 

POST / HTTP/1.1

Host: www.CarRentalInc.com

 

<saml:Response>…</saml:Response>

 

The car rental service parses the Response XML document, and then makes the decision to allow John Doe to access the resources at his service. 

 

Lastly, the car rental service responds to John Doe:

 

HTTP/1.1 200 OK

 

<HTML>…</HTML>

 

The browser displays the HTML to John Doe.

 

 

Whew!  That’s a lot of work just to make it so that John Doe doesn’t have to log in again.

 

 

It is useful to summarize the flow of all the HTTP messages:

 

John Doe’s browser –> HTTP GET –>

 

      car rental server –> response (HTTP Redirect) –>

 

           John Doe’s browser –> HTTP GET –>

 

                 airline server –> HTTP POST –>

 

                       car rental server –> response –>

 

                            John Doe’s browser displays the HTML from the car rental server!

 

There are two issues that remain:

 

1. I said that the airline HTTP POSTed the Response to the car rental service.  How did the car rental service authenticate the airline?

 

Answer: Let’s assume that long before John Doe came along the airline had authenticated with the car rental service.  So, the HTTP connection was still open.  Thus, the airline can interact with the car rental service at any time, without re-authenticating.

 

2. How did the car rental service know that the Response XML document from the airline was for the John Doe connection?

 

Answer: The AuthnRequest has an id attribute:

 

    <saml:AuthnRequest id=”a1490fa93”> … </saml:AuthnRequest>

 

The Response XML document has an attribute called InResponseTo:

 

    <saml:Response InResponseTo=”a1490fa93”> … </saml:Response>

 

The car rental service knows that the Response XML document is for the John Doe connection by checking that the InResponseTo attribute matches the id attribute.

 

QUESTION: Can you confirm that all the above is accurate?

 

/Roger