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