Proposal: bound persistent CIMD client creation (#50532) #52796

saivarun1410 · 2026-09-15T16:42:13Z

saivarun1410
Sep 15, 2026

Context: #50532 is a triaged prerequisite for MCP Authorization support. On current main, a previously unseen URL-shaped client_id passes through the CIMD executor into AbstractPersistentClientIdMetadataDocumentProvider.createClientMetadata(), which persists a ClientModel. The only CIMD-specific state is the cache-expiry attribute; there is no quota, provenance marker, or garbage-collection path.

I would like to contribute a fix, but want to align on the intended protection before coding. A process-local/IP-based rate limiter would be ineffective across nodes and reverse proxies, so I do not think it is an appropriate solution.

Questions for maintainers:

Should the bound be per exact host, or per configured trusted-domain rule (including wildcard rules)?
When a bound is reached, should Keycloak reject a new client_id, or first remove expired CIMD-managed clients?
Is a scheduled, cluster-safe cleanup task desired, or should the first PR be limited to a durable quota?
Is an explicit CIMD ownership marker acceptable so cleanup/counting never affects administratively created clients?

Once the intended semantics are confirmed, I propose a focused PR with configuration and documentation, an explicit CIMD-only marker, and functional tests covering distinct paths under one trusted host, the capacity boundary, and preservation of ordinary clients. I will keep the patch limited to the CIMD provider/configuration boundary and use the existing integration-test style.

lubineitor · 2026-09-17T00:17:57Z

lubineitor
Sep 17, 2026

I agree that a process-local or IP-based rate limiter would not solve the persistent-growth problem in a clustered deployment.

My preference for the first implementation would be:

Scope the quota to the matched trusted-domain rule, rather than to the full client_id URL. The URL should be normalized before determining the quota scope so that path or query variations cannot bypass the limit. For wildcard rules, I would use one aggregate quota for the rule.
Add an explicit CIMD ownership marker to every dynamically created ClientModel. Counting and cleanup should only affect clients with this marker; the client ID format or expiry attribute alone should not be used to identify them.
At capacity, perform a bounded cleanup of expired CIMD-managed clients, re-check the quota, and reject the new client if the limit is still reached. The quota must remain correct even if cleanup fails.
For the first PR, I would focus on a durable quota, the ownership marker, configuration, documentation, and functional tests. A scheduled cluster-safe cleanup task could be a follow-up if it makes the initial change too broad.
Any cleanup task should be idempotent, batched, and use Keycloak’s existing cluster-aware task infrastructure rather than a process-local scheduler.

Keycloak already has a Max Clients Policy for client registration, but it appears to be realm-wide and does not provide a CIMD-specific ownership boundary, so I do not think it is sufficient by itself: Client Registration documentation.

The proposed tests look good. I would additionally cover:

Different paths and query strings under the same trusted host sharing one quota.
Different hosts matched by the same wildcard rule sharing the aggregate quota.
Ordinary administratively created clients never being counted or deleted.
Concurrent creation attempts not exceeding the configured limit.
Expired clients being removed only when they carry the CIMD ownership marker.

0 replies

Navigation Menu

Repository navigation

Proposal: bound persistent CIMD client creation (#50532) #52796

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Proposal: bound persistent CIMD client creation (#50532) #52796

Uh oh!

saivarun1410 Sep 15, 2026

Replies: 1 comment

Uh oh!

lubineitor Sep 17, 2026

saivarun1410
Sep 15, 2026

lubineitor
Sep 17, 2026