Ok, so this is a little project/tutorial to integrate Vaadin to Spring Security, and code everything in Scala. The project also uses Hibernate to persist data into an H2 database. It's developed with Eclipse (+ Scala plugin) and Maven. Code can be found here.
This project implements a web application that allows a user to:
- register to the site by providing his/her personal info
- log-in to the site
- log-out of the site
- change his/her personal info
- change his/her password
The application also shows internationalization (i18n). The main challenge in this type of integration is how to define authorization for different pages and how to handle situations where a page is accessed with insufficient credentials, i.e. how to forward the user to a login page or similar.
Other projects have integrated Vaadin to Spring Security, notably these:
Both of these alternatives have shortcomings that have been worked around in this project + this one is written in Scala.
The problem
As described in (1), Spring Security (SS) works by securing subcontexts (myhost.com/public vs. myhost.com/private) whereas Vaadin uses fragments for different views (myhost.com/#!public vs. myhost.com/#!private). Fragments are a client side part of the URI that is not sent to the server, so SS cannot distinguish between the last two URIs.
Normally SS handles authentication and authorization (a&a) with exception handlers in a filter chain, so if a user tries to access a page (s)he is not authenticated for, SS will throw an exception and an exception handler will forward the user to a login page. This is illustrated below:
-> user sends request
-> servlet invoked
-> exception filter entered
=> page generation (with a&a that throws exceptions)
-> exception filter catches a&a exception and sets up a login page forward
-> servlet returns a redirect message to the browser
-> user's browser goes to a login page (that has a different URI i.e. subcontext)
If we want to implement all views (like the login and registration views that don't require authentication) and other views (that do require authentication and authorization) with Vaadin, we cannot use spring security's exception handling mechanism because the exception handling happens after the Vaadin page generation and needs to forward to another subcontext. If you try to forward to another fragment, you'll get a redirect loop:
Normally SS handles authentication and authorization (a&a) with exception handlers in a filter chain, so if a user tries to access a page (s)he is not authenticated for, SS will throw an exception and an exception handler will forward the user to a login page. This is illustrated below:
-> user sends request
-> servlet invoked
-> exception filter entered
=> page generation (with a&a that throws exceptions)
-> exception filter catches a&a exception and sets up a login page forward
-> servlet returns a redirect message to the browser
-> user's browser goes to a login page (that has a different URI i.e. subcontext)
If we want to implement all views (like the login and registration views that don't require authentication) and other views (that do require authentication and authorization) with Vaadin, we cannot use spring security's exception handling mechanism because the exception handling happens after the Vaadin page generation and needs to forward to another subcontext. If you try to forward to another fragment, you'll get a redirect loop:
The other projects mentioned above work around this by setting up a login page that is not a Vaadin view: The login page is implemented with FreeMarker or some other technology where the page can have a distinct subcontext.
Implementation
To avoid using different subcontexts, the access management has to be done in the Vaadin Navigator during the view generation. Here's a high level description of how this is done:
The integration of Spring to Vaadin starts with an extention of VaadinServlet. This is implemented in net.sf.vaadinturvaa.spring.SpringVaadinServlet. This implementation is pretty much copied from project (2) and loads the Spring application context as well as sets up a UIProvider for the application with net.sf.vaadinturvaa.spring.SpringUIProvider.
The Vaadin views are implemented in the net.sf.vaadinturvaa.views package and are marked with the following annotations:
- When a user navigates to a view, that view is provided by the Spring application context
- The view object is defined with special annotations describing the roles the user must have in order to access the view
- If the user does not have the proper role, the access manager throws an exception that is caught in a custom implementation of the navigator, which will then provide a login view
- When the user provides his/her credentials, SS stores these credentials for the duration of the session (to be read by the access manager)
Spring integration with application context generated views
The integration of Spring to Vaadin starts with an extention of VaadinServlet. This is implemented in net.sf.vaadinturvaa.spring.SpringVaadinServlet. This implementation is pretty much copied from project (2) and loads the Spring application context as well as sets up a UIProvider for the application with net.sf.vaadinturvaa.spring.SpringUIProvider.
The Vaadin views are implemented in the net.sf.vaadinturvaa.views package and are marked with the following annotations:
- org.springframework.stereotype.Component means managed by Spring
- org.springframework.context.annotation.Scope that should always be set to SCOPE_PROTOTYPE for non static views
- org.springframework.security.access.annotation.Secured (optional) that defines the role(s) the user accessing the view should have
- net.sf.vaadinturvaa.spring.VaadinView used to recognize the Vaadin view classes
Authentication
When a user register on the site, (s)he creates an account with personal information and a password. The password is hashed and stored to the database. When the user logs in, the password entered on the login form is hashed and compared to the hash in the database. If they match, the user is authenticated and a token is stored in the SecurityContextHolder:
SecurityContextHolder.getContext().setAuthentication(auth)
The SecurityContextPersistenceFilter will take care of persisting this between user requests.
Custom Navigator and error handling
When a page is accessed in Vaadin, the UI component defined for the VaadinServlet in the web.xml is invoked. More specifically, the Navigator configured in the UI's init method is invoked to access the appropriate view. The view instances are managed by Spring and returned by a custom implementation of Navigator. SS's AccessDecisionManager is responsible for making sure that the user accessing the view has proper credentials and if not, will throw an appropriate exception.
These exceptions are handled in class net.sf.vaadinturvaa.core.NavigatorFactory. This class returns Navigator instances that have a net.sf.vaadinturvaa.core.NavigationErrorHandlingStrategy. This is defined as follows:
The NavigationErrorHandlingStrategy is used by the ExceptionHandlingNavigator returned by the NavigatorFactory:
These exceptions are handled in class net.sf.vaadinturvaa.core.NavigatorFactory. This class returns Navigator instances that have a net.sf.vaadinturvaa.core.NavigationErrorHandlingStrategy. This is defined as follows:
abstract class NavigationErrorHandlingStrategy {
def apply(navigationState: String, navigateTo: String => Unit)
}
class DefaultNavigationErrorHandlingStrategy(val authenticationFailureView: String,
val accessDeniedUnauthenticatedView: String,
val accessDeniedAuthenticatedView: String)
extends NavigationErrorHandlingStrategy {
override def apply(navigationView: String, navigateTo: String => Unit) {
try {
navigateTo(navigationView)
}
catch {
case e: AuthenticationException => navigateTo(authenticationFailureView)
case e: AlreadyLoggedInException => navigateTo(accessDeniedAuthenticatedView)
case e: AccessDeniedException =>
if(AuthenticationHelper.areWeAuthenticated)
navigateTo(accessDeniedAuthenticatedView)
else navigateTo(accessDeniedUnauthenticatedView)
}
}
}The NavigationErrorHandlingStrategy is used by the ExceptionHandlingNavigator returned by the NavigatorFactory:
private class ExceptionHandlingNavigator(ui: UI,
container: SingleComponentContainer,
errorHandling: NavigationErrorHandlingStrategy)
extends Navigator(ui, container) {
addProvider(viewProvider)
override def navigateTo(navigationState: String) {
errorHandling(navigationState, super.navigateTo(_))
}
}
The viewProvider is an instance of ViewProvider that gets the view instances from the Spring application context.
Internationalization
i18n is made of two parts: localized view labels and localized validation messages. View labels come from ViewMessages_xx.properties files and validation messages come from ValidationMessages_xx.properties files. View labels are made available to the application with a MessageSource and all view implementations get access to it by extending the net.sf.vaadinturvaa.views.MessageSourced trait. Validation messages are accessed directly by Vaadin's BeanValidator.
Running the app
To run the app you need to
- start the H2 database as a separate process (./h2.sh -tcpAllowOthers -tcpPort 8043) or start it along with the rest of the application (see root-context.xml). You also need to place the accounts.h2.db file in your home directory (or modify the jdbc.properties file accordingly).
- build the app as a WAR file and start it in a Servlet engine or from the project directory with mvn jetty:run.
- go to http://localhost:9090/#!register and register away.
