I've been playing around some more with Lingo and hooking it together with Spring's Acegi Security framework.
It would be awesome if Object properties on JMS messages let you send arbitrary objects. Then it would be no problem to propagate the security context. But, of course it's not that easy.
Instead I subclassed the LingoRemoteInvocationFactory and LingoInvocation classes to create SecureLingoRemoteInvocationFactory and SecureLingoInvocation. The new invocation class propagates the client side SecurityContext's Authentication to the server. I could have also set this as an attribute on the normal RemoteInvocation class, but I thought a concrete class was nicer and avoids creating+serializing a Map.
To handle the authentication information on the server I introduced a Lingo HeaderMarshaller. It pulls out the Authentication object from the invocation and authenticates it with Acegi's authentication manager.
I also introduced a new SessionAuthenticationToken and a SessionAuthenticationCreator interface. If an implementation of that interface is provided to the header marshaller it will use it to create a new session for an authenticated client.
For response messages, if the server side authentication token is a SessionAuthenticationToken, then the header marshaller includes the session ID in response messages sent to the client. In the client side header marshaller I check for this session ID and create a new SessionAuthenticationToken based on it. This token is then used in future server communication and the server then authenticates based on a session ID.
This is working pretty well, but it seems like a lot of work to make this happen. I looked at Acegi's implementation of sessions and remember-me authentication, but unfortunately it's all based around HttpSession and Servlets.
The annoying part for Lingo was that the HeaderMarshaller interface provides a client-side method that includes the RemoteInvocation object. However, at that point a JMS ObjectMessage has already been created, so adding the Authentication as an attribute to the invocation at that point seems to be too late. At least for me I could not get it to work this way, so I had to subclass the RemoteInvocationFactory. However, I'm not sure why it shouldn't work just with the header marshaller, so I really need to look into this more.
If anyone has a better idea or some more insights (or actually reads this), please post a comment. :-)
Recent comments
29 weeks 6 days ago
1 year 10 weeks ago
1 year 13 weeks ago
1 year 42 weeks ago
2 years 3 days ago
2 years 2 weeks ago
2 years 6 weeks ago
2 years 8 weeks ago
2 years 12 weeks ago
2 years 13 weeks ago