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

	@Override
	protected void configure(HttpSecurity http) throws Exception {
	http.authorizeRequests()
	.antMatchers("/signup", "/static/**").permitAll()
	.antMatchers("/code").hasRole("PRE_AUTH_USER")
	.antMatchers("/home").hasRole("USER")
	.anyRequest().authenticated();
	http.formLogin()
	.loginPage("/login")
	.permitAll()
	// always use the default success url despite if a protected page had been previously visited
	.defaultSuccessUrl("/code", true)
	.and()
	.logout()
	.permitAll();

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.

	public class UserDetailsServiceAdapter implements UserDetailsService {
	@Autowired
	private AccountRepository accountRepository;
	@Override
	public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
	Account account = accountRepository.findByEmail(username);
	if (account == null) {
	throw new UsernameNotFoundException(username);
	}
	return new UserDetailsAdapter(account);
	}
	}

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.

	git clone https://github.com/altfatterz/atmosphere-fun
	cd atmosphere-fun
	mvn clean install
	mvn jetty:run

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

	public enum Event {
	ACCOUNT_DEBITED, ACCOUNT_CREDITED, ACCOUNT_LOCKED
	}

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)

	var request = { url: document.location.toString() + 'event',
	contentType : "application/json",
	logLevel : 'debug',
	transport : 'websocket',
	fallbackTransport : 'long-polling' ,
	trackMessageLength : true,
	reconnectInterval : 5000,
	enableXDR: true,
	timeout : 60000,
	headers : {sessionId : sessionId} // 0 for firefox, 1 for chrome, 2 for IE
	};
	subSocket = atmosphere.subscribe(request)

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

	@Singleton
	@ManagedService(path = "/event")
	public class EventService {
	}

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.

	BroadcasterFactory broadcasterFactory = BroadcasterFactory.getDefault();
	Broadcaster eventBroadcaster = broadcasterFactory.lookup("/event");
	Collection<AtmosphereResource> atmosphereResources = eventBroadcaster.getAtmosphereResources();
	for (AtmosphereResource atmosphereResource : atmosphereResources) {
	if (message.getSessionId().equals(getSessionId(atmosphereResource))) {
	eventBroadcaster.broadcast(message, atmosphereResource);
	}
	}

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

	$ heroku login
	$ heroku keys:add ~/.ssh/id_rsa.pub

• Clone the sample app from my github account

$ git clone https://github.com/altfatterz/spring-boot-heroku.git

• Build and verify that it starts up locally

	$ mvn clean install
	$ java -jar target/*.jar // will start on 8080, with --port=<PORT> you can customize
	$ curl http://localhost:8080/greeting?name=Zoltan
	$ Hello Zoltan

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

	$ heroku create // automatically adds a git remote named “heroku”
	$ git push heroku master
	$ heroku logs // check if the application starts up successfully

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

web: java $JAVA_OPTS -jar target/*.jar

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:

server.port: ${port:8080}

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

	$ heroku ps:scale web=0 //scale the web dynos down to zero which effectively takes all your app http-processes offline
	$ heroku logout

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.