Two factor authentication with Spring Security

In this blog post I would like to show you how you could implement (simulate) two factor authentication with Spring Security. If you would like to jump ahead right to the code have a look at my github profile. To easily test the simple demo application I have uploaded it to heroku. Note that by default the application will use a single dyno (Heroku's term for scalable unit) and it will go to sleep after one hour of inactivity. This causes delay of a few seconds for the first request, subsequent requests will perform normally.

I mentioned "simulate" previously since the demo application turns the two factor authentication problem into a normal authentication plus authorisation problem. When valid credentials (here: email and password) are provided the PRE_AUTH_USER role is assigned to the user. With this role the user is authorised only to access the view where the verification code can be provided. If the correct verification code is provided the user will be granted with the USER role, with which all the views can be accessed.

Below you can see how easy is to configure Spring Security with the Java config introduced in version 3.2

In order to support non-security related user information, the AccountRepository is adapted to the UserDetailsService, so Spring Security can use it as an authentication source.

For the second step verification a time based one time password (TOTP) verification algorithm is used, which is described very good here.

Non HTTP initiated broadcast with Atmosphere framework

In this blog post I would like to show you how you can push server side events to a web application using the atmosphere framework. I will also show how you can broadcast to a set of AtmosphereResource instances, not to all suspended connections. If you want to jump right to the code have a look at my github account.

In this simple example the backend will notify the front-end about the following three events

In order to demonstrate the selective broadcast functionality we will broadcast ACCOUNT_DEBITED to chrome, ACCOUNT_CREDITED to firefox and ACCOUNT_LOCKED to IE browser clients. In real application you would broadcast the event to the currently logged in user whose account was debited, credited or locked.

On the front-end with the help of atmosphere.js I send as a header the information about the client (currently the type of the browser)

The initial transport is set to websocket, however if the browser or backend doesn't support it, it will fall back transparently to long polling. The subscribe function initiates a GET request which is handled by the following managed service

With a camel timer component we simulate the continuous event generation. The events are broadcasted to the appropriate AtmosphereResource which models a connections between a client and the server.

With the help of atmosphere framework the events are pushed via websocket or long-polling transport. As you can see below with IE 9 the transport will be long polling since it does not support websockets. With chrome or firefox websocket transport will be chosen.

Spring Boot application on Heroku

In this blog post I would like to demonstrate how easy is to deploy a simple Spring Boot application on Heroku.

• Sign up for a Heroku account
• Download the Heroku Toolbelt, which is tool to manage Heroku applications from command line
• Login to heroku and set up SSH keys

• Clone the sample app from my github account

• Build and verify that it starts up locally

• Configure the sample app as a heroku application and push it live

In the root folder of the sample application there is file name Procfile with the following content

This is needed to let Heroku know how to run the application. On Heroku we cannot tell explicitly on which port should the application run, this depends runtime based on the $PORT environment variable. Our sample application by default runs on 8080 port when starting it up with above command (in the Heroku specific Procfile). This can be easily changed with the server.port in the application.properties as seen below:

This way locally we can use the short command line arguments --port=9000 instead of --server.port=9000 and will also work on Heroku since Spring can bind to capitalized synonyms for Environment properties.
After you have finished stop your deployed application and logout from Heroku

A running version can be accessed here. Note that by default our application will use a single dyno (Heroku term for scaleable unit) and it will go to sleep after one hour of inactivity. This causes delay of a few seconds for the first request, subsequent requests will perform normally.