Expose access to STOMP SimpleMessageBroker sessions user Principal

[bgK]

Hi,

We have a Spring application with a SockJS / STOMP SimpleMessageBroker setup.
User authentification happens through a JWT token passed in a STOMP CONNECT
message header.

Everything is working as desired except we would like to close the broker
sessions for the users with an expired JWT token. So users are not able to
receive messages after their authentication expired.

To do so, I wanted to have a scheduled task that would inspect all the open
sessions principals to check if they are expired, and send a DISCONNECT message
when necessary.

However I've not been able to find a way to access the Principal object for
the open sessions (seems to be stored in SimpleBrokerMessageHandler.SessionInfo).

Am I missing something or is this not currently possible?

[rstoyanchev]

@bgK there is a SimpUserRegistry bean with the name "userRegistry" that you can use to get the currently connected users. Have you tried that?

[bgK]

Hi,

Thank you for your answer. Indeed, I can get the list of connected users and their associated sessions through the SimpUserRegistry. However the returned SimpUser and SimpSession interfaces don't allow to retrieve the security Principal where the authentication information is stored. The actual object instances are static private classes and don't have the principal either, so casting does not seem to be an option.

[rstoyanchev]

Yes we only expose the username and session id. Do you have a way to look up the authentication info from that? It's the only option currently. The SessionInfo that's in SimpleBrokerMessageHandler is for internal use to manage heartbeats.

[bgK]

Hi,

Yes, I could create my own store using a ChannelInterceptor to be able to lookup Principals from session id. I was kind of hoping I would not have to do that so the various stores don't get out of sync, but that definitely possible.

[rstoyanchev]

We can store and expose the Principal from SimpUser when it is available. This would work mainly for a local registry and would not with a multi-server registry where user registry content is exchanged.