Repository navigation
Analyse how to make Client Policies independent from Client API Representations #47576
Description
Description
At this moment, some contexts used for client policies evaluation includes field proposedRepresentation that just passes the Representation/DTO object to the client policy executor and then tries to determine whether the policy applies or not.
You can check the AdminClientRegisterContext or AdminClientUpdateContext contexts.
The issue here is that it's not usable for the Client V2 as we don't have any old ClientRepresentation objects available, and we have only the representation/DTO objects for the Client V2.
For that case, we just temporarily create the old representation from the ClientModel, and pass it there to comply with the current client policies implementations and executors.
However, these contexts should not contain the DTO as it may change, and it should rather use some abstract object, like ClientModel?
Activity
bkoragan commentedon Apr 20, 2026
@mabartos I dig into this. Here's what I see:
Current State
ClientCRUDContext.getProposedClientRepresentation() returns a v1 ClientRepresentation and is consumed by 15 executors (e.g., SecureRedirectUrisEnforcerExecutor, PKCEEnforcerExecutor, SecureClientAuthenticatorExecutor) and 2 conditions (ClientProtocolCondition, ClientAccessTypeCondition).
The v2 DefaultClientService.createOrUpdate() works around this by delegating to v1's ClientsResource.createClientModel() with a minimal ClientRepresentation (only clientId, protocol, auth). Policies evaluate against incomplete data — the full v2 config is applied after policy evaluation.
Key Observation
Every property these executors/conditions read (redirect URIs, protocol, authenticator type, grant types, attributes, etc.) is also available on ClientModel. They don't need the incoming DTO — they need the proposed state of the client.
I could think of below options -
Option A: Replace with ClientModel — Change getProposedClientRepresentation() to return ClientModel. V2 would apply its representation to a transient model first, then pass it to policy evaluation. Clean and DTO-agnostic, but requires updating all 17 consumers and handling transient model construction.
Option B: Build a full v1 ClientRepresentation from v2 — Map the complete v2 representation before triggering policies. Zero executor changes, but perpetuates the v1 dependency.
Option A aligns with the direction you suggested and seems to the right long-term approach. Option B could serve as a short-term unblock if needed.
Happy to hear your thoughts on the preferred direction. Once aligned, I can help create follow-up implementation issues or a proof-of-concept PR. Thanks!
vmuzikar commentedon Nov 5, 2026
As this is more affecting Client Policies rather than Client v2, we'll not be doing this for now. Client Policies should use something else than Representations which are considered a public (now versioned) API and not an internal DTO. But this refactoring will be a bigger task...
[-]Analyse how to provide V2 representation for client policies[/-][+]Analyse how to make Client Policies independent from Client API Representations[/+]