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.
#1 by Nitin on 2011/08/09 - 10:42
Can you post a code example? The configuration part mainly .. and how do we access context at the server side..?
#2 by asyard on 2011/12/18 - 19:12
Hi, that was what I look for. Thank you for your post.. But I would like to ask a question for my problem, my user is authenticated in one side, so there is a securitycontext.. For remoting I type
on client side as ContextPropagatingRemoteInvocationFactory puts the securitycontext to request header.. But I couldn’t understand the server side. securitycontext is now passed to the remote side, but what am I suppose to do then? My remote side config only has
part. I don’t understand how to deserialize the securitycontext part and create a remote securitycontext.. What configuration should I add for this? Do I have to put authenticationmanager? or what property and class should I add to <bean name="/securityService"… that does the opposite of ContextPropagatingRemoteInvocationFactory?