[Openid-specs-ab] Session Management / Logout Discussion at IIW 6-May-14

[Mike Jones]

Session Management / Logout Discussion at IIW 6-May-14

Back channel logout

Multiple RP sessions might be logged in at once
OP doesn't have session identifiers
Torsten - back channel logout has been shown to cause problems
Chuck - the session-based SAML logout doesn't work well and isn't supported
Brian - requiring JavaScript on every page a non-starter in enterprise contexts
Alan Karp - Better UI could help users better understand what's actually going on
John - one requirement can be extending session lifetimes across sessions
Chuck - The only session state typically present is the session cookie
Brian - SAML has fragile redirect chain
               Another means is for the IdP to do a GET to each RP endpoint
               Ping is currently implementing something like that
Naveen - Unless the browser tab is active, the JavaScript logout doesn't work
Naveen - Yahoo had a variant where they stored state for all sessions in a single cookie
Brian - Doing GETs to single-pixel images, which trigger logouts
John - The RP could check the referer if it wants to secure the logout
               But in general, not protectable against XSRF
Chuck - Browsers are getting better about preventing cookie state manipulation in iframes
Torsten - Will check what DT is doing
John - ID Token "exp" claim doesn't trigger logout in practice
Naveen - We could just document both front channel mechanisms as optional
               Enterprises might choose one method, the Web might choose another
               We should document both as a next step
Mike - If we support multiple mechanisms, the RPs would get to decide
John - Back channel notification is yet a third mechanism
David Pinter - The front channel won't always be available
Bill Mills - Security policy may require ability to kill all sessions
John - A compromise back channel mechanism is notifying RPs on the back channel of a state change

Mechanisms:
               postMessage:
                              Pro: RPs get notifications, minimal web traffic
                              Con: Requires RP JavaScript
                                   Doesn't work when RP tab not active
               image/iframe GETs:
                              Pro: Doesn't require JavaScript
                                   Still uses session cookies
                              Con: IdP needs to track active RP sessions
                                   Ugly logout page
                                   All RPs might not be notified before the browser is closed
               backchannel notifications:
                              Pro: Works even when RP tab not active
                              Con: Requires RP logic to identify and communicate with session to logout
                                   IdP scaling issues

Chuck - Current spec doesn't work for enterprise use cases because of JavaScript requirement
               and because the RP must be active for the logout to work
Chuck - We didn't put "jti" in the ID Token - we could for enabling logout
               That would enable correlating back channel notifications received to active sessions
               Open questions about whether to use the same ID in multiple responses to same RP
               Probably use a separate session identifier that is not "jti"
Dale - Back channel notification is effectively ID Token revocation
Chuck - The OP wants to be authoritative for the session ID
Chuck - Revoking a session could be done like an OAuth revocation
               OAuth revocation supports CORS and JSONP

Actions:
               Add image/iframe description to Session Management
               Also describe back channel mechanism
               Then we decide what to do after that

Naveen, Breno - Google is planning to build a token caching layer
               It would get tokens at login time and clear them at logout
               It would send notifications when things change
               It would communicate internally with postMessage
               postMessage requires a security layer
George - How is this like the Trusted Agent in the Native Applications work?
Naveen - It's a lot like that
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140507/d53a11a7/attachment.html>