Reduce usage of "ROLE_" prefix to RoleAuthority which implements GrantedAuthority

[HerrDerb]

Current state

Currently a role is defined by prefixing it with "ROLE_". Ca. 293 classes within spring-security currently contain a role definition string prefixed with "ROLE_". Not that it's only very hard to re-factor, it's also not type safe, requires string comparing and is ugly and hard to extend.

Suggestion

A class based extendible solution is needed:
Create a new RoleAuthority class which implements GrantedAuthority.
Create a new RoleSecurityConfig class which implements ConfigAttribute.
Create @HasRole annotation which adds ROLE_ to avoid usage of @PreAuthorize with a unsafe EL string.
Create HasRoleMetadataExtractor which returns a Collection of RoleSecurityConfig
Benefits

1. "ROLE_" is defined once as constant in RoleAuthority -> Huge reduction of coupling.
2. Type safety: Filter grantedAuthrorities for instance types instead of .startsWith(...) .
3. Much better readability and type safety with @HasRole.
4. Increase modularity.

Sample

RoleAuthority roleAuthority = new RoleAuthority("observer");
assertTrue(roleAuthority.getAuthority().equals("ROLE_observer"));
assertTrue(roleAuthority.getRole().equals("observer"));

@HasRole("observer")
public void protectedMethod(){
    ...
}

Next steps

With this base, the spring-security framework will be opened to introduce permission based security more easily.

[rwinch]

Thank you for the report @HerrDerb!

If you don't like the ROLE_ convention you can completely avoid it using the authority expressions. For example, in a web application you can use:

http
    .authorizeRequests()
        .anyRequest().hasAuthority("observer");

As for the annotations, you can leverage meta annotations to avoid rewriting the annotation. For example:

@Target({ ElementType.METHOD, ElementType.TYPE })
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
@PreAuthorize("hasAuthority('observer')")
public @interface Observer {}

Now on your methods you can just do this:

@Observer
public void protectedMethod()

With this base, the spring-security framework will be opened to introduce permission based security more easily.

Permissions are typically per domain object. We cannot add all permissions to the Spring Security user because in most systems the permissions are too large to be contained within memory.

Of course if your system requires a custom GrantedAuthority type you are free to extend Spring Security to have it. However, overall I don't think we want to add more options for handling of ROLE_ which already confuses users.

[HerrDerb]

I just don't understand why a String is used for type identification. That's not how Java nor any OOP works.

[rwinch]

@HerrDerb To a large degree it is historical baggage. I would just view the end result as:

• if you used roles in the past, you can continue to use them
• if you create a future application & don't like ROE_ just use authorities
• if you need a custom authority type, you can create it. The framework only supplies that the framework itself needs (if we provide everything than it quickly becomes too much. Consider if we added a first and last name to a User or an address to a User. This would not work, we expect that most users will extend the framework)