This week's DZone Refcard by Willie Wheeler is about Expression-Based Authorization with Spring Security 3. The Refcard covers the key features of expression-based authorization with Spring Security 3 and aims to be a handy reference for novices and experienced users alike. DZone had a chance to catch up with Wheeler about the card and his upcoming book.
DZone: Could you give us an introduction to yourself and your work on Spring Security 3?
Wheeler: Hi, I'm Willie Wheeler, and I work as an architect for the Apollo Group in Phoenix. I've been a Java developer for 13 years now, and it's something that I enjoy immensely. Security is one of my areas of interest so I'm glad for the opportunity to do the Refcard.
I've been using Spring for six years, and Spring Security for about two years now. Just as a user. I don't work "on" Spring Security itself, other than submitting the occasional Jira issue.
DZone: What is whitelisting and what are the benefits?
Wheeler: Whitelisting and its counterpart, blacklisting, are two different approaches to access control. Blacklisting is the approach of allowing anything that isn't specifically excluded (the exclusion list is the so-called "blacklist"), whereas whitelisting involves disallowing everything that isn't specifically permitted (the inclusion list is the "whitelist").
With law people are innocent until proven guilty, but with security it's exactly the opposite. Trusting unproven people is a great way to get ripped off. Whitelisting amounts to a posture of distrustfulness and blacklisting is being generally trusting. Whitelisting is safer.
Interestingly, for valid practical reasons, the TSA's no-fly list is a blacklist, not a whitelist. Whitelisting would be safer, but probably not "better" in this context.
Preferring whitelisting is a general security principle; it isn't specifically tied to Spring Security. But one of the keys to using a security framework effectively is to understand both the general principles and their implementation using the framework. With Spring Security we can implement whitelists for URLs and also for method security, as the Refcard illustrates.
Security whitelists show up in some other places too. One is in Spring Web MVC. Web MVC supports automatic binding of HTTP parameters to POJOs, and if you're not careful, you may find users injecting data into POJOs by providing HTTP parameters that you didn't include in your HTML form. We can deal with that by whitelisting the parameters in an @InitBinder method.
Another example is validating HTML input, like accepting user comments and allowing HTML. It makes a lot of sense to whitelist the tags. The alternative is try to think of all the tags you don't want, like <script> or <img width="1000000" ...> or whatever, and risk being surprised by tags you forgot to exclude, by tags newly supported by a browser and so forth.
DZone: You mentioned in your Refcard that people should try to drive access decisions using data rather than code. What does that mean, and why should we do that?
Wheeler: Access control rules are the sort of thing that we expect to change from time to time. Some secure business function that used to be handled by one role needs to be transitioned over to another role, for instance. And where security is concerned, it's fairly often that we can't wait for the next software release to change the rule. We need to change the rule now.
In software, when something changes a lot, or when changes require more or less immediate turnaround, we typically try to push those into configuration or the database. That way we don't have to go through all the development, test, deployment and administrative overhead associated with making an actual software change.
First consider the following poor (common, but poor) approach to access control. Let's say that we have a web-based forum application, and the requirement is that only the site administrator can delete forum posts. So we code that into the app using an annotation or whatever. Later on we decide that we want to add forum moderators for each of the individual forums, and the moderators need to be able to delete posts too. We can't do that without rebuilding and redeploying the app. If we're a vendor, our customers have to wait for a new software release, which could be months away. Bummer.
A much better approach is to put things like "only users with permission to delete this message can actually delete it" in the code. That's a rule that's likely to stand the test of time. Then we specify who has which permissions on which objects in the ACL database. Customers can implement a forum moderator concept simply by creating the right database records, even if the vendor never explicitly treated or even considered the use case. Very powerful.
DZone: Besides using ACLs to drive access decisions, there needs to be some way to manage ACLs from the app. How is that done?
Wheeler: Spring Security has an API for managing ACLs. This is the kind of thing you might do when creating or deleting domain objects. If I create a new secure domain object in the app, then I need to use the Spring Security API to create a corresponding ACL and populate it with the right entries.
DZone: What does your upcoming book, Spring in Practice, cover?
Wheeler: In terms of the Spring technologies it treats, it's fairly wide-ranging, covering both the core framework (Spring Framework 3) and several portfolio projects. Examples include Spring Web MVC (including REST support), Spring Web Flow, Spring AOP, Spring Security, Spring Integration, Spring/Flex integration via BlazeDS, Grails and Spring Roo. It also shows how to integrate with non-Spring technologies such as Java Content Repository, Hibernate, Hibernate Validator, reCAPTCHA, the AttackLab WMD editor (the same editor StackOverflow uses), Google App Engine, AJAX, jQuery, Sitemesh, Velocity, Mockito, JMX and more. Lots of good stuff.
DZone: How does this particular book stand out from other books on Spring?
Wheeler: There are several things I think.
1) The book is in the cookbook/recipe format. While that's not itself unique, what I think is special is that it's organized more around problem domains than solution technologies. For instance, individual recipes are things like "how to create a login form that appears on every page" instead of how to use this or that specific feature of a given framework. One advantage of this approach is that developers don't need to already know which specific technologies are involved. Another advantage of the problem-centric approach is that the book really shows how to tie things together, since real problems typically involve integrating multiple technology solutions. Each chapter is essentially self-contained, but its constituent recipes build upon each other in a way that shows how to accomplish the necessary technology integration.
Exclusive deal for DZone readers! Use promo code sip35dzone and receive 35% off the MEAP and ebook of Spring in Practice! Click here to purchase.
Have a great comment about your experience with Spring Security 3? Add it to this post (see below) for your chance to win a Spring in Practice ebook free! We'll select the best two comments to win.
2) The sample code and user interfaces are fairly realistic compared to what you might normally see in technical books. For example, chapter 6 shows how to build a message forum application. It's not a complete app by any stretch, but it includes a login, authorization, multiple forums, individual moderators for each forum, individual ACLs for forums and messages (message author can edit messages they create), AJAX calls to RESTful services for blocking and unblocking messages, jQuery dialog boxes that confirm message deletions, and stuff like that. These are real things that real app developers have to figure out how to do, and a lot of times it's the details that trip us up.
3) For developers who have ever wanted to develop their own Spring-based framework code but don't know where to start, chapter 15 should be interesting. I show how to implement a circuit breaker component complete with custom namespace, Spring-style template, AOP-based configuration, annotation-based configuration, JMX integration (so the NOC can manually trip and reset the breaker), and more.
For more information on Spring in Practice or to purchase a copy, click here.
Other recommended reading from Manning:
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}