Repository navigation
Replies: 1 comment 2 replies
|
I checked every condition provider currently shipped under return attributesForMatching.entrySet().stream()
.allMatch(entry -> {
// ...
return clientAttributes.containsKey(key) && clientAttributes.get(key).equals(value);
});There's no "not equals" or "not present" mode in that condition, so you can't point it at the default realm clients ( The pattern that actually works in practice is the inverse of what you're trying: instead of "any-client minus the defaults," tag your own clients with a custom attribute at creation time (something like #27188 that you linked is asking for the same capability at the platform level (a first-class exclude/negate on conditions), so if the attribute workaround doesn't fit your case, that's the right place to weigh in rather than something to wait on right now. |
|
Thank you for replying. The attribute-based approach would likely work, but I think the requirement of configuring custom attributes on a client partially negates the advantages of some of the client policies, especially those that may automatically alter settings during client creation (e.g., confidential clients). In our case, we don't use OIDC dynamic client registration, and all clients are manually set up using the admin interface. As far as I can tell this means that the attribute needs to be manually set up, which makes it more likely for an administrator to forget (which would go against the purpose of policies, at least in our use-case). Also, the client registration policies seem to only apply to OIDC clients (according to https://www.keycloak.org/docs/latest/server_admin/index.html#use-cases-2), but some policies can also apply to SAML clients (e.g., enforcing the consent required setting). |
|
For clarification, what I was thinking was if there was a way to tell if something is a built-in client. It was something similar to your idea of a custom attribute, but something akin to |
Uh oh!
There was an error while loading. Please reload this page.
Is there an option to exclude the default realm clients when creating a client policy? Some executors are implicitly incompatible with the default clients - e.g., the
confidential-clientandsecure-redirect-uris-enforcerexecutors cannot apply to the default account console client(s), since the console client is public and contains a wildcard in the redirect URI.This makes it impossible to apply the executors using the
any-clientcondition, making the policies far less efficient in providing configuration safeguards for new clients since we cannot assume they include any specific configurations that would be checked by conditions. Assuming the default clients have secure configurations - ideally using the highest security settings available for their respective applications, it would make sense to exclude them when adding policies for custom clients.Issue #27188 may also be relevant.
All reactions