• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Unit Testing and Security Constraints...

 
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 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?
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd probably go with the annotated permissions and static analysis in your tests to verify (and document) which permissions are required for which method and so on.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic