Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reuse existing sessions created by kcadm-wrapper.sh? #327

Closed
nblock opened this issue Nov 14, 2024 · 3 comments · Fixed by #328
Closed

Reuse existing sessions created by kcadm-wrapper.sh? #327

nblock opened this issue Nov 14, 2024 · 3 comments · Fixed by #328

Comments

@nblock
Copy link
Contributor

nblock commented Nov 14, 2024

The current implementation of kcadm-wrapper.sh uses --no-config and performs a full login for each request to the admin REST API. This has a few drawbacks:

  • A full login is slow, especially since Keycloak changed the settings of PBKDF2 in Keycloak 23.
  • Each login creates a new session which pollutes the session log.
  • With persistent user sessions (Keycloak 25+) this also consumes more resources in the database).

With this PoC-patch we got some improvements in our environment:

  • Before: 1011.32 seconds for a Puppet run on Keycloak 26 and 760 new "admin" sessions in the database
  • After: 971.41 seconds for a Puppet run on Keycloak 26 and 1 new "admin" session in the database
  • NOTE: the reduced runtime is "only" ~40 seconds because we reduced the number of rounds in the hash algorithm for the master realm. If you are using Keycloak's default values, you should see a bigger speed improvement.

There might be way better ways to implement this, for example by providing the ability to overwrite the kcadm-wrapper.sh.

@nblock nblock changed the title Reuse existing sessions created by kcadm.sh? Reuse existing sessions created by kcadm-wrapper.sh? Nov 14, 2024
@treydock
Copy link
Owner

I really like the idea of fewer API calls, as I've also noticed that catalog apply time is quite long. However I'm worried about just checking the exit code. One solution that I might give a shot is updating the Puppet code to run the config command in Ruby and check the expiration here:

# jq '.endpoints."http://localhost:8080/".master.refreshExpiresAt' ~/.keycloak/kcadm.config
1731797192115

It should be possible for the Ruby code to check the kcadm.config and re-run the config command if the refresh token is expired.

@treydock
Copy link
Owner

Checkout #328. I haven't tested it but if it actually works the acceptance tests should pass.

@nblock
Copy link
Contributor Author

nblock commented Nov 18, 2024

It should be possible for the Ruby code to check the kcadm.config and re-run the config command if the refresh token is expired.

This works, except for this edge case:

  • The file /opt/keycloak/conf/kcadm.config exists and its not expired yet
  • An admin purges all active sessions via the Security Admin Console: SessionsActionSign out all active sessions

The code assumes a valid session and Puppet fails. A workaround is to delete /opt/keycloak/conf/kcadm.config or wait until the refresh token is expired (roughly 2 hours).


Maybe it is not too relevant as this resolves itself and there is a reasonable error message in Keycloak's log:

… type="REFRESH_TOKEN_ERROR", realmId="master", realmName="master", clientId="admin-cli", userId="null", error="invalid_token", reason="Session not active", refresh_token_type="Refresh" …

treydock added a commit that referenced this issue Nov 18, 2024
* Reuse session when running kcadm commands
Fixes #327

* Move to using kcadm-wrapper config file so that script is just a script and not a template

* Fix conditional

* Remove kcmadm login session when Keycloak service restarts unless using persistent sessions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants