tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niki Dokovski <nick...@gmail.com>
Subject Re: Does JSR-356 provide a way for a client to pass security info on connect?
Date Thu, 05 Sep 2013 05:48:35 GMT
On Thu, Sep 5, 2013 at 12:44 AM, Bob DeRemer <bob.deremer@thingworx.com>wrote:

>
>
> > -----Original Message-----
> > From: André Warnier [mailto:aw@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/ClientEndpointConfig.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/ServerEndpointConfig.Configurator.html#modifyHandshake(javax.websocket.server.ServerEndpointConfig,
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.






> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message