If the SP could terminate the session based on NameID only, then front-channel Single Logout UI implementation wouldn't require acceptance of third party cookies. The request can be authenticated based on the signature, which is also mandated by the profile.
On the other hand, I admit that front-channel application notification is quite useless without cookies, but I think it's more a deployment issue. (There are other ways to tie the app session to the Shibboleth session.)
If no session is "active" for the request, and a logout request comes in, it invokes logout indirectly if it can locate the session by NameID and skips front channel notifications.
If a session is "active" it still enforces a match between that session and the NameID in the logout request. So you can't deliver somebody else's logout as an active user, but the third party cookie problem should be fixed.
Scott Cantor October 29, 2012 at 7:48 PM
A bit much to try in a patch, but I really, really want to change this, so I'll take a look.
If the SP could terminate the session based on NameID only, then front-channel Single Logout UI implementation wouldn't require acceptance of third party cookies. The request can be authenticated based on the signature, which is also mandated by the profile.
On the other hand, I admit that front-channel application notification is quite useless without cookies, but I think it's more a deployment issue. (There are other ways to tie the app session to the Shibboleth session.)