Repository navigation
Token Exchange impersonation: guidance on upgrade path (26.2.4 → 26.5.2) and future migration #45797
Replies: 4 comments
|
Still looking for some insights on this 🙏 |
|
We are also very interested in this. When I saw the comparison table, I was quite alarmed. Use Case 4, "A client can impersonate a user", is only supported by the legacy V1 implementation, and I cannot find an adequate replacement. |
|
Only hope here is that it remains deprecated permanently. Since the new one simply removes functionality and provides no solutions. If you need to impersonate user for support/debugging - the tokens have to be in that users context and behave like it does for the user (including token refresh). Consent or not (and the v2 delegation is basically non existing and lacking for that). I don't see anything in the V2 that supports this. |
|
We are using impersonation not as Token-Exchange but over Admin-API https://www.keycloak.org/docs-api/latest/rest-api/index.html#_post_adminrealmsrealmusersuser_idimpersonation. This works fine for all Browser-Scenarios where a Browser ist involved that is capable to deal with (session) cookies because this impersonates the session and only a new session-cookie is returned. But we too look for a way to get the impersonated Token directly over an Api-Call. So this would most likely be Token-Exchange V2 which lacks the functionality. The only ways i see for now is either custom api or custom token-exchange. |
Uh oh!
There was an error while loading. Please reload this page.
Context
We use token exchange with direct (naked) impersonation for service-to-service communication:
We are currently evaluating an upgrade from Keycloak 26.2.4 to 26.5.2.
What We Observed
On 26.5.2, we encountered the NPE described in #40328 (
UserPermissionsV2.canClientImpersonate). Following the guidance in that issue, we enabled FGAP v1 with--features=admin-fine-grained-authz:v1, which resolved the problem.However, we noticed that our 26.2.4 environment does not exhibit this issue. According to the Keycloak admin console, 26.2.4 has
ADMIN_FINE_GRAINED_AUTHZ_V2enabled andADMIN_FINE_GRAINED_AUTHZdisabled—yet token exchange impersonation works.We don't fully understand why the behavior differs between these versions.
Our Questions
Question 1: Could you help us understand what changed between 26.2.4 and 26.5.2 regarding token exchange impersonation and FGAP?
Question 2: Looking at the roadmap (#43151, #38336, #44122), we understand that impersonation support is being worked on, and that v1 features are planned for removal in KC 27.0. Reading #38336, it seems the future approach may involve
subject_token+actor_tokenwith anactclaim, which differs from the currentrequested_subjectparameter. Will the future impersonation API be compatible with the current flow, or should we expect a breaking change?Question 3: If it is a breaking change, is there a recommended migration strategy for zero-downtime deployments? We're trying to understand how to transition without requiring simultaneous changes to both Keycloak and our applications.
Question 4: We're uncertain whether upgrading to 26.5.2 now (requiring FGAP v1) will complicate our future migration compared to staying on 26.2.4 (where FGAP v2 appears to work with our use case). Is there any guidance on which path would be smoother?
Our Current Plan
We plan to keep FGAP v1 enabled until impersonation is supported without it, then migrate. We'd appreciate any guidance on whether this is reasonable or if we should prepare differently.
Thank you for your time.
All reactions