> -----Original Message----- > From: Bob DeRemer [mailto:bob.dere...@thingworx.com] > Sent: Tuesday, September 10, 2013 8:56 AM > To: Tomcat Users List > Subject: RE: solution - RE: how to access HTTP response from jsr-356 > ServerEndpointConfig.Configurator.modifyHandshake? > > > > > -----Original Message----- > > From: André Warnier [mailto:a...@ice-sa.com] > > Sent: Tuesday, September 10, 2013 6:12 AM > > To: Tomcat Users List > > Subject: Re: solution - RE: how to access HTTP response from jsr-356 > > ServerEndpointConfig.Configurator.modifyHandshake? > > > > Bob DeRemer wrote: > > > > > >> -----Original Message----- > > >> From: Bob DeRemer [mailto:bob.dere...@thingworx.com] > > >> Sent: Monday, September 09, 2013 1:30 PM > > >> To: Tomcat Users List > > >> Subject: RE: how to access HTTP response from jsr-356 > > >> ServerEndpointConfig.Configurator.modifyHandshake? > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: Niki Dokovski [mailto:nick...@gmail.com] > > >>> Sent: Monday, September 09, 2013 1:11 PM > > >>> To: Tomcat Users List > > >>> Subject: Re: how to access HTTP response from jsr-356 > > >>> ServerEndpointConfig.Configurator.modifyHandshake? > > >>> > > >>> On Mon, Sep 9, 2013 at 5:26 PM, Bob DeRemer > > >>> <bob.dere...@thingworx.com>wrote: > > >>> > > >>>> Thanks for the direction on using the respective Client/Server > > >>>> EndpointConfig.Configurator plumbing to do a pre-connection AUTH. > > >>>> Unfortunately, I'm stuck on the server side when trying to > > >>>> actually modify the HTTP response result code from within the > Configurator. > > >>>> It doesn't appear that the HandshakeResponse [or anything else > > >>>> that I could see] provides access to modify the actual HTTP > > >>>> response - setting it to > > >>> 403 if > > >>>> the AUTH fails. In fact, from looking at the UpgradeUtil.doUpgrade, > > >>>> it > > >>>> seems that the decision to upgrade has already been made by the > > >>>> time the modifyHandshake override gets called. > > >>>> > > >>> Yes the decision is'already made at that point. In this version of > > >>> the spec and current implementation, the only place to actully > > >>> provide different status code (aka 403) is when checkOrigin returns > > >>> false. > > >>> http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerE > > >>> nd > > >>> po > > >>> intC > > >>> onfig.Configurator.html#checkOrigin(java.lang.String) > > >>> > > >>> I don't know wether this works in your case, but for sure the next > > >>> spec revision could try to provide more application control in > > >> "modifyHandshake" > > >> checkOrigin would work if there was some way to gain access to the > > >> client supplied headers. Is there any way for my checkOrigin > > >> method to get access to the calling request and associated HTTP > > >> headers? If not, then I'm not sure how to perform a pre-connected > > >> AUTH check based > > on the current implementation. > > >> > > >> if there are any other suggestions, please LMK; meanwhile, I'll > > >> keep digging to see if there's another solution. > > >> > > >> Thx,bob > > >> > > > > > > After looking at the options available and going through the > > > websocket > > protocol specification again, I've found a better solution for > > authenticating using a JSR-356 implementation than the original > > concept of using ServerEndpointConfig.Configurator.modifyHandshake. > > The new approach still uses custom Client and Server > > EndpointConfig/Configurator instances to pass security information > > during the handshake, but instead of rejecting the handshake, it's > > cleaner to grab the security information in the OnOpen (from the > > ServerEndpointConfig) of the actual endpoint. At this point, simply > > perform whatever AAA you wish - calling close with an appropriate > CloseReason if AAA fails. > > > > > > With regard to DOS and opening websocket connections: > > > > > > The websocket protocol already prohibits multiple clients from being > > > in the > > connecting/handshake phase at once, which already helps reduce the DOS > > surface area. In addition, the client and/or server side > > implementations can add additional logic to prohibit the number of > > concurrent connections from the same client endpoint based on > configuration. > > > > > > And, yes, once I get it done and tested, I'll write this up. > > > > > > > Hi. > > I have been watching this a bit from the outside, and I am neither a > > Java nor a Tomcat nor a websocket expert. > > But I am wondering a bit if we are not here missing the forest for the > > trees, in the following sense : > > If I understand correctly the issue at hand, it would be about > > 1) preventing DoS attacks by "protecting" the websocket interface by a > > prior AAA phase > > 2) how to do this AAA phase > > > > When I read through the JSR-356, it looks to me more concerned about > > what happens while the websocket connection is actually open, than > > about what precedes it. > > And when I read the websocket RFC-6455, it seems to me that at least > > in terms of the intent, the websocket connection is established - from > > the server point of view - when the server returns a 101 response > > status. And anything before that is part of the "initial handshake", > > which as far as I understand it is purely HTTP and includes anything to do > > with > AAA. > > > > See RFC-6455 : > > > > 4. Opening Handshake > > 4.1. Client Requirements > > ... > > 12. The request MAY include any other header fields, for example, > > cookies [RFC6265] and/or authentication-related header fields > > such as the |Authorization| header field [RFC2616], which are > > processed according to documents that define them. > > > > Once the client's opening handshake has been sent, the client MUST > > wait for a response from the server before sending any further data. > > The client MUST validate the server's response as follows: > > > > 1. If the status code received from the server is not 101, the > > client handles the response per HTTP [RFC2616] procedures. In > > particular, the client might perform authentication if it > > receives a 401 status code; the server might redirect the client > > using a 3xx status code (but clients are not required to follow > > them), etc. Otherwise, proceed as follows. > > > > ... > > > > In JSR-356, there is similarly : > > > > 8.1 Authentication of Websockets > > This specification does not define a mechanism by which websockets > > themselves can be authenticated. Rather, by building on the servlet > > defined security mechanism, a websocket that requires authentication > > must rely on the opening handshake request that seeks to initiate a > > connection to be previously authenticated. Typically, this will be > > performed by a Http authentication (perhaps basic or form-based) in > > the web application containing the websocket prior to the opening handshake > to the websocket. > > > > In other words, I am a bit confused as to why there would need to be a > > need for any websocket application to be able to either access the > > client-sent authentication headers, cookies etc.., or why it should be > > possible to the websocket application to trigger the sending of a HTTP 4xx > response. > > > > This should all already have happened at the initial HTTP handshake > > phase, and should not be a concern for the websocket interface itself. > > It may be nice for the websocket application later on to have read > > access to the (or some) headers sent by the client during the initial > > handshake, but this does not look like a requirement. > > > > Or am I in turn missing something ? > > > > Hi Andre, > > I see what you mean and believe using an HTTP-based auth approach may work > in some scenarios. I'm not sure if this would work in one of our primary > scenarios, which is dealing with many real-world devices that do not have a > UI, > so basic/form authentication isn't an option. That said, I will have to see > if I can > use a standard Filter approach in front of our websocket endpoints. If I can > programmatically add an auth filter, then I may be able to perform the auth > check in the same manner as we do for our stand HTTP-based REST api. > > Thx, bob
It appears I can call addFilter dynamically when my webapp starts up and front-end the websocket endpoint with a Filter - processing the initial HTTP request completely before any websocket communication is involved Thanks for causing me to pull up from the weeds and look at this from another angle! -bob > > > > --------------------------------------------------------------------- > > 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
