Support CDI providers of key/trust stores in TLS registry

[emattheis]

Per discussion #41024, this PR provides a mechanism for application code to supply keystores or truststores to the TLS registry.

[quarkus-bot]

Thanks for your pull request!

Your pull request does not follow our editorial rules. Could you have a look?

• description should not be empty, describe your intent or provide links to the issues this PR is fixing (using Fixes #NNNNN) or changelogs

_{This message is automatically generated by a bot.}

[cescoffier]

Very nice!

I made a few comment and I added a question for @mkouba

[cescoffier]

A bit of javadoc would be nice

[cescoffier]

A bit of javadoc would be nice

[cescoffier]

I forgot to mention that this deserves a small section in the TLS registry documentation.

[github-actions]

🎊 PR Preview 83338cf has been successfully built and deployed to https://quarkus-pr-main-45937-preview.surge.sh/version/main/guides/

• Images of blog posts older than 3 months are not available.
• Newsletters older than 3 months are not available.

[michalvavrik]

I think this method (that is called twice) can be completely replaced with. Also this way, you can drop changes in TlsBucketConfig.

// alpn == true by default, but we need to set some property to let SR Config that we need a bucket with such name, maybe Roberto knows a better way
`new RunTimeConfigurationDefaultBuildItem("quarkus.tls.collected-identifier.alpn", "true")`

I didn't try it, I just think that's how this should work. Just tell config "I need these keys if user didn't configure them". Of course, there is even better way, I think you can use https://smallrye.io/smallrye-config/Main/config/mappings/, you collect all the identifiers during the build-time and then you create var namedConfigs = new HashMap<>(config.namedCertificateConfig()); as you already do and iterate over identifiers collected at the build-time and do config.namedCertificateConfig().get("identifier-abz") and you don't care whether it is user config or defaults, because it will always return config for your identifiers.

But then maybe, @cescoffier don't want this in config 🤷 , I don't really know what is preferable for this extension.

[michalvavrik]

I mean @WithDefaults of the config mapping if it wasn't clear.

[emattheis]

@michalvavrik I think I understand what you mean, but I'm a bit unclear how to proceed. It would definitely be better to simply merge the @Identifier values into the config at build time.

I think I would need a build step that can take the bean discovery and config state as input. Then I can find all the providers with annotations and collect the values. Then I need to put any missing names into the namedCertificateConfig map with default values.

If you can give me a bit more guidance, I'll be happy to do it 🙏

[michalvavrik]

I can't really decide if this should be done in this extension. Nevertheless, I can give you guidance, this is just a metacode, you will need to figure details like everyone else. What I usually do is to simply look for usage of a class/method and "get inspired".

1. in initializeCertificate inject CombinedIndexBuildItem, get Identifier annotation instances from index, filter them by annotation target where it implements KeyStoreProvider or TrustStoreProvider and collect identifier annotation instance values. I suppose you can stick to Set<String>
2. pass it down to the io.quarkus.tls.runtime.CertificateRecorder#validateCertificates
3. add @WithDefaults top Map<String, TlsBucketConfig> namedCertificateConfig()
4. create your final named configs like:

Set<String> identifiers; // method param
        var namedConfigs = new HashMap<>(config.namedCertificateConfig());
        for (String identifier : identifiers) {
            if (!namedConfigs.containsKey(identifier)) {
                namedConfigs.put(identifier, config.namedCertificateConfig().get(identifier));
            }
        }

Shout if you get stuck.

[emattheis]

I mean @WithDefaults of the config mapping if it wasn't clear.

So if I add @WithDefaults to TlsConfig::namedCertificateConfig I should be able to get a default for any unconfigured key?

[michalvavrik]

I mean @WithDefaults of the config mapping if it wasn't clear.

So if I add @WithDefaults to TlsConfig::namedCertificateConfig I should be able to get a default for any unconfigured key?

yep; I supposed unasked question is what about unavailable beans, because this would create default config for these, no idea if that is an issue, I'd rather say no...