Integrating Wicket with Wicket Auth/Roles and Spring Security

In this tutorial I describe how you can setup Wicket 1.5 to use Spring Security 3.1 for authentication and Wicket Auth/Roles for authorization.

Spring Security is a very complete and flexible solution for all kinds of security needs. It offers a lot of functionality out-of-the-box and it is quite easy to extend to fit your own custom needs. Visit the Spring Security website ( for more information.

Wicket Auth/Roles makes it easy to annotate components with authorization information. E.g., the @AuthorizeInstantiation configures what roles are allowed to instantiate the annotated component or package, and the @AuthorizeAction annotation controls wether the component is rendered or not based on the roles.

At the and of this tutorial you will have a sample Wicket project that uses Spring Security to look up the user – including roles, full name, etc. -, validate the password, and manage the current user session. Wicket Auth/Roles validates whether the current user has access to a particular page, or even a particular component.


  • JDK 7.x
  • Maven 3.x
  • a recent version of the Eclipse IDE for Java EE Developers
  • the m2e – Maven Integration for Eclipse

Please not that during the writing of this tutorial I ran into a bug with Wicket version 1.5.6, which causes the FeedbackPanel to not render messages on stateless pages. See So for now, use version 1.5.5 (or 1.5.7 when it’s released).

Create a new Wicket project

Create a new Maven project from within Eclipse using the wicket-archetype. Press Ctrl+N and select MavenMaven Project. Next, select the maven-archetype-quickstart 1.5.5 and enter your desired Archetype Parameters.

New Wicket project

After clicking Finish your new Wicket project will be generated.

To verify that everything is working correctly, run as a Java application en browse to http://localhost:8080/. You should see something like the following:

Wicket quickstart running

Change the location of the html files

By default Wicket expects the html files to live next to the Java source files, in the same package and also in the src/main/java folder. However, if like me you prefer your html files to be stored inside the src/main/webapp folder you could do one of two things.

If you don’t mind the html files still residing within the same package as the corresponding .java files, the easiest way to change this is to add the following lines to your pom.xml files within the <resources> element:

However, if you also want to strip the Java package structure from the html files you’ll have to implement a custom ResourceStreamLocator that tells Wicket where it should get the html files from. This is especially useful if you want to maintain a deep Java package ordering for your Java source code but want your webapp folder to have a more “natural” structure to it. For example, by default Wicket will try to find the html file for by looking for the file com/example/MyPage.html. With a custom ResourceStreamLocator you can configure Wicket to look for just MyPage.html.

To create a custom ResourceStreamLocator create a new class that extends ResourceStreamLocator and override two methods:

Next, you have to tell Wicket to use your custom ResourceStreamLocator. To do so, edit your Wicket Application class and add the following lines to the init() method:

Spring 3.1 integration


To integrate Spring 3.1.0 with Wicket 1.5.5 you first need to add the dependencies for both frameworks to your pom.xml. Next, to actually make them cooperate you also have to add the wicket-spring dependency:

 Spring code

Create a Spring bean HelloWorldService:

Create a standard Spring applicationContext.xml file under your WEB-INF directory with the annotation scanning enabled:

Integrating Spring with Wicket

Add the following line of code to the init() method in your Wicket Application class:

Edit your web.xml and add a Spring ContextLoaderListener:

Now you can finally inject Spring beans into your Wicket components using the @SpringBean annotation. First, add <h1 wicket:id=”msg”></h1> somewhere in the HomePage.html file. Next, edit and inject the HelloWorldService:

If you run your application and fire up a browser to http://localhost:8080 you should see the message from the Spring bean:

Wicket with Spring integrated

Spring Security for authentication and Wicket Auth/Roles for authorization


Add the following dependencies to your pom.xml:

Spring Security Configuration

Previously, we’ve already added Spring’s ContextLoaderListener to our web.xml. By default Spring looks for the configuration file /WEB-INF/applicationContext.xml. For this tutorial we’re going to put the Spring Security related configuration into a separate file called applicationContext-security.xml. To tell Spring to use both these configuration files we’ll have to add a <context-param> called contextConfigLocation to our web.xml:

Create the file /WEB-INF/applicationContext-security.xml and enter the following lines:

Setting up Wicket

Create a new class to represent a user session. Name it SecureWicketAuthenticatedWebSession and have it extend AuthenticatedWebSession. Inject the Spring AuthenticationManager that you’ve configured in applicationContext-security.xml. Have your class override the authenticate() method and implement getRoles(). You should end up with something like this:

Next you have to change your Wicket Application from a WebApplication to an AuthenticatedWebApplication:

Secured pages and the login form

Finally, we have to create some secured pages and a login form.




Put some links on the HomePage to get to the secured pages.


Test run

Now, if your start up your wicket application you will have Spring Security handling the authentication and user session whilst Wicket Auth/Roles handles the authorization of the secured pages.

End result home page

If you select one of the links without being logged in you will be taken to the login page:End result login form

If you manage to log in correctly, you can then navigate to the secured pages for which you are authorized:

End result authorized page

If, on the other hand, you try to access a page for which you are not authorized, you will be treated to the Access Denied message:

End result access denied

So that’s it. You now have a basic Wicket project setup that uses Spring Security to look up the user (including roles), validate the password, and manage the current user session. Wicket Auth/Roles is used for authorization. It validates whether the current user has access to a particular page.

Source code: secureWicket-source

2 Replies to “Integrating Wicket with Wicket Auth/Roles and Spring Security”

  1. As I ran source code then I found -SecurityContextHolder.getContext().getAuthentication() returns null from addRolesFromAuthentication() method.

Comments are closed.