A few days ago I was in the middle of preparing for my Spring One 2GX 2014 talk Creating Modular Test-Driven SPAs (Slideshare) with Spring and AngularJS. Part of the presentation is a demo application I created called botanic-ng. This application uses AngularJS on the client side and Spring (Boot) on the server-side. As I wanted to not merely create a simplistic toy app, I also intended to add authentication and (simple) authorization to the application.
I did not want to go too crazy with this (e.g. implementing full-fledged OAuth 2.0 integration). Nevertheless, I wanted to add (I hope) some meaningful security features inside my AngularJS application.
Disclaimer: I am not a security expert. Proceed with caution as this solution may not provide enough security for your application needs.
By chance I came across a demo application that Josh Long created a while back. That application, while using Spring Security, did not integrate with Spring Security to the fullest extends, and I felt that I could improve upon that implementation using Spring Session which is new project created by Spring Security lead Rob Winch.
The Servlet 3.0 Specification (JSR 315) introduced several ways to customize the handling of session cookies, for instance changing the name of the cookie (from the default JSESSIONID) and providing additional security relevant settings:
However, you're still pretty much bound to using cookies in order to store your Session IDs. For cases where you need more comprehensive flexibility for handling your sessions, Spring Session comes in quite handy and provides numerous advantages.
By default Spring Session stores session information in Redis using the RedisOperationsSessionRepository. Sessions expire by default after 30 minutes but this can be customized using the setDefaultMaxInactiveInterval property. Beyond Redis a MapSessionRepository is also provided to allow for easy integration with e.g. Hazelcast.
For my use-case, I wanted to expose the Session ID not via a standard cookies but via an HTTP header. Luckily, Spring Session provides various pluggable strategies to customize that behavior. As Spring Session works as a Filter you have to configure a SessionRepositoryFilter. On this filter you can set the used HttpSessionStrategy. By default it uses the CookieHttpSessionStrategy. For my use-case, though, I am using the HeaderHttpSessionStrategy, which by default stores the Session ID in an HTTP header called x-auth-token (This is customizable though).
On the client-side in my AngularJS application, I am adding a HTTP header via $http to every request.
$http.defaults.headers.common['x-auth-token'] = user.token;
This is configured upon successful login through the LoginController. Botanic-ng submits the login credentials to the server, which in turn uses them to authenticate the user using Spring Security (AuthenticationController) and if successful, the AuthenticationToken containing the Session ID and user roles will be send back to the client.
The Session ID on the client is stored in memory only and if you refresh the client, the user must re-authenticate.
For the full source code, please see: