What I would like to see in Spring Authorization...

I am trying to integrate Spring Security in CollectionSpace web services. I chose Spring Security because it is used quite widely in enterprise applications and has proven its utility and reliability. Also, it is a well thought out architecture that is easy to understand for the application developers. I like most of the features of Spring Security Authorization. This includes role-based access control, possibility for several types of voting in access decision manager and pre/post invocation hooks, etc.

In Spring Security, a resource to protect such as URI is treated differently from other resources (methods, domain objects, ...) both for permission administration as well as enforcement.  Easiest way to provision permissions for URI is by adding intercept-urls and corresponding expressions in security metadata for a filter in web application. This is metadata packaged with the war file.

1:  <bean id="filterSecurityInterceptor"  
2:      class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">  
3:   <property name="authenticationManager" ref="authenticationManager"/>  
4:   <property name="accessDecisionManager" ref="accessDecisionManager"/>  
5:   <property name="securityMetadataSource">  
6:    <security:filter-security-metadata-source>  
7:     <security:intercept-url pattern="/secure/super/**" access="ROLE_WE_DONT_HAVE"/>  
8:     <security:intercept-url pattern="/secure/**" access="ROLE_SUPERVISOR,ROLE_TELLER"/>  
9:    </security:filter-security-metadata-source>  
10:   </property>  
11:  </bean>  

It perhaps is possible to define security metadata in database for these URIs so that permission could be changed dynamically after the webapp is deployed. I am trying to do exactly the same for CollectionSpace. I will explain the why later. However, I am disappointed to see statements such as "The first thing you should ask yourself is if you really need to do this. If an application requires securing, then it also requires that the security be tested thoroughly based on a defined policy." to defend their approach (of embedding permission expressions in the application itself). This seems like a short-sighted argument to me. It is a bad practice to embed permissions in the application package as it requires redeploying the application if permissions change dynamically as they often do, especially if the web application is a multi-tenant software service or exposes web services.

Secondly, while it is good to see permission enforcement for resources such as URI, method and AspectJ JoinPoint "described" as metadata that is not "hard coded" into the application, it is disappointing to see permissions ("securityMetadataSource") associated with these at the same location. I would have loved to see permission provisioning aspect separated out from the permission enforcement points (interceptors). The permissions enforcement points should only know about which resources to protect and not what permissions are associated with those resources. There seems to be a nicer way to delegate the permission evaluation using the PermissionsEvaluator interface but that seems only applicable to method security.

Why I need such flexibility?

1. CollectionSpace is a multi-tenant application. For the same service URI, there could be different permissions per tenant. 
2. There are lots of URIs that need to be protected for a web service and for a collection of web services in CollectionSpace. CollectionSpace web services are RESTful web services.
3. Not all services might be packaged into a single war file. It would be good to centralize permission provisioning and administration out of the security interceptor meta data packaged with the war file.

Keep tuned for the next post describing how we do permission administration using Spring Security in CollectionSpace...