Spring Websocket allows clients (I.e. Browsers) to directly send messages to any broker-backed destination, I.e. Allowing direct client-to-client communication bypassing the server-side application. In real world, I don't think it's acceptable to publicly expose write-access directly to your message broker. For security and message-integrity reason, you'll usually want to allow only the server application to ever send any message to the clients via the broker. But I can't find any information on how to achieve this. The default behaviour is browsers have unrestricted read+write direct access to broker destinations.
This is not technically true, there's no direct communication between the client and the broker, all messages go through your application regardless of the destination type. Broker destination messages are forwarded to the broker, this means you can intercept them at any time before they reach the broker. Spring Security 4.0.0.RC1 has support for WebSocket security so you can apply authorization on your messages:
public class WebSocketSecurityConfig extends AbstractSecurityWebSocketMessageBrokerConfigurer {
protected void configureInbound(MessageSecurityMetadataSourceRegistry messages) {
messages
.antMatchers(SimpMessageType.MESSAGE, "/topic/**").denyAll()
.antMatchers("/**").hasRole("ADMIN");
}
}
In the above snippet, sending messages to any /topic destination is denied and any other action to other destinations require the role ADMIN. If that's not enough for you, you can always implement your own ChannelInterceptor to intercept messages and add it to the clientInboundChannel.
Related
I am using Stomp with Spring Boot and Spring Security. Originally I was using WebSocketMessageBrokerConfigurer and in order to make sure only one connection per authenticated session was allowed I would add ChannelInterceptor in the ConfigureClientInboundChannel override and for the preSend I would check to see if the given authenticated user is already connected and listening.
However I decided to use AbstractSecurityWebSocketMessageBrokerConfigurer because I want to allow only authenticated users to connect to stomp socket.
But it seems that in the AbstractSecurityWebSocketMessageBrokerConfigurer I am not allowed to override ConfigureClientInboundChannel. So since that is the case, how can I check to make sure that on connect, user isn't already connected and listening on some other tab?
I have recently developed a simple messaging application with Spring Boot and Spring Security. The application takes in 2 users - user A and user B. Once, user A performs a specific task a notification is sent to user B. Currently I am doing this by adding a Spring Messaging dependency and SockJS and it works great.
Here is where I am confused and hoping to receive some guidance. I realize there are many tutorials that speak about RabbitMQ and ActiveMQ. From what I understand, they are message brokers. May I ask what is the difference between SockJS and RabbitMQ/ActiveMQ? And do I need RabbitMQ/ActiveMQ in my current application together with SockJS?
SockJS is JavaScript based WebSocket client library that runs in a browser. It can be used to send messages to or receive messages from a broker.
Both RabbitMQ and ActiveMQ are message brokers, examples of message-oriented middleware. They both support WebSocket clients which use a messaging protocol (e.g. STOMP or AMQP). Brokers receive messages from and dispatch messages to clients.
You haven't really provided enough information to determine whether or not you actually need to use either RabbitMQ or ActiveMQ in your current application given that it's already working as it is.
We implemented a filter, or plugin, in ActiveMq broker that intercepts inbound messages and validates them from a security standpoint.
We are needing a programmer friendly way of receiving these exceptions on the producer side (ideally not at connection level, but at session or producer level, since they may need session specific reaction).
We are doing message level authorization in the broker side in the following way: In the ActiveMq provider (server) we implement BrokerFilter (plugin) in order to intercept the incoming JMS message, and validate a JWT access token attached to the message as property. If the JWT token is valid, then the message is let through downstream chain, if it is not valid, a SecurityException is thrown.
We notice that the message does reach back to the sending JVM which reports that no ExceptionListener instances registered for the specific exception.
Our question is, where can we best register an ExceptionListener in Spring JMS for this scenario? We have direct access to the producer and JMS session, but not to the JMS connection.
It is true that registering an ExceptionListener to the connection would be useful for connection level events, but for session level events it may make the code more understandable and cohesive if we could register such exception listeners locally to the session or producer, since they are kind of direct responses to a message send attempt.
Of course it would be also possible to implement local exception listeners via connection level and a thread local structure of local listeners, but i am wondering if JMS or Spring already provides such possibility of the session or producer finding out directly that their message was not authorized, so that they answer upstream to calling microservice rather then retyrying to send it for instance.
We are using persistent messages but unsure if we do synchronous or asynchronous send. I believe on asynchronous send, an ExceptionListener of some kind will be called back on such an event (exception thrown in BrokerFilter.send method). While on the synchronous send perhaps the exception will directly be thrown there (but the thread blocking may decrease robustness of the microservice).
This is solvable with connection.setExceptionListener but to us it would likely be more convenient a session.setExceptionListener or even a message request level listener.
We would like to see any other options possible with Spring JMS except registering an exception listener at connection level and except synchronous send, if any such other options are possible.
Since Spring JMS uses the JMS API then you're pretty much limited to what the JMS API provides and it doesn't provide a session or request level exception listener. It provides a connection level exception listener for exceptions which are reported asynchronously and normal Java checked exceptions for the synchronous use-case.
We have built a Spring Boot messaging service that listens to a JMS queue hosted on a TIBCO EMS (Enterprise Messaging Service) Server. It is a fairly straightforward application that receives a JMS message, does some data manipulation and updates a database.
The issue is that, occasionally, there are no JMS consumers on the queue, and incoming messages are not processed. However the Spring Boot app is up and running (verified by ps -ef). Restarting the app restores the consumer, but unfortunately this is not a feasible solution in production etc.
Other facts of interest:
We have observed this to happen when the JMS server accepts SSL traffic and is on deployed as a Fault Tolerant pair (although this has been a conculsive observation yet)
There is absolutely no indication in the log (like an error) when the consumer goes down.
We are using Spring-JMS (4.1.0) and TIBCO EMS (8.3.0)
Code Snippet of instantiating a DefaultJmsListenerContainerFactory:
#Bean
public DefaultJmsListenerContainerFactory listenerJmsContainerFactory() {
DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory();
TibjmsQueueConnectionFactory cf = new TibjmsQueueConnectionFactory("tcp://localhost:7222");
cf.setUserName("admin");
cf.setUserPassword("");
factory.setConnectionFactory(cf);
return factory;
}
The JMS Listener:
#JmsListener(destination = "queue.sample", containerFactory = "listenerJmsContainerFactory")
public void listen(TextMessage message, Session session) throws JMSException{
System.out.println("Received Message: "+message.getJMSMessageID());
System.out.println("Acknowledgement Mode: "+session.getAcknowledgeMode());
// Some more application specific stuff
}
While we are trying to setup additional logging on both the Spring Boot and TIBCO side, we would like to check some points like:
Can there be a situation where a consumer idle for more than a certain time, automatically expires?
Is this something that is governed by DMLC settings like idleConsumerLimit, idleTaskExecutionLimit etc.?
Can these properties be viewed in the Spring Boot code mentioned above? For instance in the code above, the JMS Listener is being created under the hood by the DefaultJmsListenerContainerFactory. So how can we access the DMLC object so that we can invoke methods like getIdleConsumerLimit(), getIdleTaskExecutionLimit() etc.
Thanks for the inputs,
Prabal
Most likely, something in the network (router, firewall etc) is silently dropping idle connections.
While not part of the JMS spec, most vendors implement some kind of heartbeat mechanism so that the client/server exchange pings from time to time, to prevent such actions by network components and/or to detect such conditions.
Look at the Tibco documentation to figure out how to configure heartbeats (they might call it something else).
We're using spring-messaging websocket with STOMP. Now we've defined multiple #SubscribeMapping methods, but is there also some sort of callback that gets fired when a client application disconnects from the socket?
We got a list of connect clients and some additional properties, like status. Status field needs to be updated when the client application disconnects.
Any suggestions on how to achieve this in Spring? I've tried implementing ApplicationListener however, there's no usefull information in the OnSessionDisconnect object.