coheigea opened a new pull request, #3531:
URL: https://github.com/apache/cxf/pull/3531
Two problems in JwsUtils.loadSignatureVerifier when
rs.security.keystore.type is "jwk":
1. An incoming JWS with an x5c, x5t or x5t#S256 header caused CXF to try
to load a Java KeyStore of type "jwk" to resolve the certificate,
which fails ("jwk KeyStore not available"). Tokens from Microsoft
Entra ID, which carry x5t, could therefore never be verified. These
headers are now ignored for a jwk key store and the verification key
is loaded from the configured JWK set.
2. The kid from the JWS header was only used to select a key from the
JWK set if rs.security.accept.public.key was enabled, a flag that
also allows a JWK embedded in the token to be trusted. Without it, a
key set holding several keys, such as an identity provider's JWKS,
could not be used, and keys could not be rotated.
When no rs.security.keystore.alias is configured, the kid now selects
the key from the JWK set, provided the key is explicitly marked for
signatures ("use": "sig", or key_ops containing "verify"). Otherwise
the previous behaviour applies:
- a configured alias still pins the verification key;
- with accept.public.key enabled, the kid selects any key as before;
- a kid that does not select a key falls back as before.
To follow an identity provider's key rotation, configure a jwk key
store pointing at its JWKS URL and no alias. Note that a valid
signature from a shared JWKS does not mean the token was issued for
this service: claims such as iss and aud must still be validated.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
