[mitreid-connect] Re-requesting tokens

[Richer, Justin P.]

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).

http://openid.net/specs/openid-connect-session-1_0.html#RPLogout

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.

 -- Justin

On Sep 5, 2014, at 10:48 AM, James Agnew <jamesagnew at gmail.com> wrote:

Interesting (and thanks for the reply).

> It would be dangerous and undesirable to let an RP clear the session of the IdP automatically.

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.

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....)

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 "https://[idb base]/logout". Is there a more elegant solution?

Cheers,
James




On Fri, Sep 5, 2014 at 7:59 AM, Richer, Justin P. <jricher at mitre.org<mailto:jricher at mitre.org>> wrote:
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.

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.

 -- Justin

On Sep 4, 2014, at 5:23 PM, James Agnew <jamesagnew at gmail.com<mailto:jamesagnew at gmail.com>> wrote:

> Hello,
>
> 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.
>
> 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.
>
> 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.
>
> Cheers,
> James
> _______________________________________________
> mitreid-connect mailing list
> mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>
> http://mailman.mit.edu/mailman/listinfo/mitreid-connect



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20140905/27a0e157/attachment.htm