NIIF SLO Questions

[Kristof Bajnok]

On 2011. October 11. 16:44:56 Paul Hethmon wrote:
> I've been working this past week on actually pulling out your SLO code and
> packaging it in a separate jar for inclusion with the main Shib release.
> That's actually working out pretty well. I've only found 3 core Shib
> classes that actually need modifications to support the SLO work. I
> haven't got to the point yet to see if there is an alternate to that.

Although Adam (and probably Chad) knows the actual implementation lot better 
than me, I also remember that some minor api extension was necessary, mostly 
for session NameID indexing.

I've just noticed that I can not find the issues in Jira anymore (SIDP-336 and 
SIDP-338), so I can't say this for sure.

> Anyway, one of the initial reasons I went down this path was due to a
> customer submitted but (to me) that the SLO request would not get
> redirected back to the initiating relying party. So what I see is that the
> sloController.jsp file actually implements most of the logout logic. It
> also does not provide for the user's browser session to be redirected back
> to the initiating relying party site (with the appropriate LogoutResponse
> message).

IMHO it's imperative to inform the user about the status of the logout, so an 
interception of the user UI is inevitable. SimpleSAMLphp has a button for 
returning to the initiating SP; I don't know if users tend to click on "Return 
to the originating SP" button, and also not if an SP could tell them anything 
reasonable on return.

Back at the beginning we used to return the final LogoutResponse via 
redirecting the UI but we ran into some disturbing error message some cases. 
For that reason, I think it's always safer to leave the user at the logout 
page.

Ideally, this behaviour should be configurable, but I see no point adding this 
as a feature to the IdPv2 version of the code. For v3, I'm also not sure, 
because the ability of dealing with returning users is an 'SP thing', however 
it's the IdP (admin) is who controls the flow. IMHO, delivering the 
LogoutResponse as UI redirect is only reasonable if SPs need to behave in a 
specific way (beyond standard).

(On the other hand, one may argue that SLO itself is also not for general use, 
and I can't deny that.)

> 1. Why did you choose to encapsulate the SLO logic in the jsp page as
> opposed to the handler or servlet? 

If I understand right, your question is about the final redirect. The idea was 
to place everything about the UI into the JSP. The servlet itself only uses 
pure redirects. It's the (ugly) UI which embeds this in an IFrame and makes it 
feeling like a parallel thing. At the cost of requiring third party cookies, 
unfortunately.

> 2. Why is their no redirect to the initiating relying party at the end?

It's sent in an IFrame by default. 
Try switching off frames or JavaScript and you will see what it really does. 
With Shibboleth SP default config, you will get an "error message" that Global 
Logout completed successfully.

Kristof