1

Concerning passive federation, I'm wondering how the transport of the security token from STS to the relying party works exactly. On nearly every article regarding the Windows Identity Foundation and passive federation it is said that browser redirects (is it by the way a 30x http code?) and cookies are the only "tools" that are used. But: when the STS stores the token in a cookie and redirects the browser to the relying party after that, how is it possible that the relying party can read this cookie? Isn't there something like a same origin policy for cookies (like javascript has it)? The issuer of the cookie (STS) is another address/source/domain than the relying party, is the relying party nonetheless allowed to access this "foreign" cookie or is it some magic in the background that makes tis possible?

Thank you

ceran
  • 1,392
  • 1
  • 17
  • 43

1 Answers1

3

The STS doesn't send a cookie, it would be impossible.

Rather, the STS returns to your browser a page containing: a) the SAML token in the page body (XML) b) the action=Relying Party url + the javascript to autosubmit the form

The browser happily submits such form to the relying party. It is then responsible for creating the authentication cookie used to authenticate consecutive requests from the client.

There's no "magic", just a SAML token passed explicitely in the request body. The token is signed by the STS certificate so the RP can validate its authenticity.

Wiktor Zychla
  • 47,367
  • 6
  • 74
  • 106
  • Thank you, that is plausible. – ceran Nov 21 '11 at 12:39
  • For other people who find this and are curious, the form which is automatically submitted via Javascript will gracefully degrade and show a submit button for the user to manually click through if Javascript is turned off. You can turn JS off and test for yourself using an inspection tool like Chrome Dev Tools to see the intermediate form. – Travis Watson Dec 18 '12 at 16:53