Servlet 3.0 is awesome, so is CDI. They work well and are a joy to set up. Even adding the Vaadin Navigator to the mix isn’t an issue, since you can use the CDIViewProvider to maintain the injection chains. Everything works nicely with annotations, and you don’t need to mess around with nasty XML. But what if you want to use JAAS? Recently, I stumbled upon a small dilemma in a customer project where the customer wanted to use JAAS in combination with CDI. How in the world was I going to combine the two?
To get us all to the same page before we start; here is a very short introduction to JAAS. JAAS, or the Java Authentication and Authorization Service, has been around for a while. It is an API for Java to manage user authentication and request authorization, with a multitude of connectors to other technologies and pre-made helpers. In this post I’m going to show you how to integrate the authentication part into your Vaadin application, using the Vaadin CDI plugin and JBoss 7.1. The blog post is a summary of my Wiki article. It contains complete source code and a more thorough explanation on the different parts.
So, how do we really make this work?
There are a couple of ways we can configure the Servlet to have both JAAS and CDI capability; both involve the actual mappings of the Servlet. If you map your Servlet in your web.xml, you can use CDI by using the CDIUIProvider utility class. It scans the classpath for @CDIUI annotations and deploys the classes automatically. If you’re not using web.xml, you can define the same thing in your servlet by injecting the provider and adding it to the session. In my example, I just use the pre-made servlet definition included in the CDI addon. It is preconfigured to use the CDIUIProvider, so I just create the necessary UIs and annotate them, and I’m good to go, like this:
@CDIUI("secure")
public class SecureUI extends UI
That’s how you get CDI to work, what about JAAS? Well, we can restrict the user in two ways; web.xml-based security constraints, or restricting the access to mapped Navigator Views using the @RolesAllowed annotation. Since we aren’t using the Navigator, we need to use the web.xml file approach. If you already have the file, then you just add the security constraints. If not, you need to create a web.xml file under your WEB-INF folder. You don’t need to add any servlet definitions; you only need to work with URL mappings. With JAAS, you define which URLs are off-limits to normal users. If you have a Servlet deployed there or not is actually moot; JAAS only controls access to that URL, it doesn’t care what’s there. You also define where the login-page exists with another URL.
In my example I, have a secure area of my application mapped to /secure, an unsecure area mapped to the root (/), and a login page on /login. I tell JAAS that /secure is a secure zone: users must log in to access it. If a user isn’t logged in, they get redirected to a login page. In our case it is /login. The user logs in, and the server grants access to /secure. Fragment below:
<login-config>
<auth-method>FORM</auth-method>
<realm-name>ApplicationRealm</realm-name>
<form-login-config>
<form-login-page>/login</form-login-page>
<form-error-page>/login</form-error-page>
</form-login-config>
</login-config>
How you actually log in the user is completely up to you. In my example I use a Vaadin UI with a relational database to store user info, and have JBoss fetch the user data with SQL. You could also set up Active Directory, LDAP, a simple file-based system. You could use existing JSP (or even plain HTML) for the actual login UI. There are lots of tutorials for the different solutions, so I won’t cover them here. Check the wiki article for detailed information about the database method, including all source code and JBoss configs.
Now that you have JAAS enabled, what benefits do you get? Well, a lot actually. With JAAS, you get access to a properly defined authentication and authorization framework, that is built into all application servers. You can easily separate your security concerns into a separate, maintainable module. With CDI and EJBs, you can use standard-based security protocols for bean access. If you are using the Vaadin Navigator, you can even define access control restrictions on your Views with the @RolesAllowed annotation found in JAAS. Most importantly, using JAAS lets you concentrate on your application instead of the security for it.
That’s it, your app will now use JAAS authentication and CDI. The configuration provided in the wiki article isn’t complete, and there are small pieces I didn’t really cover, but it will work for basic cases. From here, you can add authorization for your particular application. Anything I missed? Anyone used JAAS with CDI, and want to share your thoughts? Feel free to add comments below.
Thomas Mattsson works at Vaadin as a Vaadin Expert and Project Manager. He has been designing and implementing Vaadin application architectures for over 5 years. When he isn’t designing, he runs around Europe doing Vaadin trainings and consulting gigs. You might also catch him on the Vaadin Forum.