Difference between @Secured vs @RolesAllowed in Spring? And the concept of Role Based Security?

Question

I am studying Spring Security and I have the following doubts related the difference between the use of the @Secured annotation and the @RolesAllowed annotation.

I know that both have to been used at method level, on my study material I found the followings 2 examples:

• @RolesAllowed annotation:

  import javax.annotation.security.RolesAllowed;    
  public class ItemManager {
      @RolesAllowed("ROLE_MEMBER")
      public Item findItem(long itemNumber) {
          ...
      }
  }
  

• @Secured annotation:

  import org.springframework.security.annotation.Secured;
  public class ItemManager {
      @Secured("ROLE_MEMBER")
      public Item findItem(long itemNumber) {
          ...
      }
  }
  

It seems to me that these 2 annotations works in the same way. What are the differences? What am I missing?

Another doubt that I have is: what exactly represent the ROLE_MEMBER?

I think that this is something like role based security, so it could mean something like: only if the user is a member it could access to the annoted resource (is it correct?). But where and how is definied the fact that the user have setted this role (it is a member)? How exactly works?

Tnx

Solution 1

@Secured and @RolesAllowed are the same. They do the same operation in Spring.

But

• @RolesAllowed - Standard annotation of Java.

  Java has defined Java Specification Request, basically change requests for the Java language, libraries and other components. For the development of annotations, they have provided JSR 250. @RolesAllowed is included in it. This link contains further info in JSR 250

• @Secured - Spring security annotation

ROLE_MEMBER is the role which is set to the security user details.

Refer this example from my current project. Here I'm using the user data object and mapping the roles given to the user to the security user details.

public class CustomUserDetails implements UserDetails {
...
...
... 

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        Collection<GrantedAuthority> grantedAuthorities = new ArrayList<GrantedAuthority>();
        for (Role role : this.user.getRoles()){
            grantedAuthorities.add(new SimpleGrantedAuthority(role.getRole()));
        }
        return grantedAuthorities;
    }
}

These roles are then set for the security approvals using the @Secured or @RolesAllowed or @PreAuthorize("hasRole('ROLE_USER')") for the methods.

By design it's good to put the security in the Service layer. So when I'm securing my service actions, I check for the roles, not for the users.

This way, we can focus on the business logic and the security for the business logic via small security units called roles.

Then I assign the roles to the user. Users can have multiple roles. So you have to see the relationship here. Users are given the roles. And roles are given the access to the business logic. Users are given the access to the business logic via the roles. This concept is called, Role Based Access Control.

And in complex situations we can also manage hierarchical roles. Where one role has many other roles. But in the UserDetails, we have to flatten the role hierarchy and provide the list of roles to the Spring framework to process.

Solution 2

The accepted answer completely answers the question (heh), but I think this is a good place to say how to enable method level security in Spring.

The only thing You need to add is the @EnableGlobalMethodSecurity annotation on a configuration class (see the example) with the following properties set to true (default is false)

• securedEnabled (enables Spring's Secured annotation.),
• jsr250Enabled (enables the JSR-250 standard java security annotations, like RolesAllowed),
• prePostEnabled (enables Spring's PreAuthorize and PostAuthorize annotations).

Example of annotation usage:

@EnableGlobalMethodSecurity(
    securedEnabled = true,
    jsr250Enabled = true,
    prePostEnabled = true)
public class SecurityConfig extends WebSecurityConfigurerAdapter {
// ...
@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
        .anyRequest().fullyAuthenticated()
        .and()
        .formLogin(); // You probably need more than this
}

@Override
public void configure(AuthenticationManagerBuilder auth) throws Exception {
    // your authentication manager config here
}

For more detailed example, see Spring Security Method Level Annotations Example.

Comments

[AndreaNobili]

Ok, and can you give me more information about how exactly works the role based security?

[Faraj Farook]

Wait im updating my answer :)

[masterxilo]

What would be the point of having these annotations (@Secured, @RolesAllowed, @PreAuthorize) but not having them enabled? Why are they not enabled by default?

[Aleksandar]

@masterxilo there is no point in using these annotations if they are not enabled. The reason why they are not enabled by default is because not every Spring setup wants/needs to use method-level security. There are many ways of securing Your web app, ant method-level security is just one of them.

[masterxilo]

Thanks @Casper. However, why aren't they enabled as soon as they are used? Is there any cost when I have them enabled but don't use them? Why?

[Aleksandar]

I am not sure I understand You completely, but as with any additional feature - You first need to enable/configure it before usage. And to find out what is the impact of enabling them, You need to go a bit deeper. But again, what is the point of enabling them if You won't be using them?

[masterxilo]

So that I can just use them instead of having to use AND enable them. It's a usability thing. Imagine you first had to configure your Os and enable, say, symbolic links, before you could use them in your file system. Nonsense. Especially since the cost will be zero if they are just not used even if enabled...

[Aleksandar]

@masterxilo I am not competent to speak about the cost of any Spring's features and Spring usabillity in general. If You think something shoud be changed, please ask them direclty spring.io/team. I will no longer discuss on this topic. Have a nice day.