feat(#1737): Add OAuth2 JWT authentication support via JAAS LoginModule

[jbonofre]

Add OAuth2LoginModule to activemq-jaas that validates JWT access tokens using JWKS endpoint for signature verification.

Clients pass the JWT as the password field, and claims are mapped to UserPrincipal/GroupPrincipal for seamless integration with the existing JaasAuthenticationPlugin.

[jbonofre]

NB: this is a better approach imho to what I did initially in #1035 (with the same goal).

[jbonofre]

The test failure is related to #1741

[jeanouii]

Some small details. nothing important

[jeanouii]

LGTM

[mattrpav]

-1 on merging this as part of the activemq-jaas module. This drags in 3rd party dependency to all deployments -- I think this should go into a activemq-jaas-oath2 module.

[mattrpav]

I think this should go into a separate module and get deployed into an extras folder (with the 3rd party) dependency instead of installed into the classpath by default for every running broker.

[jbonofre]

I think this should go into a separate module and get deployed into an extras folder (with the 3rd party) dependency instead of installed into the classpath by default for every running broker.

@mattrpav what is the concern about the Nimbus dependency in the JAAS module ?

At the end, regarding the ActiveMQ distribution, it will be a dependency like another (like Jetty or Rome for instance).

Your concern is about the "embedded" ActiveMQ service in application (BrokerService) ?

[jeanouii]

@mattrpav Using LinkedHashSet is a nice to have but not strictly required per spec. Actually Subject.getPrincipals() returns a Set, that's it. The rest is platform dependant. Our JaasAuthenticationBroker for instance gets all the principals and then iterates until it finds an instance of UserPrincipal.
The other login modules all rely on HashSet, so it is now inconsistent with other ActiveMQ LoginModule.

On the dependency, it will be in the final zip anyways, so until it becomes a problem, I'd prefer to keep in in activemq-jaas instead of creating another module for one class only. It is both simpler for us and for our users that don't have to know they need another module to use oauth2 tokens. We could go like this and if it's a problem split later on.
Jasypt is there as optional as well, so it's similar here. It won't be pulled as transitive dependency.
On the other hand, we have a full independant shiro module. Both are valid, Shiro has much more code, so that's understandable. activemq-jaas-oauth2 definitely makes sense, but it's one class for now so splitting now just makes it harder for us.