[Openid-specs-ab] Session cleanup via back-channel
Pedro Felix
pmhsfelix at gmail.com
Fri Mar 14 14:58:56 UTC 2014
Regarding the motivation for a back-channel session cleanup mechanism:
1) The iframe based polling mechanism is useful, namely in SPA apps,
however it imposes additional requirements. Namely, it requires additional
coordination between the browser-side and the server-side of the "client" -
the browser side must inform the server-side of the session status change.
In my perspective, it is fundamental to ensure session cleanup on the
server-side. Also, as Todd mentioned, the browser-side of the app may not
always be active.
2) One of the scenarios for our OP is currently based on Shibboleth, where
this back-channel cleanup is common. Namely, the OP will be receiving
back-channel cleanup notifications from a upstream Shibboleth IdP and will
have to propagate these down to the OIDC RPs. Since this process is
occurring on the back-channel, it is not even possible to update the
browser state (e.g. via the session cookie).
Makes sense?
Thanks
Pedro
On Thu, Mar 13, 2014 at 8:11 PM, George Fletcher <gffletch at aol.com> wrote:
> So I'm to blame for the confusion... see the other email I just sent:)
>
> As for browsers and JS. Basically, yes, the browser does not run JS from
> historical pages so the problem comes when the user navigates the same
> browser window from RP "A" to RP "B" and then logs out. If the user had two
> tabs open, one for RP "A" and one for RP "B", then the JS solution will
> work just fine.
>
> Thanks,
> George
>
> On 3/13/14 3:53 PM, Todd W Lainhart wrote:
>
> > Your example seems to indicate that JavaScript code in pages present in
> the browser history doesn't get to run unless the page is the displayed
> page. Is that correct?
>
> I'm also not an expert, but that's my understanding.
>
> > Do you have any sense why this issue also prompted discussions on
> non-opaque access tokens and introspection?
>
> I don't. That's something that George/Justin brought up. Went over my
> head.
>
>
>
>
>
> * Todd Lainhart Rational software IBM Corporation 550 King Street,
> Littleton, MA 01460-1250*
>
>
> * 1-978-899-4705 <1-978-899-4705> 2-276-4705 (T/L) lainhart at us.ibm.com
> <lainhart at us.ibm.com>*
>
>
>
>
> From: Mike Jones <Michael.Jones at microsoft.com><Michael.Jones at microsoft.com>
> To: Todd W Lainhart/Lexington/IBM at IBMUS,
> Cc: George Fletcher <gffletch at aol.com> <gffletch at aol.com>, Justin
> Richer <jricher at mitre.org> <jricher at mitre.org>,
> "openid-specs-ab at lists.openid.net" <openid-specs-ab at lists.openid.net>
> <openid-specs-ab at lists.openid.net> <openid-specs-ab at lists.openid.net>,
> "openid-specs-ab-bounces at lists.openid.net"<openid-specs-ab-bounces at lists.openid.net>
> <openid-specs-ab-bounces at lists.openid.net><openid-specs-ab-bounces at lists.openid.net>,
> Pedro Felix <pmhsfelix at gmail.com> <pmhsfelix at gmail.com>
> Date: 03/13/2014 03:26 PM
> Subject: RE: [Openid-specs-ab] Session cleanup via back-channel
> ------------------------------
>
>
>
> Thanks for the concrete example, Todd. That's useful. Your example seems
> to indicate that JavaScript code in pages present in the browser history
> doesn't get to run unless the page is the displayed page. Is that correct?
> And is the answer the same for all browsers or is it different for
> different browsers? (I'm not an expert in browser implementation details,
> so I'm openly asking this, hoping that someone on the thread does have this
> expertise.)
>
> Do you have any sense why this issue also prompted discussions on
> non-opaque access tokens and introspection?
>
> -- Mike
>
> *From:* Todd W Lainhart [mailto:lainhart at us.ibm.com <lainhart at us.ibm.com>]
>
> * Sent:* Thursday, March 13, 2014 12:12 PM
> * To:* Mike Jones
> * Cc:* George Fletcher; Justin Richer; openid-specs-ab at lists.openid.net;
> openid-specs-ab-bounces at lists.openid.net; Pedro Felix
> * Subject:* Re: [Openid-specs-ab] Session cleanup via back-channel
>
> > Am I correct or wrong that this is the same issue?
>
> It is the same issue. My sense at the time it was closed was that folks
> on the call didn't want to hold up the specs for this, and so Nat proposed
> the extension route, with the observation that the topic had been raised
> before. I'm also recalling that maybe the Googlers had something to say
> about this.
>
> > is there a reason that RPs can't learn of the OP-initiated logout via
> the JavaScript session state changed notification already in the spec?
>
> I'm not speaking for Pedro, but I'll give you an example (but real)
> scenario that prompted #916. Browser is viewing the protected resources of
> RP "A" (a session has already been started). Bob clicks a link on the page
> which now shows the representation of a protected resource from RP "B".
> Bob selects "logout", which directs "B" to the end_session endpoint.
> Ideally, "A" would get notified of the session end so that it can drop
> resources that it was associating to Bob.
>
>
>
>
>
>
>
> * Todd Lainhart Rational software IBM Corporation 550 King Street,
> Littleton, MA 01460-1250*
>
> * 1-978-899-4705 <1-978-899-4705> 2-276-4705 (T/L)*
> *lainhart at us.ibm.com* <lainhart at us.ibm.com>
>
>
>
>
>
> From: Mike Jones <*Michael.Jones at microsoft.com*<Michael.Jones at microsoft.com>
> >
> To: George Fletcher <*gffletch at aol.com* <gffletch at aol.com>>, Pedro
> Felix <*pmhsfelix at gmail.com* <pmhsfelix at gmail.com>>, Justin Richer <
> *jricher at mitre.org* <jricher at mitre.org>>,
> Cc: "*openid-specs-ab at lists.openid.net*<openid-specs-ab at lists.openid.net>"
> <*openid-specs-ab at lists.openid.net* <openid-specs-ab at lists.openid.net>>
> Date: 03/13/2014 02:47 PM
> Subject: Re: [Openid-specs-ab] Session cleanup via back-channel
> Sent by: *openid-specs-ab-bounces at lists.openid.net*<openid-specs-ab-bounces at lists.openid.net>
>
> ------------------------------
>
>
>
>
> Maybe I'm confused, but this issue seems like a duplicate of
> *https://bitbucket.org/openid/connect/issue/916*<https://bitbucket.org/openid/connect/issue/916>,
> which we'd previously discussed and decided not to fix. Am I correct or
> wrong that this is the same issue?
>
> Responding to Pedro's point "2) The OP propagate this cleanup
> notification to the downstream RPs, also via back-channel (a back-channel
> to front-channel is not possible)" - is there a reason that RPs can't
> learn of the OP-initiated logout via the JavaScript session state changed
> notification already in the spec? I realize that requiring JavaScript
> might not be your preferred mechanism, but we've also tried not to have
> multiple ways to do the same thing, unless there's a good reason to do so.
> I'm open-minded about this, but would like to hear what the arguments for
> the additional mechanism are, and if they're different than those discussed
> with issue #916.
>
> I'm also confused about the talk of structured access tokens. How do
> structured access tokens relate to logout? And why would we consider
> changing access tokens from being opaque to structured? Requiring specific
> structure would break many OAuth and OpenID Connect implementations.
>
> I'm also confused why introspection is being discussed again. We deleted
> the Check ID Endpoint, which did introspection on ID Tokens in May 2012 in
> response to developer feedback about not wanting to have to support two
> ways of doing the same thing. See
> *https://bitbucket.org/openid/connect/issue/570*<https://bitbucket.org/openid/connect/issue/570>.
> Why is this being discussed again, now that the specs are final?
>
> I guess call me confused today...
>
> -- Mike
>
> * From:* *openid-specs-ab-bounces at lists.openid.net*<openid-specs-ab-bounces at lists.openid.net>[
> *mailto:openid-specs-ab-bounces at lists.openid.net*<openid-specs-ab-bounces at lists.openid.net>]
> *On Behalf Of *George Fletcher
> * Sent:* Thursday, March 13, 2014 8:19 AM
> * To:* Pedro Felix; Justin Richer
> * Cc:* *openid-specs-ab at lists.openid.net*<openid-specs-ab at lists.openid.net>
> * Subject:* Re: [Openid-specs-ab] Session cleanup via back-channel
>
> Hi Pedro,
>
> Sorry for confusing the thread. I was responding to Nat's point about
> structured headers. It's not really relevant to the issue you are
> addressing. As for requirements for the back-channel call, you can add a
> document on the wiki, or file a new issue on the site as an enhancement for
> the working group to address and then put in the ticket all the current
> requirements. Others can then comment on the ticket and the working group
> can track it.
>
> Note, that for this back-channel capability to be relevant to an RP, the
> RP must support the concept of "server side" sessions (or maintain a "black
> list" of revoked sessions). This doesn't tend to be capabilities that most
> RPs support.
>
> Thanks,
> George
> On 3/13/14 11:12 AM, Pedro Felix wrote:
> 1) Since I'm rather new in this group, what would be the best way to
> continue this discussion? In this email thread? By trying to produce a
> requirements doc on the wiki?
> Most probably, I will be working on an implementation of this feature in
> the near future.
>
> 2) Picking up on Justin's reply: an approach would be to also use the
> "aud" and the "sub" to identify the session to cleanup. I don't like the
> idea of requiring a round-trip to the introspection endpoint in order to
> check the token purpose. Makes sense?
>
> Thanks
> Pedro
>
> On Thu, Mar 13, 2014 at 2:12 PM, Justin Richer <*jricher at mitre.org*<jricher at mitre.org>>
> wrote:
> A number of our apps use this combined approach -- the server sends out a
> signed JWT that the client can check the "iss" field and signature, then
> (if it cares to do so) the client does introspection with the server at
> "iss" to see if the token's still valid and what it's good for.
>
> -- Justin
>
> On 03/13/2014 09:48 AM, George Fletcher wrote:
> On the "structured token" side of things I remember having a discussion
> about this at IIW (a few back) and I thought someone and written something
> up. It was needed in a number of cases that were using the token
> introspection endpoint as a way to identifier the authorization server to
> send the token to for introspection. I can't find my notes on the
> conversation but maybe someone else remembers?
>
> I think conceptually it was as simple as a non-signed JWT containing iss
> and token fields. Obviously, the rest of JOSE could be applied for signed
> or encrypted tokens.
>
> Thanks,
> George
> On 3/12/14 9:02 PM, n-sakimura wrote:
> Let's just write up requirements on the WG wiki (@bitbucket).
> Once we agree on the requirements, it should be straight forward to turn
> it into a spec.
>
> On the side note, perhaps it is actually for OAuth WG, but it would be
> nice to spec out the structured (access) token. it could be pseudo opaque
> as well as long as you can find the authorization server from the token but
> we at least need to be able to find out the iss.
>
> Nat
>
> (2014/03/13 3:58), John Bradley wrote:
>
> We have discussed creating a backchannel push method for the IdP to notify
> the RP.
>
> So far noting is written up. I have a bad feeling that it might be me
> that needs to create the first draft.
>
> John B.
>
> On Mar 12, 2014, at 3:54 PM, Pedro Felix *<pmhsfelix at gmail.com>*<pmhsfelix at gmail.com>wrote:
>
>
> Hi,
>
> I've a scenario where a OIDC OP is acting as a bridge between upstream
> IdPs using non-OIDC protocols (e.g Shibboleth) and downstream RPs using
> OIDC.
> In this scenario I have the following requirements
> 1) The upstream IdP notifies the OP of a session termination via
> back-channel
> 2) The OP propagate this cleanup notification to the downstream RPs, also
> via back-channel (a back-channel to front-channel is not possible)
>
> Unfortunately, the OIDC session management spec does not provide any way
> to perform this back-channel cleanup, however I remember reading some
> meeting notes about this possibility.
>
> Is there anything that can be shared? I would like to align our solution
> with what is being developed by this working group.
>
> Thanks
> Pedro
> _______________________________________________
> Openid-specs-ab mailing list
> *Openid-specs-ab at lists.openid.net* <Openid-specs-ab at lists.openid.net>
> *http://lists.openid.net/mailman/listinfo/openid-specs-ab*<http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> *Openid-specs-ab at lists.openid.net* <Openid-specs-ab at lists.openid.net>
> *http://lists.openid.net/mailman/listinfo/openid-specs-ab*<http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>
>
> --
> [image: George Fletcher] <http://connect.me/gffletch>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> *Openid-specs-ab at lists.openid.net* <Openid-specs-ab at lists.openid.net>
> *http://lists.openid.net/mailman/listinfo/openid-specs-ab*<http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> *Openid-specs-ab at lists.openid.net* <Openid-specs-ab at lists.openid.net>
> *http://lists.openid.net/mailman/listinfo/openid-specs-ab*<http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>
>
> --
> [image: George Fletcher] <http://connect.me/gffletch>
> _______________________________________________
> Openid-specs-ab mailing list
> *Openid-specs-ab at lists.openid.net* <Openid-specs-ab at lists.openid.net>
> *http://lists.openid.net/mailman/listinfo/openid-specs-ab*<http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>
>
> --
> [image: George Fletcher] <http://connect.me/gffletch>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140314/5d6ff4ca/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 79004 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140314/5d6ff4ca/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 80944 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140314/5d6ff4ca/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XeC
Type: image/png
Size: 80944 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140314/5d6ff4ca/attachment-0002.png>
More information about the Openid-specs-ab
mailing list