Skip to content

Conversation

@shawkins
Copy link
Contributor

@shawkins shawkins commented Dec 18, 2025

Rationale for this change:

  • the api has been stable for years
  • we have several examples of users creating their own cert providers, but that is not considered supported and they see warnings about this being an internal api.
  • external contribution of new providers seems to take a long time Client cert lookup provider compliant to RFC 9440 #36161

On timing, this is optional for 26.5.

closes: #33818

@shawkins shawkins marked this pull request as ready for review December 18, 2025 16:53
@shawkins shawkins requested a review from a team as a code owner December 18, 2025 16:53
@shawkins shawkins requested a review from a team as a code owner December 18, 2025 17:53
@shawkins
Copy link
Contributor Author

shawkins commented Dec 18, 2025

There appears to be an unrelated CRDTest expectation change - which doesn't seem to occur for me locally. If needed that can be separated to a different pr.

EDIT: moved the other commit to its own pr.

Copy link

@keycloak-github-bot keycloak-github-bot bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unreported flaky test detected, please review

@keycloak-github-bot
Copy link

Unreported flaky test detected

If 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.webauthn.passwordless.PasskeysKcOidcFirstBrokerLoginTest#testLinkAccountByReauthenticationWithDiscoverablePasskey

Keycloak CI - WebAuthn IT

java.lang.AssertionError: Expected LogoutConfirmPage but was localhost (https://localhost:8543/auth/realms/consumer/protocol/openid-connect/logout)
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.assertTrue(Assert.java:42)
	at org.keycloak.testsuite.pages.AbstractPage.assertCurrent(AbstractPage.java:39)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
...

Report flaky test

Copy link
Contributor

@vmuzikar vmuzikar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would probably need some docs to officially consider it supported.

@shawkins
Copy link
Contributor Author

We would probably need some docs to officially consider it supported.

That seemed optional as there appear to be quite a few non-internal spis not covered by https://www.keycloak.org/docs/latest/server_development/index.html

Or is there another place where this should be documented?

@vmuzikar
Copy link
Contributor

That seemed optional as there appear to be quite a few non-internal spis not covered by https://www.keycloak.org/docs/latest/server_development/index.html

AFAIU, those not mentioned in the docs are not officially supported.

Or is there another place where this should be documented?

No, this would be it.

I think we have some grey area though. We have public SPIs, yet we don't document them, and hence don't support them. I do not know then why we even mark SPIs as public.

Adding a new supported SPI is a bigger step and would require broader team involvement, IMHO. We could potentially just mark the cert lookup SPI as public and not mention it in the release notes not to give any implication it's supported. Not sure if that makes much difference though from a private SPI.

CC @stianst

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Request for Enhancement: Make x509cert-lookup SPI public

2 participants