All, I'm digging through the test failures in the MP JWT TCK and one of them is a test verifying support for downloading the keys for verifying JWTs via an http call.
The trick is the test is deploying an application that makes an HTTP request to itself to get the public key and expects that to work. Since we validate the configuration before the application is started, this does not work -- the application can't call itself to make an HTTP request because it hasn't been deployed yet. Chicken and egg. I personally think it's not valid and that we should be allowed to eagerly verify the configuration before we start the app, but I can see an argument to having code that can re-check the key server for updates, which is something you'd need to do at runtime. So, as long as we issue a big warning that the http server cannot be reached and authentications will fail until it becomes available, I can be convinced to implement something that checks for keys at runtime. This would require reworking our code quite a bit. Currently, we have a JWTAuthConfiguration object which we allow users to supply via CDI. If one isn't supplied we'll use their microprofile-config.properties. We would not easily be able to implement runtime/dynamic resolution of keys without impacting JWTAuthConfiguration, which is user facing. Personally, I'd be happy to eliminate support for JWTAuthConfiguration as a stable, user-facing, API. We only created JWTAuthConfiguration because MP JWT 1.0 didn't have a standard configuration mechanism yet. Now it does and it's getting more robust every specification version. Having JWTAuthConfiguration exposed to users basically exposes our guts and inhibits our ability to change them. It's really better to have users relying on microprofile-config.properties. What do you think about: - Supporting runtime/dynamic key resolution - Eliminating JWTAuthConfiguration in TomEE 9.0 before it goes final -David
smime.p7s
Description: S/MIME cryptographic signature
