[keycloak-dev] Client and Service Account Session

[Zaunegger, Jörg]

Hi Thomas,

thanks. Of course I will give it a try.
Today I did also try to find a solution by myself.
Because we are using AccessTokens in our applications to access other applications, we will having the problem not only with spring-boot-admin. What do you think about caching the AccessTokenResponse.

If the AccessToken is not valid but the RefreshToken is, then we obtain a new AcessToken with that RefreshToken. If the RefreshToken is no longer valid, we obtain a new token with the credentials of the service account.
It seems to work. Do you see any problem with this solution?

Cheers Jörg

Von: Thomas Darimont <thomas.darimont at googlemail.com>
Gesendet: Mittwoch, 13. Februar 2019 16:27
An: Zaunegger, Jörg <Joerg.Zaunegger at kvbawue.de>
Cc: keycloak-dev at lists.jboss.org
Betreff: Re: [keycloak-dev] Client and Service Account Session

Hello Jörg,

I built an example app that demonstrates this spring-boot-admin / Keycloak setup.

Would it help to use offline_tokens for the spring-boot-admin service account instead of normal refresh-tokens?

Unfortunately the Keycloak Admin client library currently does not support custom scopes like scope=offline_access.

I just pushed a PoC with patched offline_access support via a custom TokenManager. Would you mind giving it a try?
https://github.com/thomasdarimont/spring-boot-admin-keycloak-example/tree/poc/keycloak-offline-access

Cheers,
Thomas

Am Mi., 13. Feb. 2019 um 10:43 Uhr schrieb Zaunegger, Jörg <Joerg.Zaunegger at kvbawue.de<mailto:Joerg.Zaunegger at kvbawue.de>>:
Hi Pedro,

In our application we are securing spring-actuator endpoints with a keycloak role. These endpoints are requested repeatedly (every 5 s) by an application called spring-boot-admin<https://github.com/codecentric/spring-boot-admin>. For the request spring-boot-admin obtains an AccessToken. Because there is a session for each request, we have thousands of open sessions for the service account of spring-boot-admin.
Any news, suggestions or solutions on avoiding these open sessions?

Thanks.
Jörg Zaunegger

-----Ursprüngliche Nachricht-----
Von: keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org><mailto:keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>> <keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org><mailto:keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>>> Im Auftrag von Pedro Igor Silva
Gesendet: Montag, 13. November 2017 09:52
An: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org><mailto:keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>>
Betreff: RE: [keycloak-dev] Client and Service Account Session


Hi,

Currently, every time a confidential client tries to get a new access token
from the token endpoint a new session is created on the server. This can
lead to multiple active sessions for a single client/service account when
doing multiple requests to token endpoint.

To avoid that the client should store the access token/refresh token and
use a refresh token when appropriate in case the access token has expired.
That is fine.

Now, suppose a confidential client is deployed and wants an access token. A
new session will be created on the server. In case the application goes
down for some reason (e.g.: container moved to a different node in
kubernetes and without a persistent volume) and tries to get a new access
token, we may end-up with two active sessions when asking for a new token
after a re-deploy.

What are your thoughts about re-using existing sessions when doing client
credentials ? What could be the impact on clustering if we need (and we'll
probably need) to update the session ?

Another question would be ... Does make sense to also enable clients to
obtain tokens without necessarily creating a session on the server ? I
think that in most cases, you don't really want to keep track of sessions
when doing client credentials.

Regards.
Pedro Igor


_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev