[mitreid-connect] Re-requesting tokens

[James Agnew]

Ah ok that makes sense. I was thinking of it from the perspective of my own
closed environment, where I trust all the applications.

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.

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

James


On Fri, Sep 5, 2014 at 4:31 PM, Richer, Justin P. <jricher at mitre.org> wrote:

>  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>
> 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> 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
>> > 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/8b421cab/attachment-0001.htm