<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;">
With a closely knit set of applications, the session management protocol is exactly what you want. Google's using it today to manage state across their suite of applications, which all trust each other and directly defer to the google IdP. We've got a similar
set of "core" apps on MITRE's network that will make use of the full session management protocol when it's available. Apps that aren't part of this core suite probably won't use it, which is fine because it's all optional.
<div><br>
</div>
<div> -- Justin</div>
<div><br>
<div>
<div>On Sep 5, 2014, at 5:04 PM, James Agnew <<a href="mailto:jamesagnew@gmail.com">jamesagnew@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">Ah ok that makes sense. I was thinking of it from the perspective of my own closed environment, where I trust all the applications.
<div><br>
</div>
<div>If looks like the session management protocol is exactly the solution to my issue. If I get ambitious at some point I might have a go at implementing it. For now the iframe will be fine.</div>
<div><br>
</div>
<div>Thanks for talking me through this BTW- As someone who leads an open source project implementing an equally arcane specification (HL7) I know how it is to answer basic questions repeatedly. :)</div>
<div><br>
</div>
<div>James</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Sep 5, 2014 at 4:31 PM, Richer, Justin P. <span dir="ltr">
<<a href="mailto:jricher@mitre.org" target="_blank">jricher@mitre.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">You don't want a malicious RP to be able to kill sessions across multiple RPs and the IdP. If you want to do session management, there's the OpenID Connect Session Management protocol that MITREid Connect doesn't support (yet).
<div><br>
</div>
<div><a href="http://openid.net/specs/openid-connect-session-1_0.html#RPLogout" target="_blank">http://openid.net/specs/openid-connect-session-1_0.html#RPLogout</a><br>
<div><br>
</div>
<div>Your iframe solution is a hack, but it would potentially work with the current server. No guarantee of stability of that solution over time though. </div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div> -- Justin</div>
</font></span>
<div>
<div class="h5">
<div><br>
<div>
<div>On Sep 5, 2014, at 10:48 AM, James Agnew <<a href="mailto:jamesagnew@gmail.com" target="_blank">jamesagnew@gmail.com</a>> wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">Interesting (and thanks for the reply).
<div><br>
</div>
<div>> <span style="font-family:arial,sans-serif;font-size:13px">It would be dangerous and undesirable to let an RP clear the session of the IdP automatically.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">I'm curious what makes this dangerous? I definitely understand the SSO angle, since as you point out that is one of the major benefits of using an auth server in the first place. Our problem is
that we're deploying this in a healthcare setting with shared workstations, so we have a regulatory need for users to click a logout button and not have someone else walk up and get back in.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">In other words, SSO is fine across multiple applications, but if they do choose to explicitly logout it needs to also be global (and I can't imagine we would be able to train users to go to the
IdP to logout....)</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">Is this something you (or anyone here) has encountered before? I'm thinking the right solution is just an iframe on the application's logout page that loads "<a href="https://[idb">https://[idb</a>
base]/logout". Is there a more elegant solution?</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">Cheers,</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">James</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Sep 5, 2014 at 7:59 AM, Richer, Justin P. <span dir="ltr">
<<a href="mailto:jricher@mitre.org" target="_blank">jricher@mitre.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is intentional behavior, though it can be confusing if you're thinking in terms of a single application and session. The user's session at the IdP and the RP are separate from each other. In fact, this behavior is what allows you to do SSO-style behavior
in your applications. Since the user still has a session at the IdP and has indicated that they want the IdP to not prompt them to re-log in.<br>
<br>
It would be dangerous and undesirable to let an RP clear the session of the IdP automatically. However, if your app wants to require the user to log in directly in certain situations (say, for example, you know that they've recently hit "log out"), you can
always pass "prompt=login" in that situation or set a maximum session age. I would not recommend passing that parameter all the time because it will annoy your users if they have to log in to multiple applications, which is a big feature of using an IdP.<br>
<br>
-- Justin<br>
<div>
<div><br>
On Sep 4, 2014, at 5:23 PM, James Agnew <<a href="mailto:jamesagnew@gmail.com" target="_blank">jamesagnew@gmail.com</a>> wrote:<br>
<br>
> Hello,<br>
><br>
> Hopefully this isn't a dumb question, but let's give it a shot. I have a web application (let's call it Resource Server) which is secured using a MitreID Connect installation (let's call it Auth Server). It uses the standard "code" flow, and works fine.<br>
><br>
> I need to allow the user to explicitly log out of the Resource Server. In the RS the user can click a logout button which clears their session and deletes the token. The problem is that if they try to log in again, the Auth Server automatically grants them
a new token without asking for credentials, since the user still has an active session with the Auth Server itself.<br>
><br>
> So my question is this- Is this a security hole? Should the Auth Server be clearing the user's session upon calls to "/authorize"? I'm happy to take a crack at implementing that (either as an optional feature or as default behavior) but maybe I'm missing
something fundamental.<br>
><br>
> Cheers,<br>
> James<br>
</div>
</div>
> _______________________________________________<br>
> mitreid-connect mailing list<br>
> <a href="mailto:mitreid-connect@mit.edu" target="_blank">mitreid-connect@mit.edu</a><br>
> <a href="http://mailman.mit.edu/mailman/listinfo/mitreid-connect" target="_blank">
http://mailman.mit.edu/mailman/listinfo/mitreid-connect</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>