#50798 Apply protocol defaults when creating clients through Admin AP… - #50801
Conversation
There was a problem hiding this comment.
Pull request overview
This PR ensures Admin API v2 client creation applies the same protocol-specific defaults as the legacy (v1-based) creation flow by reusing LoginProtocolFactory.setupClientDefaults, and adds interoperability tests to verify key defaults for minimal OIDC and SAML client creation.
Changes:
- Invoke
LoginProtocolFactory.setupClientDefaults(...)during Admin API v2 client creation to apply protocol defaults before validation. - Preserve “omitted vs explicitly set” semantics for specific SAML fields so protocol defaults are applied correctly.
- Add interop tests asserting OIDC backchannel logout and SAML creation defaults are applied when creating minimal clients via v2.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| rest/admin-v2/services/src/main/java/org/keycloak/services/client/DefaultClientService.java | Apply protocol factory defaults during v2 client creation (with SAML omission-preservation for primitive-backed fields). |
| rest/admin-v2/tests/src/test/java/org/keycloak/tests/admin/client/v2/InteropTest.java | Add minimal OIDC/SAML creation interop tests to validate protocol defaults are applied. |
|
Thank you for the PR, the other thing still missing is |
I'll look into it |
Unreported flaky test detectedIf the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.forms.BruteForceTest#testExceedMaxTemporaryLockouts |
|
Addressed the remaining client-type creation path and follow-up review findings in 2f77c90. Admin API v2 now preserves omitted client-type defaults, applies explicit values through type validation, restores ordinary service-account flow handling, and exposes the requested type to client policy contexts. |
2f77c90 to
2c7d27a
Compare
the flaky test is not caused by this PR |
michalvavrik
left a comment
There was a problem hiding this comment.
Thank you for your PR.
I suspect Copilot comments regarding NPEs (this one #50801 (comment)) and PATCH/PUT with explicit null on typed clients (this one #50801 (comment)) are right. The fact that PR CI is not failing means there is gap in test coverage.
Please have a look if there is something on it.
There was a problem hiding this comment.
LGTM, thank you @arnabnandy7
edit - removed the approval due to the failing test. Looking into that now.
|
That PR CI failure is suspicious, I haven't checked yet (I can do it later), but did you investigate @arnabnandy7 if it is related or flaky? |
Not related to my changes. |
Unfortunately it is related to the changes here. The OIDCLoginProtocolFactory will generate a secret for all non-public clients. However the v2 logic expects that to happen only if specific auth methods are used. To keep that convention, either the generated secret will need cleared prior to the v2 logic setting a generated one, or we'll need to only conditionally call setupClientDefaults for non-OIDC clients and make sure that any needed defaulting logic from OIDCLoginProtocolFactory is forked. |
Sorry I was travelling so I thought it was referred to previous CI failure. As I can see the issue will add a fix to make |
Signed-off-by: Arnab Nandy <arnab_nandy7@yahoo.com>
|
@shawkins @michalvavrik your review is required |
Signed-off-by: Arnab Nandy <arnab_nandy7@yahoo.com>
shawkins
left a comment
There was a problem hiding this comment.
LGTM, thanks @arnabnandy7
Let's get another @keycloak/cloud-native review, and then this can be merged.
| && oidcClient.getAuth() != null | ||
| && !isClientSecret(oidcClient.getAuth().getMethod()) | ||
| && isBlank(oidcClient.getAuth().getSecret())) { | ||
| // OIDCLoginProtocolFactory generates a secret for every confidential client, while Admin API v2 |
There was a problem hiding this comment.
but you do this even when factory == null, how should I understand this comment then?
There was a problem hiding this comment.
I'm ok with leaving it as is, but it's certainly fine to move this block into the preceding if (factory != null) block.
There was a problem hiding this comment.
Yeah, not a bug, I I wasn't certain that it can't have side effects which brought me to reading the comment. At least the comment is wrong, but I am fine with it as is.
Apply protocol defaults when creating clients through Admin API v2
Reuse LoginProtocolFactory client defaults in the Admin API v2 creation path. Preserve omitted SAML fields and add interoperability coverage for OIDC backchannel logout and SAML creation defaults.
Closes #50798
Splits from #50894