cookieless SP

Cantor, Scott cantor.2 at osu.edu
Sun Jul 13 17:10:35 EDT 2014


On 7/12/14, 4:22 PM, "Pascal Rigaux" <pascal.rigaux at univ-paris1.fr> wrote:
>>
>- user goes to https://portal.univ-foo.bar
>- user is redirected to https://idp.univ-foo.bar
>- user logins on idp, cookie is accepted since it is not third party
>- user is redirected to relayState https://portal.univ-foo.bar
>- this page has an iframe https://app.somewhere.com/login
>- inside the iframe :
>   - redirection to https://app.somewhere.com/Shibboleth.sso/Login
>   - redirection to https://idp.univ-foo.bar, the cookie is passed =>
>autologin

Hmm, not in my testing. That's the exact definition of a third party
cookie. The cookie is *not* sent back to the IdP there. I think you are
perhaps seeing the results of the differencees between browsers in how
they treat that issue. Some browsers will allow cookie reads but not
writes, but Firefox at least has generally blocked both.

Also, even when reads work, the V2 IdP also sets a cookie (the login
context) during the SSO process, so you need both read and write to work.
That *may* not be as much true in V3 because the web flow conversation
basically piggy backs on the container session.

>It is complex, but it works.
>I already have this in production with CAS authentication.

Then I'm pretty sure you have third party cookies enabled or are using a
browser with a weak definition.

>I would really need it to work with Shibboleth :)

I don't believe it can. Either that or I'm misinterpreting the testing
I've done in the past.

-- Scott



More information about the dev mailing list