Insane Programming Java ramblings and finds on the net

Propagating security through Spring’s HttpInvoker service export

I've been looking into securing my HttpInvoker exported services lately, and I feel that the current Spring reference falls a bit short when it comes to integrating security into HttpInvoker. They'll point you to AuthenticationSimpleHttpInvokerRequestExecutor, which adds basic authentication to your HttpInvoker calls. You'll then have to use the DelegatingFilterProxy to secure your services on the server side.

But what if you already have your SecurityContext on the client side, say for example in a Spring Rich Client application? It would cause a lot of overhead, as each call will retrieve the security context for the user (which you already have). In comes ContextPropagatingRemoteInvocationFactory. This class is normally used in the RMI exporter context, but suits my use case rather nicely. It put the current security context on the client in the invocation object, and when the invocation is executed on the server, it first sets the current security context (which will normally be thread local) to the enclosed security context.

As HttpInvoker is a Spring specific approach to service remoting, I don't really see any problem with this approach. It's not like someone is going to call a HttpInvoker service by hand (it can be done), and even then they still have to be able to correctly set the security context inside the call. In short, if your web API can be called outside of a Spring context or through Spring without a known SecurityContext (but with a username and password), use DelegatingFilterProxy to secure your remote services. Otherwise use the ContextPropagatingRemoteInvocationFactory. It's so much easier to set up.