We are currently looking into how we could leverage Acegi (0.8.3) to add method-level security to our Spring-based web services. These services are components in a large loosely coupled framework that already has several entities dealing with various aspects of security. Specifically, there is a central entity (for the purpose of this discussion, letís call it Authentication Service, or AS) that is capable of authenticating framework users against multiple authentication sources, such as LDAP, AD, etc. There is another central entity (letís call it Security Service, or SS) that is a system of record of role and permission information that is meaningful within the framework. The result of a successful authentication against the AS is a login token that among other things contains a user id and token expiration date. This login token is then used for all web service invocations within the framework and is the first argument of every service method. For existing non-Spring-based services, a service method access decision is a three-step process where a combination of the ASís facility to validate a presented login token, an SSís facility to obtain role/permission information for a given user, and a client library to evaluate roles/permissions is used within the implementation of the service.
For the Spring-based services we are naturally looking at the Acegi framework and ways to plug our security facilities into it. Acegiís AuthenticationProvider/AccessDecisionManager abstraction plays nice with our security facilities I have described above. We could validate the login token and obtain granted authorities in our custom AuthenticationProvider; a custom AccessDecisionManager would then make the access decision using our client library.
I am working on a proof of concept and have a couple of questions:
1. SecureContext population in the service scenario.
I have configured a MethodSecurityInterceptor bean to proxy access to an instance of my service bean. However, the MethodSecurityInterceptor machinery (more specifically, AbstractSecurityInterceptor.beforeInvocation()) requires a populated SecureContext. One way I was able to make it work is by creating a ďsecurity context populatorĒ proxy (with the MethodBeforeAdvice) and wiring it in front of the MethodSecurityInterceptor. While this works fine, I am not sure that this is the intended way of doing this. What is the proper way of doing this for Spring-based services with Acegi?
2. Authentication retention between service method invocations.
Out of performance considerations, I would like to make it possible to have Authentication cached between service method invocations, so that the login token validation and population of granted authorities would only happen on the very first service method invocation with a given token. I see that in the case of web applications an HttpSessionContextIntegrationFilter would do the trick. Is there anything in the framework that lets you do that for services exposed by means of Spring remoting?
Thanks in advance for your responses!