HTTP Security Policy should support the role mappings

[sberyozkin]

Description
@michalszynkiewicz has discovered that Quarkus MP-JWT TCK does not run RolesAllowedTest.testNeesGroup1Mapping because it is part of the optional ee-security test group, but in fact it does not depend on the container supporting EE-Security, all it tests is that a container is able to map a role set in the token to the role listed in @RolesAllowed.

For example, given this token's groups claim and a role mapping configuration like this one (as used in Thorntail), this @RolesAllowed restriction should work.

This can be useful when the role names used by OIDC IDP admins are different to those used in the actual endpoints.

Implementation ideas
Update Quarkus HTTP security policy mechanism to let users map the token specific roles to the container specific roles:
role1=mappedrole1,mappedrole2 or role1=mappedrole1

Alternatively we can update both quarkus-smallrye-jwt (or smallrye-jwt itself) and quarkus-oidc to map, but it appears it would be better to map after the roles have been extracted in either of those extensions

[sberyozkin]

Hi @stuartwdouglas What do you think about this one ?

[sberyozkin]

If the token contain some role names, the way they've been set up in Keycloak Admin console, etc, then it can be useful to map them to the deployment specific roles, ex, admin -> Administrator, etc, especially if the role in the token does represent a real group, say admins which we would map to admins=Admin,SuperAdmin.

[stuartwdouglas]

We can do this using a SecurityIdentityAugmentor, which gives complete freedom in mapping as you do it programatically. I don't know if we want a config based option or not.

[sberyozkin]

@michalvavrik FYI, if you are interested, please have a look, I agree with Stuart an augmentor can help, but having an option to configure the mappings can be useful too