11:03 a.m.
----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Thursday, 9 October, 2014 12:02:07 AM
Subject: [keycloak-dev] Stateless session management pushed
Some summary of my changes:
- Added new parameter "http_session_id" to code-to-token request. It's
not mandatory and used just for AS7/Wildfly adapters. In Keycloak, it's
saved as note in ClientSessionModel.
- ResourceAdminManager refactored to use the IDs of httpSession, which
are retrieved from ClientSessions. Removed username and
keycloakSessionId from LogoutAction
- Adapter statistics removed and everything related to them.
- UndertowUserSessionManagement and CatalinaUserManagement are now fully
stateless.
- Added new config option to adapters 'always-refresh-token' as we
discussed. If it's true, then adapter will always send request to
refresh accessToken during authentication (doesn't apply for bearer
authentication, just for cookie). In the end I've used this approach
instead of validating accessToken . It seems to be safer (no window) and
you are always fine with 1 additional request. This option is useful in
cluster in case that you have non-distributable sessions. With
non-distributable it could happen that your user logged on node1, but
logout request from KC is handled on node2 where httpSession doesn't
exist. This is no issue with "distributable" sessions as those are
replicated and hence logout can happen on any node.
- https://issues.jboss.org/browse/KEYCLOAK-741 -- If refreshing token
fails from adapters, then httpSession is invalidated immediatelly
So clustering on adapters side works well now for both Wildfly & EAP 6.3
Questions & remaining work:
- I am not so happy with logout for apps with non-distributable HTTP
sessions. It can be handled with 'always-refresh-token' but it's
performance penalty to always refresh token. The alternative might be to
send also hostname in code-to-token request. This would help as
ResourceAdminManager will be able to detect to which node send request
for invalidate http session. Does it worth adding it?
Can you elaborate on the 'hostname' in code-to-token requests? I don't quite
get what that would do.
I think the two options we have currently is sufficient, if properly document:
a) Logout doesn't happen until access token expires (default)
b) Access token is always refreshed (make sure we document the potential performance hit)
As an optimization I think we should do is that we should add a cookie that is invalidated
when a user logs-out. The cookie would only be invalidated for the application driving the
logout (retrieves the 'final' logout redirect) or for applications using the
coming crazy logout redirect loop. My reasoning is that I think a) is sufficient for
single-sign out, but if a user logs-out through a specific application at least that
application should show a logged out state straight away.
- Is it ok to have parameter like "http_session_id" or should it be
instead something more generic like "adapter_session_id" ? I am not sure
if 'Http Session' is not JEE specific term? I looked at OpenID connect
and there is no something like this mentioned (In fact OpenID Connect
doesn't handle single-sign-out)
I don't think there's nothing JEE specific about a http session, but it leaves
some confusion to which session. What about 'application_session_state'?
- Should we add https://issues.jboss.org/browse/KEYCLOAK-702 (Support
for storing token in cookie instead of HttpSession) or is it ok to leave
it for later? Note that for logout it will require
'always-refresh-token' or "hostname" stuff I mentioned above.
I think we should add it now, see my comment above (only the driving app has to be
logged-out immediately IMO).
thoughts?
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev