Shibboleth Developers

[Adam Lantos <>]

Hi,

I've quickly added an off-domain SP to our slo-test federation.

* https://www.aai.niif.hu/SLODemo/sloDemo.php
* select SP2 only! (you can use SP3, but do not try SP1 since the
shibd is unfortunately segfaulting on that host now...)
* use this URL to initiate a session on a foreign domain Shibboleth SP
(you have to deal with the certificate problems, then you will see a
403, but this is normal, the session is created nevertheless):
https://openid.kirdev.sch.bme.hu/Shibboleth.sso/Login?entityID=https://sandbox.slotest.aai.niif.hu/idp/shibboleth&target=https://openid.kirdev.sch.bme.hu/

* check the session: https://openid.kirdev.sch.bme.hu/Shibboleth.sso/Session
* initiate logout from SP2:
https://sp2.slotest.aai.niif.hu/Shibboleth.sso/Logout
* use the "all services" button
* check session again

The logout indicator page is using IFrames to do the logout. I've
tested it with FF3.5.5, Opera 10 and Chromium on Linux, IE8 on
Windows. Logout is actually working in all these browsers with the
off-domain SP.


--
 Adam


On Mon, Dec 7, 2009 at 8:11 PM, Scott Cantor 
<>
 wrote:
> Paul Hethmon wrote on 2009-12-07:
>>> By definition, if we're saying that we can loophole the cookie
> limitations
>>> in frames using Javascript, then any of the client justifications for
>>> blocking the cookies with the frame would apply to Javascript.
>>
>> Agreed. Though its tempting to try and exploit this loophole.
>
> Apparently, yeah. But should we seriously consider shipping a logout or
> discovery design that depends on it? What happens if it changes in FF 4.0?
>
> I'd feel a lot better if I could find a clear justification for this
> difference in constraints in a Mozilla design document, but I guess the next
> step is ask somebody.
>
> Obviously Safari, Chrome, and Opera to a lesser extent, also matter, but all
> I need is one counterexample.
>
> -- Scott
>
>
>