Is it possible to implement method-level access checks with annotations?

Consider some basic authorization framework with Users and Groups where access to methods should be guarded by checks which make sure that the user or the group have the necessary PriviledgeLevel to execute the method and fails otherwise.

What I imagine is something like this:

@AccessCheck(PriviledgeLevel.ADMINISTRATOR)
public static void secureMethod(){ ... }

Where the code checking basically does

if(currentUser.getPriviledgeLevel >= PriviledgeLevel.ADMINISTRATOR ||
   currentUser.getGroup.priviledgeLevel >= PriviledgeLevel.ADMINISTRATOR)
  // Allow access
else
  // Deny access       

Would it be possible to implement it this way?

I did a bit of research which points to some existing things based on AspectJ, mostly on the Security Annotation Framework (SAF) and on Spring Security.

I'm a bit concerned because SAF doesn't seem very active anymore and the documentati开发者_如何学Goon isn't that great.

I'm not sure about Spring Security but it seems to be more focused on security problems in web-related topics.

The Java Authentication and Authorization Service seems to be related, but doesn't use the annotation approach.

Does it make sense trying to define these security requirements with this declarative approach?

Is there another library/framework I'm missing, which already implements what I want or some techonology which would be relevant here?

Or is there a completely different solution (like implementing my own ClassLoader, ...) which is superior to what I imagine (in terms of conciseness and readability for the library user)?

I think AspectJ will do what you want it to do. We have a whole bunch of methods which you need certain access rights for and we've created an AspectJ aspect which will check that and error out if the user does not have those permissions.

As a plus, because AspectJ is "woven" into the classes at compile time it cannot be disabled by configuration.

We also use Spring Security, it is possible to use both in harmony!

You could do this fairly trivially yourself by using dynamic proxies.

public interface MyInterface {
           @AccessCheck(Privilege.ADMIN)
           public void doSomething();
}

The proxy would be created on the class that implements your interface and you would annotate your interface with your custom annotation.

 MyInterface aInterface = (MyInterface) java.lang.reflect.Proxy.newProxyInstance(obj.getClass()
                .getClassLoader(), obj.getClass().getInterfaces(),
                new YourProxy(new Implementation());

In the invoke() method of your proxy, you can check if your method has the annotation and throw a SecurityException if the privileges are not met.

public YourProxy implements InvocationHandler {
         ....
         public Object invoke(Object proxy, Method method, Object[] args)
        throws Throwable {

              if ( method.isAnnotationPresent(AccessCheck.class) {
                    ....// do access check here and throw SecurityException()
         }
 }

With Spring Security, you just have to add:

@Secured("ADMINISTRATOR")
public static void secureMethod(){ ... }

And configure it properly, by:

1. use JdbcDaoImpl as your UserDetailsService
2. enable group support
3. customize the queries (if you are using database credential storage)

If you are not using database credential storage, just configure your preferred UserDetailsService to add both user and group credentials to the authorities of the generated UserDetails.

Of couse, it is hard to understand it without checking the concepts at the documentation, but method level access checks is perfectly possible with spring security and it's my prefered technology for it.

In Spring Security, as the docs state, both @Secured and @PreAuthorize can be used at method level.

To enable @PreAuthorize (if you haven't already...), you need to put <global-method-security pre-post-annotations="enabled" /> in your configuration XML;

For @Secured use <global-method-security secured-annotations="enabled" />.

For more details, refer to this article.