Plugin works?

[douglasqueirozalmeida]

Any better documentation for using the plugin?
Or has the plugin been deprecated?

[ceharris]

Definitely works. We've been using it in production applications for about two years now.

Sadly not much documentation, but if you're really interested in making use of it I can probably help you get it working and flesh out some additional documentation along the way.

[douglasqueirozalmeida]

I would like to know how the integration with the server works. I was curious to use the solution, but following the README, I was a little confused on how to use it.

I believe that other people can also benefit from the solution.

[ceharris]

Let's start with the super high-level stuff first.

This is a module that plugs into the Wildfly application server using Wildfly's extension mechanism. It gets its configuration from the Wildfly configuration model. Wildfly's configuration model is persistently represented in an XML file (e.g. standalone.xml) and is typically manipulated using the Wildfly management CLI. The README shows some CLI commands that are used to set up a pretty basic configuration for the module, but there are lots of configurable options.

Once the module has been enabled in the server's configuration, it registers itself to observe application deployments. When a web application is deployed (e.g. dropping a .war file into the directory monitored by the server), the module looks for a deployment descriptor (WEB-INF/jwt.xml) whose presence indicates that the web application wants authentication and authorization using JWT. If the descriptor is present in the deployment, the module attaches a "servlet extension" to the deployment. Subsequently, when the web application is initialized, the servlet extension modifies the auth handler chain such that when a resource marked as requiring authorization (e.g. using a <security-constraint> in web.xml) is accessed, the JWT module handles the authorization.

This approach allows you to use all of the standard J2EE declarative mechanisms that require a particular security role to access a given resource in exactly the same way that you would in a web application that uses, for example, BASIC authentication or FORM authentication. The web application itself doesn't need to do anything but declare what role is required to access a given resource. The module takes care of validating a presented JWT bearer token to confirm that it is authentic and contains the claim(s) corresponding to the necessary role(s). The module can use any of Wildfly's supported mechanisms for mapping attributes of a user to application roles; a common simple approach is the use of application-roles.properties.

I'll stop here for now to give you a chance to ask questions to help guide the conversation in the direction that better suits your needs.

[viktarbelski]

Hello @ceharris. I try to extend jwt-webapp-demo with a soap endpoint in the same 'jwt' secutity domain that is declared in jboss-web.xml.

`
@ Stateless
@ RolesAllowed("valid-user")
@ WebService(name="SimpleSoapManager", targetNamespace="http://www.smthgmbh.de/SimpleSoapManager", portName="SimpleSoapManagerSOAP")
@SecurityDomain("jwt")
public class SimpleSoapManagerImpl implements SimpleSoapManager {

@ Inject
private GreetingService greetingService;
...
}
`

Call to this soap endpoint doesn't come into JwtLoginModule as expected. Could you tell me if there is a way to secure soap endpoints in 'jwt' security domain, like it is done for rest and servlets?

[ceharris]

I'm certain that there is a way to make authenticate and authorize SOAP requests using a JAAS login module in a security-domain component (such as the JwtLoginModule). Ultimately SOAP requests come in through HTTP via the undertow subsystem just like any other HTTP request.

When a web application that uses this JWT module is deployed, the module modifies the servlet deployment to replace the the authentication method -- a servlet application typically specifies a login method in web.xml as BASIC, FORM, DIGEST, etc. If you can make your SOAP endpoint work correctly using HTTP Basic authentication, it should be relatively easy to make it work correctly using the JWT module.

To work towards a solution, I would begin by temporarily renaming the JWT deployment descriptor src/main/webapp/WEB-INF/jwt.xml and deploy the demo without it. The demo will then use HTTP Basic authentication which you can verify with a browser. By adding the appropriate Authorization header to your SOAP requests, you should then be able to work through getting the SOAP endpoints to respond successfully. When all that works correctly, you will then be able to assess what (if anything) isn't working when you put the JWT deployment descriptor back into place.

[viktarbelski]

Hi @ceharris and thank you for your answer - it helped me a lot. You were right - placing the jwt deployment descriptor as well as jboss-webservices.xml in src/main/webapp/WEB-INF solved the problem for a web application. Calls to secured SOAP and REST webservices inside the war-deployment go over the JWTLoginModule as expected.

But in case of ear-deployment with the following structure it seems to ignore 'jwt' security domain for everything outside the war:

simple-demo.ear contains:

• exploded simple-web.war with secured servlets, REST endpoints and webapp/WEB-INF/jwt.xml and webapp/WEB-INF/jboss-web.xml
• unexploded simple-ejb.jar with SOAP webservices and as usual META-INF/jboss-webservices.xml

I have tested HTTP Basic authentication with the same ear-deployment structure, and the call comes to SOAP/REST/Servlets over a custom LoginModule. @ceharris do you have any idea, why a call doesn't come to SOAP webservice over JwtLoginModule in case of ear-deployment? Is there a place for jwt.xml descriptor anywhere in simple-ejb.jar?

[ceharris]

I didn't make any provisions for handling EAR deployments in the extension. To understand why this matters (and how EAR deployments might be supported), you'll need to understand a little more about how this extension plays a role in Wildlfly deployment processing.

An extension like this can register one or more deployment processors that get called back by Wildfly each time a deployment occurs. If you look in jwt-subsystem/src/main/java/org/soulwing/jwt/extension/deployment, you'll find the DescriptorDeploymentProcessor and the ServletExtensionDeploymentProcessor. These two work together to determine whether a particular deployment is going to use the JWT extension.

The DescriptorDeploymentProcessor looks in the deployment resources for a file named /WEB-INF/jwt.xml. It doesn't look anywhere else. It doesn't know whether the deployment is a WAR or an EAR (or something else). It simply assumes that if there is a /WEB-INF/jwt.xml and it validates as the JWT deployment descriptor, then the deployment is a web application and wants to use the JWT servlet extension, and it sets up some context (using something called deployment attachments) for use by ServletExtensionDeploymentProcessor later in the deployment process.

When ServletExtensionDeploymentProcessor gets called during a deployment, it checks for an attachment (put there by DescriptorDeploymentProcessor) indicating that it should replace the authentication mechanism used by servlets in that deployment. If the attachment isn't present (meaning there is no JWT descriptor) it does nothing.

For an EAR deployment, the JWT deployment descriptor, if present at all, I think it would be nested inside of the EAR differently. I haven't used EAR deployments much and I really haven't paid much attention to how things get laid out. In theory though, it should be possible to locate the JWT descriptor inside of the EAR and enable the servlet extension accordingly. The place to experiment with this would be inside of DescriptorDeploymentProcessor.

[viktarbelski]

@ceharris thank you very much for your help! I debugged the DescriptorDeploymentProcessor and understood how it works. And let me say, that I'm really impressed with a quality of implementation of your project!