By Andy Overton
In this blog post I will provide a brief introduction to JASPIC and then take a walk through setting up a basic demo using JASPIC to secure a simple web application in GlassFish.
What is JASPIC?
JASPIC stands forJava Authentication Service Provider Interface for Containers. The original JSR for JASPIC was created back in 2002 but it wasn’t completed until 2007 and wasn’t included in Java EE until Java EE 6 back in 2009.
JSR 196 defines a standard service-provider interface (SPI) and standardises how an authentication module is integrated into a Java EE container.
It is supported by all the popular web containers and is mandatory for the full Java EE 6 profile.
It provides a message processing model and details a number of interaction points on the client and server.
A compatible web container will use the SPI at these points to delegate the corresponding message security processing to a server authentication module (SAM).
Walk-through
I will be using the following software whilst doing this walk-through. If you are using different versions then you may see different results.
Ubuntu 14.04 LTS
Eclipse Luna (with Glassfish Tools – available here – http://marketplace.eclipse.org/content/glassfish-tools-luna
JDK 1.7.0_25
GlassFish 4.1
Creating the Runtime Environment
First of all, we will create a runtime environment so we can run GlassFish from within Eclipse. In order to do so:
In Eclipse go to:
File->New->Other->Server
Select Glassfish 4
Set the JDK
Set the Server directory to <GF_INSTALL_DIR>/glassfish
All other defaults should be OK.
Creating the Web Application
OK. So, next we will create a very basic web-app consisting of a single servlet.
In Eclipse go to:
File -> New -> Dynamic Web Project
Name – JASPICTest
Make sure the Target runtime is GlassFish 4.
Press Next twice to accept the defaults and then select Generate web.xml deployment descriptor on the last page.
Click Finish.
Right-click on your newly created project and select New → Servlet
package – uk.co.c2b2
Class Name – TestServlet
Click Next and Finish.
This will create a basic servlet. Add the following code to the doGet method:
This is very basic but will allow us to see the relevant authentication data being returned by the server.
Testing Your Application
Start your GlassFish server – Right click on your server and click Start. (Note – If you can’t see the Servers tab ensure you have the Java EE perspective open).
To run your servlet right click on TestServlet, select Run As -> Run on Server
Make sure your GlassFish server is selected and hit Finish. Click on Always use this server when running this project to make things simpler in future.
Go to:
http://localhost:8080/JASPICTest/TestServlet
and you should get the following response:
You have accessed TestServlet at /JASPICTest2
You are currently authenticated as: Unknown User
Sorry, you’re not admin. Nothing to see here.
Creating the Server Authentication Module
The Server Authentication Module (SAM) must implement the javax.security.auth.message.module.ServerAuthModule interface as defined by JSR 196. The interface can be found here.
The SAM is invoked indirectly by the message processing runtime at the validateRequest and secureResponse interaction points.
Create a new Java project – TestAuthModule
Right click project, select Build Path-> Configure Build Path->Libraries.
Click Add External JARs
Add the following dependencies:
Both can be found in:
<GF_INSTALL_DIR>/glassfish/modules
These will only be used to compile the code, you don’t need to package them up as the web container will already contain copies.
Right click on your new project and create a new Java class TestAuthModule which implements the interface – javax.security.auth.message.module.ServerAuthModule
For now we won’t add in anything aside from replacing the auto-generated validateRequest method with the following:
Export your new project as a jar file. Right click on the TestAuthModel project, select Export->Java->JarFile.
Remove the classpath and project resources and call the output file TestAuthModule.jar
Export the jar file to <GF_INSTALL_DIR>/glassfish/lib
Restart Glassfish
Configuring the SAM
Next up we need to create a message security provider in GlassFish and then link this to our web app.
Go to the GlassFish admin console:
http://localhost:4848
Go to Configurations->server-config->Security->Message Security
Select HttpServlet
Select the Providers tab. Click New.
Provider ID – TestSAM
Provider Type – server
Class Name – uk.co.c2b2.TestAuthModule
Updating the Web App
In the JASPICTest app, edit glassfish-web.xml
Add the following to indicate that the TestSAM you have just set up should be used for this app:
Testing the Changes
In Eclipse – Right click on TestServlet and select Run As -> Run On Server
You should now see in the Glassfish console output:
INFO: validateRequest called
This shows that Glassfish our SAM is now being used.
Locking Down Resources
OK, so at the moment we have a web app that is linked to our SAM but we haven’t actually said to secure anything and even if we did our SAM simply authenticates anyone!
So, lets implement some (albeit very basic) security.
NOTE – This is only for demo purposes and to show how JASPIC works, it is most definitely not intended to be a way of doing security!.
First of all, let’s lock down our servlet. We want to lock it down to only users with the role admin or standard. To do so, add the following to the application web.xml:
There is one additional (rather ugly) step we need to do to make our app work. In order for GlassFish to accept the roles that our authentication module puts into the JAAS Subject we have to map them to groups.
In order to do so, add the following to glassfish-web.xml:
Next up we will alter our SAM and implement the methods.
Each of the methods is implemented as follows:
initialize – Simply takes the CallBackHandler and instantiates our local handler.
getSupportedMessageTypes – Returns the HTTP servlet request and response types.
secureResponse – Simply returns Success.
cleanSubject – Clears all principals from the Subject.
validateRequest – This is the main method of interest. In order to pass in the user and role I have just added them as servlet request parameters for testing purposes. This method extracts those values and then calls authenticateUser.
authenticateUser – NOTE – This method doesn’t actually do any authentication! It simply takes the user and group, creates callback classes from them and passes them to the callback handler.
Once we have added the above our TestAuthModule looks like this:
Testing
Now all we need to do is test our new module.
First of all build it, jar it up and copy it over to <GF_INSTALL_DIR>/glassfish/lib as before.
Restart Glassfish.
Now we can test by passing in different dummy credentials.
You should see the following:
If you go to:
http://localhost:8080/JASPICTest/TestServlet?user=Andy&group=standard
You should see the “Sorry, you’re not admin. Nothing to see here.” message.
If you go to:
http://localhost:8080/JASPICTest/TestServlet?user=Andy&group=admin
You should see the “As you’re admin you can view this.” message.
And if you go to:
http://localhost:8080/JASPICTest/TestServlet?user=Andy&group=xxx
You should see an HTTP Status 403 – Forbidden message.
Wrapping Up
Hopefully this has given you a taster of how to use JASPIC to secure your applications and you can see how relatively straightforward it is to put the basic building blocks in place.
If you’re looking for an example of a SAM that does authentication then there is one available from Oracle here: http://docs.oracle.com/cd/E19798-01/821-1752/gizeb/index.html
Although JASPIC is yet to take off it’s a good first step towards standardising security in web containers and avoids the need for each to have their own proprietary solution, although there is still the issue of different containers using different deployment descriptors hindering the portability of apps.
Send to Kindle
The post Using JASPIC to Secure a Web Application in GlassFish appeared first on Voxxed.