HTML and CSS Reference
In-Depth Information
The cables at the bottom of the figure show that the same is true for WebSocket
Secure (WSS) connectivity. The WebSocket (WS) protocol runs on TCP (like HTTP), and
the WSS connection runs on TLS, which, in turn, runs on TCP. The WebSocket Protocol
is compatible with HTTP such that the WebSocket connection uses the same ports: the
WebSocket default port is 80 and WebSocket Secure (WSS) uses port 443 by default.
Authentication
To confirm the identity of users connecting to our servers via WebSocket, WebSocket
handshakes can include cookie headers. Using cookie headers allows servers to use the
same cookies for WebSocket authentication that are used to authenticate HTTP requests.
At the time of writing this topic, browsers do not allow other forms of HTTP
authentication from the WebSocket API. Interestingly, the API does not disallow these
mechanisms; they just won't work with browsers. If a server responds to a WebSocket
upgrade request with status 401 Authentication Required, for instance, the browser will
simply close the WebSocket connection. The assumption in this model is that users will
have already logged into an application via HTTP before that application attempts to
open a WebSocket connection.
Alternatively, authentication could take place over the application layer protocol
after the WebSocket upgrade has completed. Protocols such as XMPP and STOMP have
semantics for identifying users and exchanging credentials built into those layers. One
could deploy unauthenticated WebSockets but require authentication at the next protocol
layer. In the following section, Application Level Security, we discuss how authorization
can be enforced at the application protocol level, as well.
Application Level Security
Application Level Security dictates how applications can protect themselves from
attacks that may expose private information. This level of security protects the resources
exposed by the application. You can take advantage of application level security on your
WebSocket-based system if you are using a standard protocol such as XMPP, STOMP, or
Advanced Message Queueing Protocol (AMQP). Configuring permissions is specific to
the server.
In Chapter 5, we used the Apache ActiveMQ message broker to illustrate how to build
applications using STOMP over WebSocket. Here, we'll continue to build upon the ActiveMQ
configuration and restrict access to its resources, and we'll do so by implementing security to
the sample WebSocket application that ships with Apache ActiveMQ.
In this section, we review two application security measures. First, we take a look
at a simple authentication plugin that requires users to authenticate themselves before
accessing ActiveMQ. Then, we take a look at how to configure authorization to protect
specific queues and topics.
Before we get started, let's make sure that you can access the demo without
providing credentials to ensure you don't already have application authentication and
authorization configured. Using the following command, start ActiveMQ:
$> bin/activemq console
