Support certificate role mappings

[sberyozkin]

Fixes #23683.

Tests to follow, also I thought I could avoid registering an augmentor and just pass the roles directly to the default X509 identity provider.

If these mappings are not comping from the file/classpath resource then a custom SecurityIdentityAugmentor will help.

I'll open for review later but early feedback is welcome

[sberyozkin]

I wanted to modify integration-tests/vertx-http but it is the only test which tests a truststore alias option which I thought was important to retain while for this PR tests the whole truststore should be trusted to test the client certificates with different mappings

[michalvavrik]

LGTM, few notes, two important, others you can ignore

[sberyozkin]

Thanks @michalvavrik, let me deal with the comments, all of them make sense

[Ladicek]

I'm sure someone will come in the future asking to use a different certificate attribute :-), but CN seems good enough for a start.

[dmlloyd]

LGTM, for what that's worth, except for one problem around loading the properties file.

(In case anyone is wondering: I reviewed this code mainly because I was curious having tinkered with this kind of thing a bit back in my days contributing to the WildFly Elytron project.)

[sberyozkin]

Thanks @dmlloyd, your feedback is very welcome

[sberyozkin]

@dmlloyd Hi David, I think I've addressed your comments, which was easy since your typed how to address them :-), if there is anything else that you'd like to change, let me know please

[quarkus-bot]

✔️ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

[sberyozkin]

Thanks @dmlloyd @michalvavrik and @Ladicek for the reviews. Let me merge and as always, things can be improved/optimized going forward

[cescoffier]

@sberyozkin Just made aware of this. Why didn't you reuse the mechanism defined in https://datatracker.ietf.org/doc/html/rfc5755#section-4.4.5 instead of using a custom attribute (which lead to interoperability issue)

[cescoffier]

At least it should be X-Roles (or a valid syntax).

[sberyozkin]

@cescoffier Sorry, I have missed it.

Why didn't you reuse the mechanism defined in https://datatracker.ietf.org/doc/html/rfc5755#section-4.4.5 instead of using a custom attribute (which lead to interoperability issue)

We don't expect here CName to contain any roles, the requirement this PR addresses is only about using Cname as a key to pick up the deployment specific roles from the local file.

As far as expecting the certificate already have the roles, in the X-Roles attribute, please open an enhancement request if you'd like, interesting idea, it won't be in conflict with this PR

[cescoffier]

Shouldn't it use SAN and not the CN? Like for SNI.

[sberyozkin]

@cescoffier This PR addresses a specific requirement, use CName as a map key.

But sure, we can make the attribute name configurable, sounds good to me.