Page History

...

 A detailed example demonstrating websocket configuration (using docker containers for simplicity) can be found here https://github.com/moresandeep/knox-dev-docker#demo-knox-dev-container–zeppelin

Security Consideration

WebSocket RFC does not define any specific way for servers to authenticate clients it leaves the choice to the application developers. As per the RFC, The WebSocket server can use any client authentication mechanism available to a generic HTTP server, such as cookies, HTTP authentication, or TLS authentication. 

The implication of this is that any WebSocket connection opened behind a secured (authenticated) page is not "automatically" secured, application developers have to take necessary steps to secure the WebSocket connection (along with the http page). for e.g. consider a simple WebSocket echo server proxied via Knox. When we make an HTTP request Knox will challenge for credentials

➜  ~ curl -ik https://localhost:8443/gateway/sandbox/echows
HTTP/1.1 401 Unauthorized
Date: Thu, 05 Oct 2017 21:24:45 GMT
WWW-Authenticate: BASIC realm="application"
Content-Length: 0
Server: Jetty(9.2.15.v20160210)

But one could directly use the WebSocket protocol to "bypass" Knox's security framework

➜  ~ wscat -n -c wss://localhost:8443/gateway/sandbox/echows
connected (press CTRL+C to quit)
> hello
< hello

This could be done in multiple ways, one way is to use the HTTP headers commonly used for authentication as used by web views. In Knox this support will be enabled as part of KNOX-895. It is difficult to customize WebSocket headers from Javascript as a result we are limited by implicit auth (Basic or Cookies) that browser uses. WebSocket servers could be separate from the webservers which makes shared authentication difficult or impossible. KNOX-773 will add support for Basic auth which could ease out some pain.

A "ticket" based authentication can be used by applications to handle the authentication problem, similar to what Zeppelin uses as the time or writing. In this method the client side talks to WebSocket server over HTTP, authenticates and obtains a security "ticket". WebSocket server issues this "ticket" and ties it to the user identity (e.g. username) this mapping is then stored in a cache. When the client connects via WebSocket it sends this "ticket" as part of the payload which the WebSocket server uses to verify the user identity and make sure the session is not expired.

Future work

KNOX-772 - Implement binary protocol support for Websocket feature

...