You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Keycloak modules currently accept a token (user-provided access token) parameter to allow for a single token for Keycloak API requests to be shared amongst tasks, rather than authenticating to get a token at the start of each tasks.
Problem
Typically a Keycloak access token expires after 10 minutes or less, so for long-running playbooks, it's possible for the token to expire mid-playbook, causing subsequent tasks to fail with a 401 on their first request to Keycloak. Currently the modules do not support refreshing of the token or "falling back" to individually authenticating.
Proposed Solution(s)
I see two ways the modules could more robustly react when the user-provided access token is expired (i.e., a request to Keycloak gets a 401):
The username and password parameters (if provided) are used to authenticate instead.
I.e., fall back to per-task authentication.
This solution is probably the simplest, but fails to provide the benefit of sharing the token amongst tasks.
Add a refresh_token parameter to the modules, so they can try refreshing if the token is expired. As part of this, the modules should provide back to the user the refreshed access token in their output, so it can be used in subsequent tasks.
This does require the user to handle getting the refreshed token from the module output to be used in subsequent tasks.
I believe both could be implemented, with (2) being a first fallback and (1) being a second.
I've listed a few of the modules affected, but this would affect most if not all of the keycloak_... modules.
Summary
Context
The Keycloak modules currently accept a
token
(user-provided access token) parameter to allow for a single token for Keycloak API requests to be shared amongst tasks, rather than authenticating to get a token at the start of each tasks.Problem
Typically a Keycloak access token expires after 10 minutes or less, so for long-running playbooks, it's possible for the token to expire mid-playbook, causing subsequent tasks to fail with a
401
on their first request to Keycloak. Currently the modules do not support refreshing of the token or "falling back" to individually authenticating.Proposed Solution(s)
I see two ways the modules could more robustly react when the user-provided access token is expired (i.e., a request to Keycloak gets a 401):
username
andpassword
parameters (if provided) are used to authenticate instead.refresh_token
parameter to the modules, so they can try refreshing if the token is expired. As part of this, the modules should provide back to the user the refreshed access token in their output, so it can be used in subsequent tasks.I believe both could be implemented, with (2) being a first fallback and (1) being a second.
I've listed a few of the modules affected, but this would affect most if not all of the
keycloak_...
modules.Issue Type
Feature Idea
Component Name
keycloak_authentication, keycloak_authz_authorization_scope, keycloak_authz_custom_policy, keycloak_authz_permission, keycloak_client, keycloak_group, keycloak_realm, keycloak_role
Additional Information
Code of Conduct
The text was updated successfully, but these errors were encountered: