I am trying to come up with a nice framework for enforcing permission-based security in my application. I am considering using method-level JDK 5 annotations (JDK 5) to define what roles are required...

public interface ProjectService
{
  @RequiredPermission("project.create")
    public Project createProject( String name );
}

Then, using HiveMind service interceptors, I will enforce the security constraints at run-time...

...
SecurityService securityService = ...;
RequiredPermission constraint = (RequiredPermission)method.getAnnotation(RequiredPermission.class);
if( constraint != null )
{
  securityService.checkPermission( constraint.value() );
  // Call the method.
}


However, unit testing that this actually works is tricky. Do I just test to make sure that the appropriate annotation is present on my domain object method and rely on the service interceptor to take care of things at runtime? Or, since the security constraint is part of the domain logic requirements, should I just scrap the external enforcement and just code it into my service implementation, injecting mock implementations of my security service?...

public class ProjectServiceImpl implements ProjectService
{
  private SecurityServices securityServices;

  public Project createProject( String name )
  {
    securityService.checkPermission( "project.create" );
    // Create the project object...
  }
}

I like the testability of the second approach, but part of me (based on my experience as an EJB developer) wants to externalize the security constraints and let my POJO business domain objects concentrate on the business at hand. However, isn't the security constraint part of the business at hand? My customer (actually me, since this is a pet project) tells me that only users who have been granted the permission to create projects should be able to create them. I can see arguments either way, really. I just wanted to see what the experts thought. Any thoughts?