3

I'm using spring-messaging websockets in a corporate environment. The spring-messaging component runs in the DMZ. It is connected to an ActiveMQ broker network through a firewall into the internal network. Connections are authenticated in the DMZ using spring-security and the user principal is made available.

I need to make subscriptions to user-specific topics that services in the internal network can publish to through their connectivity to ActiveMQ. The spring-messaging /user prefix appears to offer this facility.

Out of the box, if I am authenticated and I make a subscription to a topic of /user/foo/bar then DefaultUserDestinationResolver transforms this into a session id and in ActiveMQ I see a subscription made by the STOMP connector to a topic of /foo/bar-userjf44st89. There are two problems with this in my scenario.

  1. The session-id jf44st89 cannot be transformed back to a user id so a service in the internal network cannot publish to a specific user through its ActiveMQ connection. Their is not, and never will be, a permitted route originating from the internal network through the firewall to the DMZ where the spring-messaging component runs so any solution involving publishing to the spring-messaging component is out.

  2. There appears to be nothing to stop an authenticated but unauthorised user from trying to guess the session id and make subscriptions to topics such as /foo/bar-userjf44st89. Unlikely to succeed, but I prefer impossible to unlikely.

So I'd like to enhance DefaultUserDestinationResolver with my own bean that will create subscriptions of the form /user/user-id/session-id/foo/bar which should solve both the issues and allow internal services to use the ActiveMQ * wildcard to ignore the session-id path component.

My main question is how to best replace DefaultUserDestinationResolver? It is created as a bean by the AbstractMessageBrokerConfiguration class. Is the intended approach for users to create their own @Primary UserDestinationResolver bean? I'd like to retain most of the functionality of DefaultUserDestinationResolver and just modify the format of the topic that it generates.

Vanessa Williams
  • 71
  • 4
Andy Brown
  • 11,766
  • 2
  • 42
  • 61
  • I don't suppose you ever figured this out? I need to know how to do this as well. Your question gives me a hint I did not have (re, @Primary), but I am struggling a bit to make that work. Any thoughts, anyone? How can the DefaultUserDestinationResolver be replaced? (FWIW, it does not work very effectively if using a clustered RabbitMQ environment because there are frequent collisions between generated queue names with predictably disastrous results.) – Vanessa Williams Jul 13 '17 at 17:01
  • @VanessaWilliams I'll add an answer that illustrates how we did it rather than trying to squash code into the comments section. – Andy Brown Jul 14 '17 at 07:54

1 Answers1

0

Since no other answer was suggested I thought I'd post the solution that we went with. Basically we went with an @Primary bean that overrides that replaces the default resolver.

In the below example MyUserDestinationResolver is a class that extends DefaultUserDestinationResolver, overriding the getTargetDestination() method. The SimpUserRegistry object is required by the base class constructor but is not actually used by our implementation at all.

@Configuration
public class UserDestinationResolverFactory {

  @Inject
  SimpUserRegistry userRegistry;

  @Bean
  @Primary
  public UserDestinationResolver userDestinationResolver() {
    return new MyUserDestinationResolver(this.userRegistry);
  }
}
Andy Brown
  • 11,766
  • 2
  • 42
  • 61