May 28th, 2008, 03:58 AM
Programmatic authorization checks
Our previous home-made security framework supported programmatic authorization checks using calls similar to the following:
void SecurityManager.checkAccess(“command1”) throws AccessDeniedException;
Here, a command is a simple abstraction; each command is mapped to a list of required roles or other authorizations. A user has access to a given command if s/he has one of the roles/authorizations that the command is mapped to.
First question is whether Spring Security contains support for 'commands' as described above. I guess this is somewhat similar to Spring Security ACL functionality, is this true? Second, what is a good way to implement programmatic security in application code when using Spring Security? Do utility methods similar to the ones described above exist? Are there other/better ways to implement programmatic security checks?
To be more precise; I know one can use a similar mechanism as is done in RoleVoter for checking whether the current user has a given role, but does Spring Security also contain a utility method isUserInRole() that is easier to use?
Also, possibly a more generic way of checking access is to inject the AccessDecisionManager into an object that requires programmatic security, and use the decide() method on that class to implement security. Would this be a recommended way of implementing programmatic security? If so, what would a call to the decide() method look like exactly?
Aug 4th, 2008, 09:31 PM
I'm interested in this also. We have an app that includes both Java and C/C++ components. The Java components work fine with the default method/join point interceptor means of calling into Authorization processing. However, we also want to be able to expose an API for the non-Java components.
It would nice for the API to simply be able to call directly into the AccessDecisionManager, then to the AclEntryVoter; however, this is not so easy. The AclEntryVoter expects that the object passed-in will be either a MethodInvocation or a JoinPoint -- not a domain object instance. The latter is retrieved in another way.
Perhaps it would be OK to simply have the API method implementation intercepted?
Tags for this Thread