Acegi & JMS

Has anyone done anything with Acegi and JMS? Specifically, we want the Acegi security context to be all properly setup by the time a message listener is invoked. I'm thinking we will have to include information in the message itself (probably in the message headers) to setup the security context and then intercept the listener interface and do context setup before invoking the actual listener method. Do you suppose this is the right track? At the moment, I'm kind of a newbie to JMS, and have only a working knowledge of Acegi. I guess that passing the username/password around in the message header is not too secure, so we will probably have to come up with a session or token system?
Any tips or advice would be greatly appreciated.

- Andy

A key issue with a session or token system is the lifespan of the message. You could use the existing CAS token system, which is robust and proven, if the messages will only exist for a period less than EhCacheBasedTicketCache.minutesToIdle (or write your own implementation of StatelessTicketCache).

In terms of the JMS-specific presentation of the username and password, could you write an interceptor which is fired for every message (like a Servlet Filter) which unwraps the message, looks at the username and password, sets the ContextHolder, proceeds with the message, then sets the ContextHolder to null?

Good point about the session timeout. So, from an implementation standpoint, it looks like the easiest thing is to pass username and password around. I wonder how secure this is? What if someone with a queue browser is poking around - even if this person is an admin, I still wouldn't want him/her seeing other people's passwords.
Just thinking out loud here, I'm not sure if I could find an automagic way to intercept every message... at least, I'm not sure if the JMS spec provides a way to do this. The interception would have to happen just before the message is delivered to ensure it is intercepted in the same thread as the listener. Because of this, for listener consumers anyway, it would probably have to be done by intercepting the developer's actual listener implementation. In other words, I would use Spring to create my bean instance that implements the JMS listener interface, and then use Spring to wrap that bean instance in an aspect that intercepts the 'onMessage' method on the listener interface and sets up the Context before allowing the listener method invocation to proceed. For "pull" style use (where my client code asks JMS to give it the next message, if any) I would either have to wrap the MessageConsumer interface returned from JMS with an aspect, or invoke a special "helper" method after getting the message and before processing. Because I'm only going to use the listener style in my code, that's all I'm going to worry about for now. :-)
One thought I had that might make this kind of thing a little easier is an Acegi context "template" that works something like Spring's Hibernate template:

Code:

---

  acegiContextTemplate.execute(authentication,
    new AcegiCallback() {
      public Object doInSecurityContext(Context context) {
        ...
      }
    }
  );

---

This template would automatically process the authentication and setup the context in ContextHolder. The Context passed into 'doInSecurityContext' is just for reference. Thoughts?

- Andy

Sounds like a helpful template class for certain environments. Perhaps passing in the target Authentication request (ie populated principal and credentials) would be better than the Context. The Context the template class creates would default to SecureContextImpl, or an alternative callback could be used that also specified the target implementation class.

In relation to the JMS side of things, I agree your approach sounds the most promising at this point. If you find it works, and particularly if you implement it via a template as proposed, I'd welcome the code as it would be a worthwhile addition to CVS nw that JMS is a part of Spring Core.

I'm going to try and work on it some today. I'll move any further discussion to the Acegi development list.

- Andy