<style>
/* Changing the layout to use less space for mobiles */
@media screen and (max-device-width: 480px), screen and (-webkit-min-device-pixel-ratio: 2) {
#email-body { min-width: 30em !important; }
#email-page { padding: 8px !important; }
#email-banner { padding: 8px 8px 0 8px !important; }
#email-avatar { margin: 1px 8px 8px 0 !important; padding: 0 !important; }
#email-fields { padding: 0 8px 8px 8px !important; }
#email-gutter { width: 0 !important; }
}
</style>
<div id="email-body">
<table id="email-wrap" align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#f0f0f0;color:#000000;width:100%;">
<tr valign="top">
<td id="email-page" style="padding:16px !important;">
<table align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#ffffff;border:1px solid #bbbbbb;color:#000000;width:100%;">
<tr valign="top">
<td bgcolor="#ffffff" style="background-color:#ffffff;color:#000000;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:12px;line-height:1;"><img src="https://shibboleth.net/images/shib_240x83.png" alt="" style="vertical-align:top;" /></td>
</tr><tr valign="top">
<td id="email-banner" style="padding:32px 32px 0 32px;">
<table align="left" border="0" cellpadding="0" cellspacing="0" width="100%" style="width:100%;">
<tr valign="top">
<td style="color:#505050;font-family:Arial,FreeSans,Helvetica,sans-serif;padding:0;">
<img id="email-avatar" src="https://issues.shibboleth.net/jira/secure/useravatar?ownerId=cantor.2%40osu.edu&avatarId=10480" alt="" height="48" width="48" border="0" align="left" style="padding:0;margin: 0 16px 16px 0;" />
<div id="email-action" style="padding: 0 0 8px 0;font-size:12px;line-height:18px;">
<a class="user-hover" rel="cantor.2@osu.edu" id="email_cantor.2@osu.edu" href="https://issues.shibboleth.net/jira/secure/ViewProfile.jspa?name=cantor.2%40osu.edu" style="color:#326ca6;">Scott Cantor</a>
commented on <img src="https://issues.shibboleth.net/jira/images/icons/issuetypes/task.png" height="16" width="16" border="0" align="absmiddle" alt="Task"> <a style='color:#326ca6;text-decoration:none;' href='https://issues.shibboleth.net/jira/browse/IDP-224'>IDP-224</a>
</div>
<div id="email-summary" style="font-size:16px;line-height:20px;padding:2px 0 16px 0;">
<a style='color:#326ca6;text-decoration:none;' href='https://issues.shibboleth.net/jira/browse/IDP-224'><strong>SAML 2 Logout Profile Actions</strong></a>
</div>
</td>
</tr>
</table>
</td>
</tr>
<tr valign="top">
<td id="email-fields" style="padding:0 32px 32px 32px;">
<table border="0" cellpadding="0" cellspacing="0" style="padding:0;text-align:left;width:100%;" width="100%">
<tr valign="top">
<td id="email-gutter" style="width:64px;white-space:nowrap;"></td>
<td>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr valign="top">
<td colspan="2" style="color:#000000;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:12px;padding:0 0 16px 0;width:100%;">
<div class="comment-block" style="background-color:#edf5ff;border:1px solid #dddddd;color:#000000;padding:12px;"><p>Some thoughts on the logout mess.</p>
<p>Ignoring the single logout aspect of this problem, the requirements here are for a couple of different entry points into the IdP that do session lookup. One uses the active session via the cookie and accesses one session. The other is a a SAML 2 logout profile endpoint that looks up 1-n sessions by NameID using a secondary lookup.</p>
<p>Both result in 1-n SPSession objects being found by combining the content of all the sessions looked up.</p>
<p>The logout flow(s) should probably destroy all the referenced IdPSessions (guaranteeing the logout basically works no matter what happens), but leave the SPSessions in some kind of LogoutContext. For the view template to have access to the information about sessions not logged out, we would need to populate a MultiRelyingPartyContext containing an RPContext for every SPSession. We could optionally do the fairly heavy work of metadata lookup and SAMLPeerEntityContext population beneath each RPContext.</p>
<p>The observation here is that any given SPSession would be associated with some procedure that populates the RPContext tree. For example, which protocol/role to lookup in metadata based on the SAML version. There's a SAML1SPSession type added now for this purpose.</p>
<p>Going further and thinking about the single logout problem, it seems to me that SAML-specific is not the way to think about it. That's a specific way of invoking the process in the IdP, and it's one of possibly many protocols for signaling SPs, but there may be others (and some protocols of course will have none).</p>
<p>In thinking about a UI, SWF <b>greatly</b> complicates this because there's no way to issue multiple requests back into the server as part of a single overall flow. Flows are linear, and a UI containing a bunch of IFRAMEs or whatever, is not linear.</p>
<p>The idea I stumbled on is to use new webflows that aren't connected to the main logout flow to launch a service-oriented request that performs a logout signaling event to an SP using a specific protocol. All the information needed to issue the logout has to be attached to the request probably by putting data into the Java session. The data should be disconnected from the original IdPSession so that it being destroyed already shouldn't inhibit making the request. In SAML this should be possible because the LogoutRequest only requires knowing the SP, NameID, and SessionIndex, all of which are inside the SPSession. So my thought is to attach the SPSession to the Java session under a random key and use that key from the UI to invoke the specific logout signalling flow to invoke.</p>
<p>So eventually we could come up with a logout UI that generates a view that populates a bunch of IFRAMEs with requests for each SP logout flow to invoke. This would apply to both front- and back-channel (obviously the UI here itself assumes front-channel logout to start with). What this does is move the overlapping of the logout signaling to the client instead of handling SOAP logout with a thread pool.</p>
<p>This UI would be extremely complex, and I don't know how to build it, but it's the only practical solution to the logout problem. Somehow we have to generate all these frame-based logout flows, and then detect when all of that work is done, and forward the flow to a final view that either renders a result or issues a LogoutResponse to the SP.</p>
<p>Obviously that all requires JavaScript, and without that capability we probably just end up with the non-single-logout UI we have today, so that would be the NOSCRIPT block.</p>
<p>I don't think I can actually build all that, but I think we can design for it and have pieces of it built so that a UI can be worked on later.</p></div>
<div style="color:#505050;padding:4px 0 0 0;"> </div>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td><!-- End #email-page -->
</tr>
<tr valign="top">
<td style="color:#505050;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:10px;line-height:14px;padding: 0 16px 16px 16px;text-align:center;">
This message is automatically generated by JIRA.<br />
If you think it was sent incorrectly, please contact your JIRA administrators<br />
For more information on JIRA, see: <a style='color:#326ca6;' href='http://www.atlassian.com/software/jira'>http://www.atlassian.com/software/jira</a>
</td>
</tr>
</table><!-- End #email-wrap -->
</div><!-- End #email-body -->