Improve web socket header support [SPR-13170]

[spring-projects-issues]

Bobby Warner opened SPR-13170 and commented

There is no way to access any of the web socket STOMP headers in the Spring handshake handler. This is required to support custom authentication / authorization schemes.

For example, given a JS file like this:

var socket = new SockJS("http://localhost:8080/stomp");
var client = Stomp.over(socket);
var headers = { login: "foo", passcode: "bar" };
client.connect( headers, function() {
    // do stuff
});

It would be great to be able to access the STOMP headers in the handler like this.

import org.springframework.http.server.ServerHttpRequest
import org.springframework.web.socket.WebSocketHandler
import org.springframework.web.socket.server.support.DefaultHandshakeHandler
import java.security.Principal

class ChatHandshakeHandler extends DefaultHandshakeHandler {
    @Override
    protected Principal determineUser(ServerHttpRequest request, WebSocketHandler wsHandler,
                                      Map<String, Object> attributes) {

        // Get the STOMP login and passcode headers here. (login = foo, passcode = bar)
    }
}

---

Affects: 4.1.6

Issue Links:

• Spring WebSockets should support token-based authentication [SPR-14690] #19254 Spring WebSockets should support token-based authentication

[spring-projects-issues]

Rossen Stoyanchev commented

hi, I think there is some confusion with the layering. A WebSocket connection (or SockJS emulation of it) must be established before STOMP messages, starting with a CONNECT frame with the login headers, can be sent. So the HandshakeHandler is layer below STOMP and happens before it.

I wonder why you're thinking of sending a login/passcode over STOMP? We don't have much support currently for STOMP-based authentication. STOMP was first used over TCP where a login/passcode would be necessary. By and large for most web applications it makes sense to use existing web authentication to protect the HTTP URL at which the WebSocket/SockJS endpoint is exposed. For example Spring Security security HTTP URLs. Also keep in mind Spring Security 4 has Spring WebSocket support that also lets you authorize STOMP messages.

You can install a ChannelInterceptor on the clientIboundChannel in a @EnableWebSocketMessageBroker setup. That will let you intercept and potentially even block STOMP CONNECT frames. You could also store information in the session associated with the connection. Again this is all a layer above the WebSocket/SockJS transport.

[spring-projects-issues]

Bobby Warner commented

Interesting, thanks for the feedback. I can't use existing session-based web authentication because this is an API that is used by native mobile applications. I'm instead trying to find a way to authenticate the mobile app for use of the web socket. The API is using Spring Security OAuth with Bearer tokens.

Do you by chance have any samples or thoughts on the best way to authenticate web socket connections with Spring Security OAuth tokens? Is using a channel interceptor the best place to validate OAuth tokens?

[spring-projects-issues]

Bobby Warner commented

I just realized that Spring Security OAuth supports URL params. I previously thought the access tokens had to be in the authorization header. Now that I know I can use regular params, I solved this by doing something this:

var url = "ws://localhost:8080/stomp?access_token=1234567890";
var client = Stomp.client(url);

Works great and I now have Spring Security OAuth working with Spring Web Sockets. This issue can be closed.

[spring-projects-issues]

Rossen Stoyanchev commented

OK good to know, thanks.

[spring-projects-issues]

Gregor Hollmig commented

Since sending sensitive data such as passwords/tokens over GET parameter is generally a bad idea (HTTP referrer leakage, server logs, ...) I would like to use the stomp headers for authorization.
Is there a way to access the STOMP headers like Bobby Warner described?

[spring-projects-issues]

Rossen Stoyanchev commented

You can configure a ChannelInterceptor on the "clientInboundChannel". See the docs.