It’s Friday, and time again for some Friday Fixes: selected problems I encountered during the week and their solutions.
This week’s challenges were all over the place, but I’ll focus in on just a couple of fixes in one popular category: Spring Security.
Filters : MVC :: Oil : Water
The web app I’m currently working on has some unique functions that occur at login. Sure, it all starts with a login form, but it goes far beyond the simplified functions of standard Java EE form authentication. Good news is, Spring MVC makes implementing these login functions nice, while Spring Security provides many of the protections we need. Bad news is, Spring Security and Spring MVC don’t play together at all.
A key reason is that Spring Security’s access control and authentication mechanisms are called upstream in the filter chain (before the controllers) and can’t access the controller’s state, session, and request. With forms authentication (LoginUrlAuthenticationEntryPoint, UsernamePasswordAuthenticationFilter, and the like), you get one monitored post URL for authentication (by default, j_spring_security_check) with no means for the controller to do sophisticated validation or page flow.
If I could lock myself into the strict confines of form authentication, then Spring Security’s implementation would be helpful: outside a bit of XML namespace configuration, all I’d need is a simple UserDetailsService DAO. But I couldn’t, and trying to force it just convinced me that I really didn’t want Spring Security’s forms authentication after all. What I really wanted was a Spring MVC login process which passed authentication details to Spring Security when done.
That part was very easy. I just wrote a small utility class which, after it authenticated the user and retrieved his authorities, simply set them in Spring Security’s context. Like so:
/** * Notify Spring Security that we've logged in and initialize * authorities for downstream filtering. */ public void login(MyUser myUser, HttpSession session) { List<GrantedAuthority> authorities = new ArrayList<GrantedAuthority>(); for (String str : myUser.getAuthorities()) { authorities.add(new SimpleGrantedAuthority(str)); } UsernamePasswordAuthenticationToken auth = new UsernamePasswordAuthenticationToken( myUser.getUserId(), myUser.getPassword(), authorities); SecurityContext securityContext = SecurityContextHolder.getContext(); securityContext.setAuthentication(auth); session.setAttribute("SPRING_SECURITY_CONTEXT", securityContext); } |
To update Spring Security at logoff, I just did this:
SecurityContextHolder.getContext().setAuthentication(null); |
This made Spring Security and me both happy, with no need to mix the oil of Spring MVC controller flow with the water of Spring Security authentication filters.
Casting Custom SPeLs
Among its many uses, the Spring Expression Language (SpEL) allows for flexible URL filter (intercept-url) expressions. And custom expressions can be used to support unique access control requirements through simple configuration.
The T(my.package.Class).myMethod(whatever) syntax was one option, but that’s ugly, limited, and prone to error. Further, by stepping through the code, I learned that the expression handlers called in Spring Security have access to all sorts of useful information to make authorization decisions. So building my own custom expression evaluator was just the ticket.
But plugging in a custom expression handler took some maneuvering. Turns out, you can’t just add a new SecurityExpressionRoot directly in the security configuration; you have to swap in a custom SecurityExpressionHandler and have it instantiate the evaluator, like so:
public class MySecurityExpressionHandler extends DefaultWebSecurityExpressionHandler { @Override protected SecurityExpressionRoot createSecurityExpressionRoot( Authentication authentication, FilterInvocation fi) { WebSecurityExpressionRoot root = new MySecurityExpressionRoot(authentication, fi); root.setPermissionEvaluator(getPermissionEvaluator()); return root; } } |
To round out the example, here’s a template for the custom evaluator and security context configuration.
public class MySecurityExpressionRoot extends WebSecurityExpressionRoot { public MySecurityExpressionRoot(Authentication a, FilterInvocation fi) { super(a, fi); } public boolean canIDoThis() { // Your clever authentication here. // 'this' has access to the authentication token, request, and other goodies. // If conditions are satisfied, return true; otherwise... return false; } } |
<http use-expressions="true" ... > <intercept-url pattern="/public/stuff/**" access="permitAll"/> <intercept-url pattern="/private/stuff/**" access="denyAll"/> <intercept-url pattern="/members/only/stuff/**" access="isAuthenticated()"/> <intercept-url pattern="/conditional/stuff/**" access="canIDoThis()"/> <expression-handler ref="mySecurityExpressionHandler" /> ... other configuration ... </http> <beans:bean id="mySecurityExpressionHandler" class="com.writestreams.security.MySecurityExpressionHandler"/> |
Note that using expression-handler under http requires Spring Security 3.1 or higher, or at least an XSD patch.
Linkapalooza
Some useful / interesting links that came up this week:
- Marine Traffic – Live ships map.
- Seven Security (Mis)Configurations in Java web.xml Files.
- Web server usage stats – Apache wins CGI, Tomcat wins Servlets, IIS monopolizes .NET.
- View Source Chart – Simple but useful Firefox extension.