Lyndsey has posted 139 posts at DZone. View Full User Profile

Q&A with Willie Wheeler: Spring Security 3

07.09.2010
| 8516 views |
  • submit to reddit

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:

AttachmentSize
willie_wheeler.jpg14.16 KB
Wheeler copy.jpg13.4 KB
Published at DZone with permission of its author, Lyndsey Clevesy.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Alan Redding replied on Mon, 2010/07/12 - 2:50pm

As an architect responsible for upgrading our enterprise framework to support Spring 3 Security from Spring Security 2.5.x, the namespace configuration enhancements are a huge leap forward.  Namespace configuration simplifies configuration for many our application teams and minimizes hard to find issues such as incorrect filter chaining.   So far, the external LDAP configuration elements in the security namespace have proven the most useful.  Session management provides all the necessary functionality including session fixation protections.  However, I would like to see more options available for controlling rules around session expiration and concurrency control, or at least a way to specify the rules using Spring EL.  Spring EL support in expression-based access controls is one of the key new features we plan to leverage in our enterprise framework.  Having a more concise way to specify access control rules is a necessity for our enterprise framework as we support many application teams in different divisions that have their own internal security rules and uniform enterprise rules will not suffice.

Willie Wheeler replied on Mon, 2010/07/12 - 6:58pm

The namespace configuration for Spring Security is especially nice because it sets up a lot of default configuration for you automatically. I'm thinking specifically about the <http> configuration. If you look at the bean dependency graph for <http> in Spring IDE you will see that there's a nontrivial amount of underlying machinery.

County Line Nissan replied on Mon, 2011/08/01 - 11:54am

Nice article. Fills in a few gaps in the Spring Security documentation! -County Line Nissan

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.