a suggested improvement for the hasPermission() SpEL expression

[bph]

Hi Folks,

We are integrating Spring Security into a new application and have implemented permission-based authorisation at the service layer. We are not using Roles or ACLs, but instead provide our own PermissionEvaluator implementation to do permission checking with the hasPermission() expression in pre- and postAuthorize annotations.

This is working well for us, with one slight ugliness: the hasPermission() expression forces the passing of a domain object reference (or id and type). In some cases, we just want to check if the current authentication has a specific permission. We don't want to consider any domain object (there may not even be a relevant domain object).

In other words, we'd like the hasPermission() expression to have a third valid form that just takes the required permission:

@PreAuthorize("hasPermission('CREATE_FOO')")
public void createFoo(String name, String description) { ... }

This would result in a callback to a new method on PermissionEvaluator interface:

hasPermission(Authentication authentication, Object requestedPermission);

At the moment, we are working around this by passing null:

@PreAuthorize("hasPermission(null, 'CREATE_FOO')")
public void createFoo(String name, String description) { ... }

which is ugly.

Please let me know what you think of this, or if there is another way that I've missed in overcoming this problem.

Cheers,
-Brendan

[Rob Winch]

It sounds like you are looking to use rights. This differs from permissions in that permissions are considered on a per instance basis. You can use @PreAuthorize("hasRole('RIGHT_CREATEFOO')"). See Mike's presentation on InfoQ for a further discussion on using rights.

[bph]

I understand that in Spring Security, granted authorities (via hasRole() checks) are the way to solve this problem, but this has several drawbacks:

1. The way I understand it, Granted authorities are assigned at authentication time, and are preloaded into the user's authentication token. This prevents us from having fine-grained authorities, because of the upfront burden of loading them all at authentication time. It's also wasteful, because there is no way at authentication time of knowing which authorities are needed to satisfy the request, so all must be loaded.

2. If we instead adopt coarse-grained "Roles", we are then forced to hardcode roles to service methods, which is hard to maintain. The advantage of hasPermission is that we can be completely data-driven in the assignment of permissions, at whatever granularity we like.

This blog post discusses the problem (and also suggests using hasRole to model permissions, with the drawbacks mentioned above):

http://springinpractice.com/2010/10/...d-permissions/

I realise that my suggestion might be subverting the Spring meaning of hasPermission, but with the simple addition I mentioned above, we can completely model fine-grained permissions (both per-instance and application-wide) and check them just in time, without the need for Roles at all.

-Brendan