Java Reference
In-Depth Information
There are two immediate considerations with security and WebSockets: restricting access
to authenticated users and encrypting traffic. A WebSocket endpoint is specified using
a URL and is thus secured via a security constraint in web.xml. For example, the We-
bSocket endpoint for customer service representatives (CSRs) is secured using the security
constraint in the following listing. The server endpoint is configured using the annotation
@ServerEndpoint(value="/support")
.
Listing 14.7. Securing a WebSocket endpoint
The configuration in this listing restricts access to the WebSocket endpoint at
/support
to only authenticated CSRs . This doesn't completely protect the endpoint. With
the default settings, all WebSocket communication would be transmitted in clear text.
Someone running a network sniffer could view the traffic and potentially even inject pack-
ets. For connections exchanging confidential communication, secure sockets should be
used. With secure sockets, the client opens the connection using the
wss:
prefix instead
of
ws:
. This will result in the connection being opened with HTTPS instead of HTTP. To
enable secure sockets, the following snippet is added to the preceding security constraint:
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
Now that you have a basic understanding of WebSockets, let's look at the two types of en-
dpoints.
