Hello all,
We haven't formally addressed how web sockets can be protected in a web
application, so I thought a good starting point for a discussion would
be to write up some ideas on how the existing web container security
model could apply to our web socket API. Please feel free to comment
and/or add ideas.
Primarily, the use case I am thinking at this point is of a web
application that contains some servlets/JSPs/web pages and also some web
socket endpoints. An example: a web site with freely available stock
information, a set of known users who can access protected information,
like their portfolios, together with dynamically updated information on
what's going on in the markets and in their portfolios.
The developer wants some of the web socket endpoints to be available
only to certain users.
We could define that web socket endpoints are covered by the Servlet
container security model in the following sense:-
1) a web socket endpoint can be made available only to certain users by
using a url-mapping, a list of allowed roles.
This means that if a user is already authenticated in the web
application and a web page containing web socket javascript attempts a
web socket opening handshake to the web socket endpoint at "/foo", the
web container should obtain the list of roles allowed access from the
url-mappings in the web application corresponding to "/foo", and check
if the user is in one of the roles. If so, the handshake proceeds, if
not the web socket handshake response returns with a 401.
If however, the user is not already authenticated, and the client sends
a web socket opening handshake for "/foo", then (to my knowledge) there
is no way to force an authentication at this point: neither does the web
socket spec define an authentication sequence within the handshake, nor
do the browsers allow a websocket handshake response to cause a redirect
to an http authentication dialog or page (please check my understanding
on that last point).
So we can apply the web container security model to protect web socket
endpoints and give fine grained control to users, but we are reliant on
the users to be pre-authenticated from a prior interaction with a
servlet/JSP/static *ML page for it to work.
In terms of where to make the configuration of authorization: it looks
reasonable to offer web socket developers the options of either doing so
in the web.xml in which their web socket endpoints are packaged, or by
using the servlet-defined annotations in their code (primarily
HttpConstraint).
2) a web socket endpoint can be deployed in the web container so that it
can only be accessed using a secure protocol i.e. wss:// only.
Here it looks like we could re-use the web container's concept of
transport-guarantee. Either offering developers the option of specifying
a transport guarantee on the URL to which the web socket endpoint is
mapped in the web.xml.
Finally, and we already touched on this, once the web application is in
use by a number of users, I think we need to following to be true:-
3) HttpSessions and active web sockets
a) we need to close web socket connections that are only for use by
authenticated users if the user explicitly logs out
(HttpSession.invalidate())
b) we need to be able to cause the HttpSession to stay alive even even
if the user makes no http requests for longer than the allocated
timeout. This is for the case when the user is busily using web sockets
by not reloading any of the http content.
I know how we can do a). I can't think of a great way of doing b) just
with the servlet API as it is today.
- Danny
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation