Spring Security: Advice needed on how to handle GrantedAuthority

Question

I have a concern when it comes to GrantedAuthority objects in a Spring Security application. I'm looking for a good way to handle things. First of all I'm trying to describe my concern, if there are any factual errors do not hesitate to point them out, I'll only be greatful.

Spring Security uses GrantedAuthority instances to act as tokens of authorization in different parts of the application.

By default a GrantedAuthority may present itself as a String. When methods are secured using *@Secured("ROLE_NAME")*, or URL's are secured using the Spring XML configuration or when the HttpServletRequest request is checked programmatically as in *if(request.isUserInRole("ROLE_NAME")) {..}* it's always the String that you are using to specify the authority which is checked for.

I'm wondering about the implications of using static strings in several places of the application. If a role name is changed the developer has to hunt down all the old strings and update them. There will be no compile time error if a String is missed, only a problem at runtime.

What is the best way according to you when it comes to handling GrantedAuthority objects in a Spring Security application? What pros and cons does your solution have?

Answer 1

I do not see a big problem here. It is very unlikely for GrantedAuthority to change the key. Just do not name your roles ROLE_A.

Also, I personally prefer XML security configuration over annotations. In general to keep any related configurations in one place looks like a good idea.

Answer 2

In Spring and other frameworks (especially for dynamic languages) "Convention over Configuration" is used. If you were free to define the role names yourself, you easily find out that much more lines of code are needed.

So stick to the convention. Always use the 3 following roles, ROLE_ANONYMOUS, ROLE_ADMIN, and ROLE_USER. If you need another one, name it accordingly and use it in all occasions. Documentations is important.

Also unit testing is imported. It helps you in the cases that an error isn't caught by the compiler.

Answer 3

First off, if possible, only do your checks at a particular place in the application (e.g. an HTTP interceptor at the beginning of the request), and using only one of the mentioned approaches. This is a good practice since you will be able to know authoritatively when a user becomes authorized.

If this is not possible, use enums for the role names and only compare on the enums. Therefore, if you wanted to locate all usages in the application it's a simple search.