Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Handle supported standard-token-exchange together with use-cases for federated and subject impersonation #37367

@mposolda

Description

@mposolda

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 exchange and 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 as Standard token exchange:v2 is 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_V2 and TOKEN_EXCHANGE_SUBJECT_IMPERSONATION_V2 . It will be ideal if we can remove those and keep only TOKEN_EXCHANGE and TOKEN_EXCHANGE_STANDARD_V2 . This would mean also removing corresponding TokenExchangeProvider implementations

  • When request is sent to token endpoint with token-exchange grant type, we will:

    • Redirect the request to StandardTokenExchangeProvider in case that requester client has standard token exchange switch enabled AND request parameters matches with the standard token exchange (params are internal-internal token exchange)
    • Redirect the request to V1TokenExchangeProvider otherwise (if enabled)

Testing

We can probably update the tests to make sure that:

  • StandardTokenExchangeV2Test is triggered with token-exchange:v1 disabled, but also with token-exchange:v2 enabled. This is to make sure that requests are still properly handled by StandardTokenExchangeProvider even 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 {
}
  • StandardTokenExchangeV1Test can be probably kept as is (it would still test with V1, which should work fine as clients used in that test don't have standard token exchange switch enabled)

  • SubjectImpersonationTokenExchangeV1Test can be probably also kept as is. The SubjectImpersonationTokenExchangeV2Test might be removed? Abstraction of AbstractSubjectImpersonationTokenExchangeTest won't be needed if we have single subclass...

  • ClientTokenExchangeSAML2Test could be probably kept?

  • KcOidcBrokerTokenExchangeV1Test kept, but KcOidcBrokerTokenExchangeFederatedTest removed (similar case like impersonation above)

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions