MicroProfile JWT 1.1 Support

[ ] Engineering

[ x ] QE

The primary integration will be happening by the addition of a new subsystem microprofile-jwt-smallrye within WildFly.

Additional integration will be added within WildFly Elytron to bridge into the application server’s security framework. This additional integration is specifically to achieve the delivery of support for MicroProfile JWT 1.1, potential new functionality that we identify would be picked up in future enhancements.

The integration will also be making use of SmallRye JWT as well as pulling in the Eclipse MicroProfile JWT API library.

This enhancement is focused on adding support for the MicroProfile JWT 1.1 specification within WildFly. During development additional opportunities may be identified to provide additional functionality, any such opportunities will be tracked within the WFLY Jira project and reviewed at the end of this enhancement rather than allowing the scope of this enhancement to grow.

Primarily this enhancement will be delivered using a new subsystem microprofile-jwt-smallrye which will be added to WildFly. The subsystem will install a DeploymentUnitProcessor which will detect if MicroProfile JWT is required and activate a suitable security configuration as described within this proposal.

The new subsystem initially will contain no configuration, it’s presence alone will enable support for MicroProfile JWT.

Additionally the initial version of this subsystem will expose no operations and no attributes.

The default location to specify the authentication requirements is within the web.xml deployment descriptor, the MicroProfile JWT specification add a new annotation @org.eclipse.microprofile.auth.LoginConfig which allows a JAX-RS javax.ws.rs.core.Application to be annotated to specify the desired auth-method and realm-name.

During deployment, deployments will be scanned for a class extending Application annotated with the new @LoginConfig annotation - if the authentication configuration was not previously specified within the web.xml the configuration from this annotation will be used instead. If the authentication configuration has already been specified in the web.xml annotation scanning will be skipped as the configuration in the web.xml takes precendence over the annotation.

After the previous steps have completed if the resulting auth-method for the web application being deployed is MP-JWT the MicroProfile JWT integration will be activated as described further within this document, in all other cases no activation will occur and the deployment will continue using the existing security capabilities provided by the application server.

The following steps will NOT occur if MicroProfile JWT has not been activated as described previously.

At the point activation occurs the deployment will not make use of a configured SecurityDomain instead a "Virtual" SecurityDomain will be created to meet the requirements of the deployment.

It is also possible that MicroProfile JWT is activated for a deployment that it itself a sub-deployment such as a war contained within an ear or in cases where the war contains items to be deployed in another container such as EJBs within the war. In all of these cases the common "Virtual" SecurityDomain will be used across all containers handling the deployment - by using a common SecurityDomain any identity established in one container will automatically propagate with any calls to the other containers without the need for any manual configuration.

Activation will add module dependencies as required on SmallRye JWT, Elytron JWT, and the MicroProfile JWT API.

Activation will also ensure activation of the SmallRye JWT CDI extension as well as the Elytron JWT CDI extension for Elytron specific overrides.

Finally activation will ensure the activation of the MP-JWT authentication mechanism for the deployment.

The combination of SmallRye JWT with Elytron JWT will be the pair of projects responsible for providing the functionality described in the MicroProfile JWT specification combined with tying in the integration to the application server’s security framework to ensure aspects such as identity association and establishment are correctly performed.

Once an identity has been established according to the steps described by the MicroProfile JWT specification the remaining security decisions required are covered by the relevant Jakarta EE specifications in use by the various subsystems.

This section is deliberately empty, the intent of this enhancement is to integrate MicroProfile JWT support to WildFly. Once the initial integration is in place nice to have functionality can be added under individual enhancements with an appropriately constrained scope.

This integration will be making use of WildFly Elytron exclusively, no support will be added for the deprecated PicketBox project. Having said that the underlying security framework will be transparent for deployments developed according to the specification - the framework only becomes apparent if there is a desire to use vendor specific APIs.

This integration will not be supporting the use of pre-configured SecurityDomains, the general motivation to use MicroProfile JWT is to use an authentication mechanism where identities are self described using the tokens exchanged eliminating the need for configured security resources for the secured endpoint(s). Use cases could be identified where pre-configured resources add an additional benefit but those would be reviewed under their own enhancements.

It is assumed when working with the MicroProfile specifications that we will be supporting a single deployment, this deployment may contain sub-deployments. The SecurityDomain of each top level deployment will be isolated from the SecurityDomain of any parallel top level deployment. Advanced WildFly Elytron features such identity propagation across domains / top level deployments will not be supported. At a later point we could consider an enhancement to offer more control of the SecurityDomains in use but that is out of scope for this enhancement.

For this initial implementation propagation of identities is outside the current scope. The specification does make provision to access the token passed to the server so deployments can manually retrieve a token. Under WFLY-11868 enhancements are being provided to make use of the WildFly Elytron authentication client in RESTEasy, once available under a new RFE the microprofile-jwt subsystem can dynamically configure an AuthenticationContext configuration to automate propagation. This could also introduce a new feature to the client to allow a feature to convert it’s current configuration to obtain an alternative token.

It is assumed that any deployment making use of MicroProfile JWT will have already activated CDI, this enhancement will not activate CDI if the deployment has not already activated it.