> -----Original Message----- > From: André Warnier [mailto:a...@ice-sa.com] > Sent: Thursday, September 05, 2013 10:04 AM > To: Tomcat Users List > Subject: Re: Does JSR-356 provide a way for a client to pass security info on > connect? > > 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/ClientEndpointCo > >>> nf > >>> 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/ServerEnd > >>> po > >>> intConfig.Configurator.html#modifyHandshake(javax.websocket.server.S > >>> er 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)
Absolutely, would love to! > > --------------------------------------------------------------------- > 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
