]
Darran Lofthouse commented on WFLY-13319:
-----------------------------------------
So for this issue I do now have a test case which matches the scenario you describe,
presently the MicroProfile JWT integration will result in a virtual security domain being
activated for the complete deployment but we are not presently activating the correct
security interceptors for the EJB deployments to correctly handle the @RolesAllowed
authorization checks so I have converted this to a feature request to add that support.
Wildfly 19 MP-JWT & EJB Integration
-----------------------------------
Key: WFLY-13319
URL:
https://issues.redhat.com/browse/WFLY-13319
Project: WildFly
Issue Type: Feature Request
Components: MP JWT, Test Suite
Affects Versions: 19.0.0.Final
Reporter: Radu Cimpean
Assignee: Darran Lofthouse
Priority: Major
Fix For: 20.0.0.Beta1
Attachments: server-cli.txt, web.xml
===Previous configuration & situation===
As written
https://groups.google.com/forum/#!topic/wildfly/L1BxATschCU,
We were running wildfly 18 and used jwt for securing the application. We did this via a
series of cli commands (see server-cli.txt) to configure the server, as well as
referencing the created domains in the web.xml.
Under jboss-web.xml we are referencing the "ejb-domain" created in the CLIs.
The web.xml (see attachments) protects the resource wit the role referenced in the CLIs
(role present in the token)
All our jax-rs resources are annotated with @Stateless and are calling EJBs which in turn
are @Statless and declare allowed roles.
===Current situation===
We've upgraded to wildfly 19 in hopes of using microprofile jwt. To do this,
we've annotated the Application class with
@LoginConfig(authMethod = "MP-JWT", realmName = "MP-JWT-REALM"),
removed the login-config from the web.xml, and removed the security-domain from
jboss-web.xml (since otherwise I would receive an error: ELY01148: A SecurityDomain has
already been associated with the specified ClassLoader").
After also removing the security-constraint tag from the web.xml I was able to get to the
resource and noticed that the JWTToken was properly injected (all claims and entries are
there), and the SecurityContext injected in the resource also contained the jwt specific
values. From what I can tell, in the context of the jax-rs classloader, I am
authenticated.
I would, however, always receive a "Invocation on method... is not allowed" the
second the resource would try calling a bean, even if the role matched. Upon checking the
logs, and what the injected SessionContext contained, I noticed the principal was
anonymous and had no roles allowed.
I therefore believe that the credentials are somehow not being properly passed.
Is there a documented way of properly integrating jax-rs&ejb with microprofile jwt?