1
votes

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

1

1 Answers

3
votes

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.