-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Client cert lookup provider compliant to RFC 9440 #36161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Client cert lookup provider compliant to RFC 9440 #36161
Conversation
|
Hoping this gets implemented soon. Cloudflare can forward a client certificate in DER format only which causes the request to fail on client certificate lookup. |
services/src/main/java/org/keycloak/services/x509/Rfc9440ClientCertificateLookup.java
Show resolved
Hide resolved
|
@shawkins @vmuzikar Removing myself as an assignee. Discussed with Stian earlier, that this PR is likely more in the area of cloud-native. Just pointing, that if we add this, it maybe makes sense to wrap this behind feature flag? See |
db1b231 to
d3630b1
Compare
I wasn't aware of this factory because non of the existing X509 cert lookup providers used it. I assume you suggest to use feature flags for all lookup providers and not just the one that I am proposing here, right? If so: Should this be part of my merge request or another merge request, which's main purpose is introducing feature flags for the lookup providers? |
services/src/main/java/org/keycloak/services/x509/Rfc9440ClientCertificateLookupFactory.java
Outdated
Show resolved
Hide resolved
|
@seiferma sorry for the delay in having more consideration of this pr. My only real concern was addressed.
I don't think we need to have this behind a feature flag. Usage will already be opt-in. In general there's also #33159 and #33818 - there should be more follow-up about making the x509cert-lookup SPI public cc @mposolda |
d3630b1 to
d83e4b0
Compare
d83e4b0 to
8032d3d
Compare
No worries @shawkins . I rebased my branch and removed the null check that you mentioned. If there should be more changes, just let me know.
That would be nice. My temporary solution was to build the provider separately and integrate it into my keycloak docker image. The warning about using a non-public API sounded pretty dramatic but if the API is fairly stable, it might be worth to remove that restriction. |
8032d3d to
e31b936
Compare
e31b936 to
6be997c
Compare
vmuzikar
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shawkins
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks again @seiferma
Signed-off-by: Stephan Seifermann <[email protected]>
Signed-off-by: Václav Muzikář <[email protected]>
Signed-off-by: Václav Muzikář <[email protected]>
3abc5cf to
a9df284
Compare
|
I took the liberty of fixing spotless and rebasing again to make the Operator tests pass. |
|
Failing external docs tests are unrelated. |
Closes #20761
This pull request addresses the issue brought up in #20761. I decided to build a certificate lookup provider that is compliant to RFC 9440 instead of just building a caddy-compliant provider. This is the solution that has been suggested in the issue.
Design decisions / implementation details:
Checklist from the contribution guidelines: