<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
I haven't yet deployed IdPv3 - it's on the plan for this year. But I know from our university's point of view from what was in IdPv2 that Logout would prefer to flow like:
<div class="">
<ul class="">
<li class="">SP Log's out immediately</li><li class="">SPs are encouraged to redirect to IdP for further logout (not required)</li><li class="">IdP informs user of options and information, as in:
<ul class="">
<li class="">You have logged out of SPx</li><li class="">Would you like to remove your IdP session?</li><li class="">Would you like to attempt to log out of all SPs?</li></ul>
</li></ul>
<div class="">To us that puts all the choice of how a user might need it to behave at the hands of the user. We believe that it is their session afterall - so they should have the choice on how it is used.</div>
</div>
<div class=""><br class="">
</div>
<div class="">We never enabled IdPv2 SLO from SPs as it did too much with very little user control. We did provide a link on the welcome page of the IdP to manually initiate a logout at the IdP. But I've even then had some SPs misusing the IdPv2 /profile/Logout
- by silently opening the the URL in an iframe and killing of the IdP session. We don't consider that SPs own the user's IdP session - so they can only make requests of it can do - not demands. Also you do get asked if we want to login when we get the first
AuthnRequest, kind of happens on further requests if uApprove is also enabled. So I see this as being asked what to do on the first Logout. </div>
<div class=""><br class="">
</div>
<div class="">Rightly or wrongly - whether this is in the standard or not - unfortunately it is the way some of us need it to work to be able to use the feature at all. I can understand that different IdP admins may require different flows to us. I'd be happy
to put in a request for something about having the flow options available. I am only familiar from this thread with how it currently works. But to me it seems like being able to configure how much power we admins give the user on the logging out flow is really
what it being asked for. As I understand, if the hooks in the logout flow were available, then really it can be implemented how we need even if the default did not provide it.</div>
<div class=""><br class="">
</div>
<div class="">Cheers,</div>
<div class="">Aaron</div>
<div class="">
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 25 Feb 2016, at 3:56 AM, Cantor, Scott <<a href="mailto:cantor.2@osu.edu" class="">cantor.2@osu.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<blockquote type="cite" class="">* Cantor, Scott <<a href="mailto:cantor.2@osu.edu" class="">cantor.2@osu.edu</a>> [2016-02-24 17:21]:<br class="">
<blockquote type="cite" class="">The point wasn't to make SLO work later, the user has just said they<br class="">
don't want SLO<br class="">
</blockquote>
<br class="">
(right now)<br class="">
</blockquote>
<br class="">
I could argue the question you're both asking the user here belongs at the SP, not the IdP. The standard really doesn't say that an IdP that receives a LogoutRequest is supposed to ask anything. It pretty much says "the session authority MUST..."<br class="">
<br class="">
Also, there are *two* endpoints here (3 if we include CAS), the SAML endpoint and the regular old /idp/profile/Logout endpoint. If you explicitly go to that endpoint, I'm again not clear on the point of asking. We don't ask if you want to login when we get
an AuthnRequest.<br class="">
<br class="">
<blockquote type="cite" class="">Fair enough. If those people knew that they hereby have removed any<br class="">
chance of also getting rid of any SP sessions, I claim that they might<br class="">
reconsider.<br class="">
</blockquote>
<br class="">
Nothing is stopping anybody from adding that text, that's a local presentation decision.<br class="">
<br class="">
<blockquote type="cite" class="">His expectation matches exactly the behaviour I included in Univie's<br class="">
IDP for local logout years ago, though, so that's probably why I<br class="">
sympathize with it. (FWIW, that local logout page didn't offer two<br class="">
buttons/choices, just one to actually perform the logout, plus text to<br class="">
inform the subject to otherwise just continue their work.)<br class="">
</blockquote>
<br class="">
That's sort of my point. We're arguing over the meaning of a choice I'm not really sure about the point of asking. I don't think either question makes a great deal of sense really, and there's definitely a question in my mind about doing this in the SAML case.
I left that there because it was easier than making them behave differently, but I don't like it.<br class="">
<br class="">
I think if it gets a request to logout, it needs to do that. If in your mind that means it needs to immediately attempt SLO and communicate the overall outcome, then I think that's probably what it should do (which doesn't need a patch, just auto-select yes).<br class="">
<br class="">
In effect, I think the request here is for a conditional logout option, which is not something we were attempting to provide, and then a statement that the current No option is bad. Since having that option there is a default, it could simply be made a non-default
without actually removing it.<br class="">
<br class="">
-- Scott<br class="">
<br class="">
-- <br class="">
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" class="">
users-unsubscribe@shibboleth.net</a><br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
<span style="font-size: 9.0pt; font-family: 'Calibri'; "><em><strong><br>
Important Notice:</strong> The contents of this email are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in error, please delete
it and any attachments immediately and advise the sender by return email or telephone.<br>
<br>
Deakin University does not warrant that this email and any attachments are error or virus free.</em></span>
</body>
</html>