Bob DeRemer wrote:
-----Original Message-----
From: Niki Dokovski [mailto:nick...@gmail.com]
Sent: Thursday, September 05, 2013 7:22 AM
To: Tomcat Users List
Subject: Re: Does JSR-356 provide a way for a client to pass security info on
connect?
On Thu, Sep 5, 2013 at 8:48 AM, Niki Dokovski <nick...@gmail.com> wrote:
On Thu, Sep 5, 2013 at 12:44 AM, Bob DeRemer
<bob.dere...@thingworx.com>wrote:
-----Original Message-----
From: André Warnier [mailto:a...@ice-sa.com]
Sent: Wednesday, September 04, 2013 3:59 PM
To: Tomcat Users List
Subject: Re: Does JSR-356 provide a way for a client to pass
security
info on
connect?
Bob DeRemer wrote:
I'm curious if there's anything defined in JSR-356 to enable a
client
to pass
some security claims in the connect that would allow me to perform
an
auth
check - prior to actually establishing the websocket connection.
In an attempt to avoid a websocket DOS, I'm looking to see
whether we
can
do an auth check in the ServerEndpoint onOpen (or, possibly at an
earlier
stage) - before the actual websocket gets established. I know we
can
do this at
the application level in the onMessage, but it'd be good to handle
this
before
setting up the actual websocket if possible.
From a not really websocket specialist :
As I recall, a websocket link starts with a normal HTTP request,
which
then gets
upgraded to a websocket connection. So it should be possible to do
AAA
at the
initial HTTP stage, no ?
From an earlier thread a couple of weeks (?) ago, it seems however
difficult to
retrieve some of that HTTP-level information later, when the
websocket connection is established.
Exactly what I am hoping to do: the WebSocket spec outlines the HTTP
Upgrade handshake process. During this handshake, a client should be
able to send additional HTTP headers for this exact purpose (i.e.
cookies, auth tokens, etc.). The server-side just needs an
application-level hook that can be called that can effectively link
into the pipeline - allowing/rejecting the establishment of the connection.
So, the big question(s):
1) does the tomcat client-side JSR impl provide a way to pass HTTP
headers in the initial upgrade handshake
Yes
background
http://docs.oracle.com/javaee/7/api/javax/websocket/ClientEndpointConf
ig.Configurator.html#beforeRequest(java.util.Map)
There is a mutuable headers map.
2) does the tomcat server-side JSR impl provide a way to hook into the
upgrade handshake and effectively allow/reject the connection
Yes and .... (need to check further :)) background
http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpo
intConfig.Configurator.html#modifyHandshake(javax.websocket.server.Ser
verEndpointConfig, javax.websocket.server.HandshakeRequest,
javax.websocket.HandshakeResponse)
JSR 356 Specification - 3.1.5 Handshake Modification I doesn't
particularly targets the rejection of the connection. The latter is
defined in http://tools.ietf.org/html/rfc6455#section-1.6 Security
Model. which simply uses the "origin" mechanism.
The status code of the response when connection should be dropped is 403
Forbidden defined by http://tools.ietf.org/html/rfc6455#section-4.2.2 which is
in relation to origin check.
The implementation in Tomcat calls checkOrigin either on the default
configurator or on a custom supplied one.
Take a look at org.apache.tomcat.websocket.server.UpgradeUtil doUpgrade
method
Awesome - I'll start looking into this today!
-thx, bob
And when you have done and solved the problem, would you be nice and post some summary on
the list as a conclusion to this thread ?
This way other people who would encounter the same issue later may find some useful
pointers to the solution.
(Or even better, write an article for the Tomcat WiKi)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
