Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

Code Block
➜  ~ 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, wss:// to "bypass" Knox's security framework which is based on servlet filters.

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

 

 

 

This WebSocket connection could be done secured 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 usesbrowsers use. 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 but until then use WebSocket with same caution as you would without Knox.

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.

...