One of the challenges around using Spring Security is that the examples—both in the documentation and on the web—tend to promote an overly-simple approach to role-based authorization, hardcoding roles in the source in a non-configurable fashion. For example:

@PreAuthorize("hasRole('facultyMember')")
public Newsletter getFacultyNews() { ... }

(Assume for the sake of example that ACL-based authorization is overkill for the method in question. The user either has permission to read faculty newsletters or not.)

The problem is that when we decide to make a change—for example, maybe teaching assistants should be allowed to read the faculty newsletters too—we have to go into the code to make a change:

@PreAuthorize("hasRole('facultyMember') or hasRole('teachingAssistant')")
public Newsletter getFacultyNews() { ... }

For domain object security there’s no problem because the permissions are cleanly separated from roles. We can map associate individual permissions on domain objects with users and roles as we wish. So the code contains annotations like

@PreAuthorize("hasPermission(#message, write)")
public void editMessage(Message message) { ... }

and all is good. We probably won’t need to change the relationship between the permission and the method itself; we’ll only need to change who (which users/roles) actually has the write permission on the message in question, and we can do that in the database. So that is nice, and we want the same thing for role-based authorization.

Solution: use granted authorities to model permissions, not roles

Here we assume an authentication source that models the desired relationship between users, roles and permissions. The typical relationship would be a many-many relationship between users and roles, and a many-many relationship between roles and permissions. For example:

It would be possible to have a direct relationship between users and permissions too (say to allow for the assignment of fine-grained permissions to specific users in addition to assigning roles), if that were desired.

The schema can be part of some standard authentication source or it can be a custom UserDetailsService; it doesn’t matter.

At the end of the day we need to transform our user representation into a UserDetails, and the trick is to map permissions—not roles—to GrantedAuthority objects to support the getAuthorities() contract on the UserDetails interface. We still have roles, but they matter only insofar as they help to bundle permissions up into convenient packages. The UserDetails implementation will probably expose the roles, but the UserDetails interface simply exposes the permissions (not the roles) via the getAuthorities() method.

It’s really that simple, and the final result is that we can avoid hardcoding roles in the code:

@PreAuthorize("hasRole('PERM_READ_FACULTY_NEWS')")
public Newsletter getFacultyNews() { ... }

As an aside, the predicate name hasRole rather than hasAuthority is a minor annoyance since permissions aren’t roles. The backing check is against a GrantedAuthority and so hasRole() seems to reflect either the intended or the typical use of GrantedAuthority.

One of the casualties was a recipe I wrote about using Spring Security 2 to hash and salt passwords. I’d already written a general article on hashing and salting passwords on my website, but I also wrote one on using Spring Security 2 specifically. But it just didn’t fit into our chapters.

It wasn’t for naught, though. It’s a perfectly good recipe, so I just put it on my website so people can see what kind of information they might expect to find in the book.

Here it is. Hope you enjoy it!

http://wheelersoftware.com/articles/spring-security-hash-salt-passwords.html

A healthy human retina. Our book doesn't go into biometric authentication but this is a cool photo anyway.

Spring in Practice centers on using Spring to implement technical solutions to common problems, but it’s also important for developers to understand the problem they’re trying to solve before implementing a solution. In the book we work pretty hard to provide that understanding.

Here’s an except from the discussion section for a recipe on implementing login forms and remember-me authentication using Spring Security. While discussion sections might treat the problem, the solution or both, this particular discussion digs a little deeper some security/usability tradeoffs to consider when implementing username/password and remember-me authentication.

Discussion

In the background we briefly mentioned that username/password logins are only one approach to authentication. While other authentication mechanisms are commercially available—for example, there are laptops with thumbprint scanners—for most web-based applications, username/password combinations are the most practical approach. It’s simply unrealistic to assume that general web users will have card readers, key fobs, biometric scanners and so forth. Such assumptions may be more plausible in controlled environments.

It’s useful to understand some of the drawbacks of username/password authentication. The main drawback is that in general, the stronger a user’s password is, the harder it is to remember. That in turn increases the chance that the user will either write it down somewhere or else use it for multiple websites, both of which increase the chance that the password will be compromised. Password reuse is problematic partly because a shared password is distributed across many systems (which can be dangerous if that password is not properly managed; see recipes 4.3 and 4.5), and partly because the damage is not limited in the event that the shared password is compromised.

People have devised different approaches to dealing with parts of this problem. One approach is called single sign-on (SSO), and it works nicely in homogeneous computing environments such as corporate intranets. The idea is that the environment (rather than the application) provides for centralized authentication and then that authentication is shared with the applications in that environment. Another approach is the relatively recent OpenID standard, which differs from SSO in being decentralized. With OpenID, a user picks a participating site to be an authentication provider, and then other participating sites use that provider to authenticate the user. This is different than SSO in that with OpenID, different sites require separate logins. While neither SSO nor OpenID does much to limit the damage when a password is compromised (though a password could be reset from a single location), they do have the benefit that they prevent password fatigue without distributing the password across multiple systems.

Remember-me authentication also highlights the tradeoff between security and usability. It’s important to recognize that we’re really authenticating the browser rather than the user. Because there are various scenarios in which there’s a many-to-one relationship between users and browsers (for example, a shared public machine, the family computer, a computer in somebody’s unlocked office), we should treat remember-me authentication as not-entirely-convincing. One good approach is to give a remember-me user access to low-risk functionality, but to force a login if the user tries to access higher-risk functionality. Amazon uses exactly this technique: remember-me users can see product recommendations, but to buy something they have to log in.

The upshot is this: add login forms and remember-me to your app only if it makes sense to do so. In some cases it would make even more sense to use SSO, auto-provision the accounts, externalize your authentication with OpenID, and so on. Just because Spring Security makes it easy to add a login form and remember-me doesn’t mean that you should. If you include remember-me in particular, keep in mind the design issues we just discussed.

Now that we’ve seen how to create a basic, unstyled login form, it’s time to get to work on making it look better. The next recipe will show you how.