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/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. > 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 cheers Niki > > > > > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> > For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
