Q&A with Willie Wheeler: Spring Security 3
Join the DZone community and get the full member experience.
Join For FreeThis 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:
Opinions expressed by DZone contributors are their own.
Comments