Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of nickytd@gmail.com designates
 74.125.82.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAN7Q5XQSA_5k+h9LMT+dBaPvemYz7J582qkQgVAuuojK1RUq1A@mail.gmail.com>
References: 
 <3695ae844bf1438ca3d0ac1ca7c6c906@BLUPR06MB193.namprd06.prod.outlook.com>
	<52279121.8000706@ice-sa.com>
	<a479b7654af34b33831d438429929cd2@BLUPR06MB193.namprd06.prod.outlook.com>
	<CAN7Q5XQSA_5k+h9LMT+dBaPvemYz7J582qkQgVAuuojK1RUq1A@mail.gmail.com>
Date: Thu, 5 Sep 2013 14:21:32 +0300
Message-ID: 
 <CAN7Q5XRmt9qU0JhRvim8PBWu4LfT-Xebfa1jSSh6MvJ32zokoQ@mail.gmail.com>
Subject: Re: Does JSR-356 provide a way for a client to pass security info on
 connect?
From: Niki Dokovski <nickytd@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: multipart/alternative; boundary=001a11c35472ce093104e5a11f6e

--001a11c35472ce093104e5a11f6e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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>w=
rote:
>
>>
>>
>> > -----Original Message-----
>> > From: Andr=E9 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 clien=
t
>> 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 w=
e
>> 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 thi=
s
>> 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 AA=
A
>> 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 ab=
le
>> to send additional HTTP headers for this exact purpose (i.e. cookies, au=
th
>> tokens, etc.).  The server-side just needs an application-level hook tha=
t
>> 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/ServerEndpoint=
Config.Configurator.html#modifyHandshake(javax.websocket.server.ServerEndpo=
intConfig,
> javax.websocket.server.HandshakeRequest, javax.websocket.HandshakeRespons=
e)
>
>
> JSR 356 Specification  - 3.1.5 Handshake Modification
> I doesn't particularly targets the rejection of the connection. The latte=
r
> 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 whic=
h
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-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
>>
>>
>

--001a11c35472ce093104e5a11f6e--