That was actually a third alternative that we also initially considered, but discarded. We
wouldn’t get single-sign-out on open URLs, and sign-out would be delayed. It’s not ideal,
but in practice it would probably be OK… except that later on in the request, Undertow (in
Wildfly) would throw an exception whenever someone invoked getSession(...) and used the
returned object. However, apparently there are several bug fixes for this in Undertow, so
we can attempt to upgrade and try this approach out. Thanx for the reminder.
~Dan
Fra: Stian Thorgersen [mailto:sthorger@redhat.com]
Sendt: tirsdag 3. januar 2017 10.53
Til: Dan Østerberg <dan(a)ren.no>
Kopi: keycloak-user(a)lists.jboss.org
Emne: Re: [keycloak-user] Log out server sessions when using bearer authentication
What about a simple filter that looks at the session state from the token and associates
it with the http session if one is set? If the tokens session state is different to the
http session invalidate it.
On 3 January 2017 at 10:39, Dan Østerberg <dan@ren.no<mailto:dan@ren.no>>
wrote:
Yes, avoiding to store any security related stuff in the session would ensure that
authentication / permissions are read from the current access token. But… the entire
problem isn’t solved, since the server session still won’t be invalidated. Lets say I log
in and trigger some REST calls. For some of those, a session is created, storing my
personal information. Then I log out – from Keycloak. You log in, and get a new security
context but can access my personal information still stored in my old server session.
(Naturally, this also goes for the same user logging in again – seing old session data
that he shouldn’t see. It’s just a less severe issue.)
When logging out normally, the client can trigger logout from all x webapps it (might)
have accessed. But that won’t happen when logging out via another webapp, or kicking out a
session from Keycloak admin console.
Maybe the problem isn’t so big if all precautions are taken. But it’s still a problem, and
I still can’t see how it can be completely solved other than by one of the two approaches
I outlined.
~Dan
Fra: Stian Thorgersen [mailto:sthorger@redhat.com<mailto:sthorger@redhat.com>]
Sendt: tirsdag 3. januar 2017 10.26
Til: Dan Østerberg <dan@ren.no<mailto:dan@ren.no>>
Kopi: keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
Emne: Re: [keycloak-user] Log out server sessions when using bearer authentication
As I suggested just make sure the sessions don't contain the security context and that
all requests that require security include an access token even when there is a session.
Problem solved.
Or the much more complicated approach and find some way of centrally track all sessions to
all REST services to destroy all session on logout. Keycloak can't do that as we only
track sessions from application that do the actual login not services that are invoked by
those applications.
On 3 January 2017 at 10:06, Dan Østerberg <dan@ren.no<mailto:dan@ren.no>>
wrote:
The other way around – to _mainly_ use stateless REST services. With client-controlled
tokens.
The fact that single-sign-out wont affect the client until token renewal is attempted is
OK. And in most cases we’ll even eagerly detect that, using a simple a cookie-logic. But
the problem is if/when some REST call creates a session. Then that session won’t be
invalidated, even if the user (or another user) logs into Keycloak again. We need to
address that somehow.
As I see it, we either need to:
1) Prevent session creation. Easy said, but we don’t control all code, and it’s
fairly easy for one programmer to accidentally e.g. inject a session-scoped WELD bean in
code reachable from a REST service. If going for this route, we’d at least need mechanisms
for detecting if a session was after all created, and notify developers plus maybe
auto-destroy it. Or wrap the request so that sessions aren’t created (with uncertain
consequences). Since parts of the webapps + shared libraries might be used statefully, it
gets a bit messy.
2) Connect all sessions to the single-sign-out controller (Keycloak).
I evaluated 2) to be the cleaner approach, but wanted to know if Keycloak has some
built-in solution.
~Dan
Fra: Stian Thorgersen [mailto:sthorger@redhat.com<mailto:sthorger@redhat.com>]
Sendt: tirsdag 3. januar 2017 08.52
Til: Dan Østerberg <dan@ren.no<mailto:dan@ren.no>>
Kopi: keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
Emne: Re: [keycloak-user] Log out server sessions when using bearer authentication
Not really following what you are saying. Are you saying you want your REST services to be
stateful and use cookie based security rather than tokens? Or the other way around?
On 3 January 2017 at 08:40, Dan Østerberg <dan@ren.no<mailto:dan@ren.no>>
wrote:
Thanx for the reply. But wouldn’t that be a bit against the whole point with token based
authentication? We’ve used Jasig CAS before, and thereby used internal server-only
authentication + server session. That’s very similar to Keycloak used the way you describe
– and limiting in several ways. If that was the only option, we would have stayed with
CAS. Being stateless & having more control in the client is certainly beneficial in a
client-heavy REST-based application, where the client accesses multiple webapps (within
the same realm).
I guess we’ll just have to implement some in-house solution then...
~Dan
Fra: Stian Thorgersen [mailto:sthorger@redhat.com<mailto:sthorger@redhat.com>]
Sendt: mandag 2. januar 2017 15.16
Til: Dan Østerberg <dan@ren.no<mailto:dan@ren.no>>
Kopi: keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
Emne: Re: [keycloak-user] Log out server sessions when using bearer authentication
There's no standard way of doing backchannel logout with OAuth2. There's a draft
spec for OpenID Connect that we may implement in the future.
Keycloak has it's own proprietary backchannel logout, but that's only for
applications that do the login. In your case as it's a JS app that obtains the tokens
there's no backchannel logout involved and instead it relies on the session cookie +
access token timeout. Assuming your JEE app is a rest service it should create a session
that allows invoking without a access token from the JS app. That way it won't be
possible for the JS app to invoke it once the session is logged out as it won't be
able to obtain new access tokens.
On 29 December 2016 at 11:27, Dan Østerberg <dan@ren.no<mailto:dan@ren.no>>
wrote:
Hi,
How can we make single sign out work when passing bearer tokens to a server guarded by a
«traditional» session based Oauth2 client / adapter?
Lets say we use bearer authentication via the Javascript adapter, and make REST requests
to a stateless (no session) server. Lets further say that during some later request, a
server session will be created – either intentionally to store state, or unintentionally
e.g. by some shared code (since sessions are auto-created in Java EE). Now single sign out
won’t work, because Keycloak is neither aware of the server session nor the Oauth2 client
that has an admin URL.
One solution could be to detect the creation of a session, and internally via an extended
REST API tell the Keycloak server to create a session also for the client with admin URL
(connecting it to the created session ID). But it just sounds as if this should be covered
out-of-the-box, so maybe I’m just missing or misunderstanding something...
~Dan
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user