-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Description
For Keycloak 26.2.0, we aim to have Standard token exchange:v2 as supported feature. However the standard token exchange:v2 does not provide support for "Federated token-exchange" and "Subject impersonation token-exchange" use-cases.
It will be ideal that the use-cases are still possible:
-
Someone want to use
Standard token exchange, which would be supported in Keycloak 26.2.0. But at the same time, he also wants to use "Federated token exchange" and/or "Subject impersonation token exchange", which would be still preview in 26.2.0 -
Someone want to disable
Standard token exchangeand handle even internal-internal use-cases with the legacy token exchange V1 . This use-case is not so important, but could be ideal to support it asStandard token exchange:v2is not shared with the community yet, so in case of blockers, people still have an opportunity to use the legacy one
Details
-
In the latest
main, we have 2 features for federated and impersonation:TOKEN_EXCHANGE_FEDERATED_V2andTOKEN_EXCHANGE_SUBJECT_IMPERSONATION_V2. It will be ideal if we can remove those and keep onlyTOKEN_EXCHANGEandTOKEN_EXCHANGE_STANDARD_V2. This would mean also removing correspondingTokenExchangeProviderimplementations -
When request is sent to token endpoint with token-exchange grant type, we will:
- Redirect the request to
StandardTokenExchangeProviderin case that requester client hasstandard token exchangeswitch enabled AND request parameters matches with the standard token exchange (params are internal-internal token exchange) - Redirect the request to
V1TokenExchangeProviderotherwise (if enabled)
- Redirect the request to
Testing
We can probably update the tests to make sure that:
StandardTokenExchangeV2Testis triggered withtoken-exchange:v1disabled, but also withtoken-exchange:v2enabled. This is to make sure that requests are still properly handled byStandardTokenExchangeProvidereven if the v1 is enabled.
Maybe just having something like this would work (note not needed to enable TOKEN_EXCHANGE_STANDARD_V2 as it would be enabled by default):
@EnableFeature(value = Profile.Feature.TOKEN_EXCHANGE, skipRestart = true)
@EnableFeature(value = Profile.Feature.ADMIN_FINE_GRAINED_AUTHZ, skipRestart = true)
public class StandardTokenExchangeV2WithLegacyTokenExchangeTest extends StandardTokenExchangeV2Test {
}
-
StandardTokenExchangeV1Testcan be probably kept as is (it would still test with V1, which should work fine as clients used in that test don't havestandard token exchangeswitch enabled) -
SubjectImpersonationTokenExchangeV1Testcan be probably also kept as is. TheSubjectImpersonationTokenExchangeV2Testmight be removed? Abstraction ofAbstractSubjectImpersonationTokenExchangeTestwon't be needed if we have single subclass... -
ClientTokenExchangeSAML2Testcould be probably kept? -
KcOidcBrokerTokenExchangeV1Testkept, butKcOidcBrokerTokenExchangeFederatedTestremoved (similar case like impersonation above)