tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob DeRemer <bob.dere...@thingworx.com>
Subject RE: Does JSR-356 provide a way for a client to pass security info on connect?
Date Thu, 05 Sep 2013 16:32:04 GMT


> -----Original Message-----
> From: André Warnier [mailto:aw@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:nickytd@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 <nickytd@gmail.com> wrote:
> >>
> >>>
> >>>
> >>> 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/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-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
View raw message