Java21+Spring6 upgrade, Keycloak removal

[ngeorges-cnrs]

This pull request updates and replaces #496, which basically had VIP-portal building with Java21, but not running in a usable way.

In the present PR :

• Login/password authentication works and the UI is usable.
• API key and EGI authentication both work, and have been upgraded to Spring Security 6.3 API.
• Keycloak API authentication has been temporarily disabled, with the org.keycloak connector fully removed, as it was incompatible with Spring6. It will be replaced by an equivalent OIDC Spring connector in a separate patch.

Known limitations :

• There are still around 20 build warnings (not related to Spring Security)
• The menus icons on the homepage have an abnormal size (probably something in gwt related to the upgrade)
• Overall, things haven't been thoroughly tested in accordance with the magnitude of the java11/java21 change

These limitations along with the Keycloak connector removal make the patch usable for development/testing, but obviously not for production yet. Also do note that Tomcat must be upgraded to v10 or v11 in order to support jakarta.

[axlbonnet]

Thanks for the work.
Seems good globally.
We need to review the way GWT is imported.
Also, the tests are failing on github because it is still configured with java11, we need to update the workflow definition with the new one @ethaaalpha did. Do they run locally ?

[ngeorges-cnrs]

Summary of today's changes :

• CI goes further, but there are still 3 failing tests in vip-api (see conversation on jakarta.validation)
• The apache-fileupload update and related dependencies changes might indeed deserve extra review / testing

Known limitations listed in the first comment all remain, and ongoing conversations have to be sorted out with @axlbonnet.

[ngeorges-cnrs]

Last two updates :

• ngeorges-cnrs@f0e2410 : fix maven CI (woo-hoo)
• ngeorges-cnrs@bdc6c86 : fix icon sizes

Remaining issues :

• Restore Keycloak API authentication support with Spring Security 6
• Maybe solve build warnings

[axlbonnet]

Excellent.
We'll see about the keycloak support and this will be ready to be merged.

[ngeorges-cnrs]

ngeorges-cnrs@7970495 : restore Keycloak support, ready for review and candidate to merge.

Notes for the review :

• This SpringSecurity 6 implementation should be fully backwards-compatible with the previous Keycloak connector one : same config file, same network requests, etc.
• There is normally only one visible and intentional change, a bugfix : locked user accounts were not checked by previous version when using OIDC bearer tokens, they now are correctly denied.
• Keycloak-specific mapping of JWT claims into roles is now explicit in OidcResolver.parseAuthorities, this was previously done by the Keycloak connector implementation. Same thing for keycloak.json file parsing.
• Preparing support for multiple OIDC servers, while also caching the authenticated principal to avoid multiple getVipUser() DB lookups per request, as well as mapping JWT claims, requires some extensive configuration compared to the simpler cases in SpringSecurity docs. This is done in OidcResolver.getAuthenticationManagerResolver and its dependencies. This is a bit verbose, but still the most concise way I've found so far.

[ngeorges-cnrs]

During some extra testing today, I found an issue with Keycloak support in the present PR, which has to do with how JWT claims get mapped to authorities ("roles") : the current PR assumed that roles were extracted from the resource_access.<resource>.roles JWT field, where <resource> is the string defined in keycloak.json. But this was an incorrect assumption : actual tests on role-restricted endpoints with VIP-portal 2.7 show that authorities are in fact extracted from realm_access.roles.

This means that the resource name in keycloak.json is probably useless : I'll do some review of the existing Keycloak connector code to confirm that, if I can find it. And we can then decide whether to drop that configuration field.
The resulting patch should be relatively simple.

Edit: Keycloak adapter behaviour is confirmed (we were using 15.0.1) :

• https://github.com/keycloak/keycloak/blob/15.0.1/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/AdapterUtils.java#L39 : roles are obtained from realm_access unless use-resource-role-mappings is set in keycloak.json
• https://github.com/keycloak/keycloak/blob/15.0.1/core/src/main/java/org/keycloak/representations/adapters/config/BaseAdapterConfig.java#L41 use-resource-role-mappings defaults to null, and we do not seem to use it in prod

So depending on current and planned prod usage, we can either remove support for resource roles entirely, or keep a similar configuration possibility with a boolean flag + resource name.

[ngeorges-cnrs]

ngeorges-cnrs@79e825c : adjusted how roles are parsed from JWT to exactly match previous implementation (cf previous comment).

As seen with Axel, use-resource-role-mappings is currently unused in prod, so the resource parameter is effectively unused as well. As this was simple to implement, I've kept optional support for both realm roles (default) and resource roles (if use-resource-role-mappings + resource fields are set).

All tests done on my side, so this PR is finally ready for review and merge.

[axlbonnet]

Excellent and elegant work.
I just have short remarks mainly about exception handling.

[camarasu]

Excellent work @ngeorges-cnrs!
I'm OK with merging the PR after taking into account Axel's suggestions.

[ngeorges-cnrs]

All comments above were addressed in today's commits :

• ngeorges-cnrs@d8adb42 for exceptions handling. See commit message for what changed. Most of the diff is just reindentation because of try/catch blocks removal.
• ngeorges-cnrs@702d30e for the rest. For the record, the code snippet with MvcRequestMatcher mentionned here does work, but it's indeed not shorter than antMatcher() so I've kept the latter.

Hopefully everything is now ready for merging.

[axlbonnet]

Great work, thanks @ngeorges-cnrs