RE: [saml-dev] 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?]

["Scott Cantor" <cantor.2@osu.edu>]

> 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

Mostly. Not in the technical details, but I have to assume that's a
consequence of not actually reading the spec to confirm them.

> 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!  

There are three legal bindings for transmitting any SAML message through the
browser, so there's no requirement that a redirect be used. And redirects
are the only binding that runs into size limitations.

> 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?

That isn't what the redirect would look like. The details of the encoding
for that binding are defined in the HTTP Redirect binding. It involves a
DEFLATE operation over the XML along with a custom signature encoding.

http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

> 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.  

Nope. Connections aren't relevant, HTTP is a stateless protocol. Sessions
are managed with things like cookies but are out of scope of SAML.

> 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:

Details of which are governed by the HTTP POST binding.

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

Web SSO is fairly ugly.

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

Which the profiles document does pretty well:
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

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

If you mean why does the SP trust the IdP, it's out of scope. The SAML
assertion is signed, and it's up to the software to define ways for
controlling signature evaluation usually using PKI libraries and
configuration files. This is easily the hardest part of any SSO system.

> 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.

Not really, but it's kind of beside the point here.

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

Because this is a tautology. The message is handed to it by the John Doe
connection. That is exactly why it knows.

> Answer: The AuthnRequest has an id attribute:
> 
>     <saml:AuthnRequest id="a1490fa93"> . </saml:AuthnRequest>
>
> The Response XML document has an attribute called InResponseTo:

That connects the various pieces for state management purposes internally,
but it has nothing to do with "connections" because HTTP is stateless.

-- Scott