Yes. If there is any security rules defined the security handler takes effect before the upgrade, so if the request is not authorised the upgrade will not go ahead. Web socket wise it is possible to get the authenticated principal from io.undertow.websockets.jsr.UndertowSession#getUserPrincipal() (assuming you are using JSR-356 web sockets). For built in HTTP upgrades such as EJB etc we leave authentication to remoting, after the connection has already been upgraded. Stuart ----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: undertow-dev(a)lists.jboss.org > Sent: Tuesday, 8 October, 2013 6:54:14 PM > Subject: [undertow-dev] security and Http Upgrade/Websocket connection requests > > Are we going to be able to authenticate/authorize HTTP Upgrade/Websocket > connection requests throw Undertow handlers and/or the new Servlet API? > > Thanks > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > _______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Jason Greene" <jason.greene(a)redhat.com&gt; Cc: "Stuart Douglas" <sdouglas(a)redhat.com&gt;, undertow-dev(a)lists.jboss.org Sent: Tuesday, 8 October, 2013 9:24:07 PM Subject: Re: [undertow-dev] security and Http Upgrade/Websocket connection requests +1. Use HTTP for connection setup and auth...use any custom protocol theereafter. On 10/8/2013 2:18 PM, Jason Greene wrote: > IMO we should explore moving the auth portion to HTTP. We could implement > some kind of trust relationship between the protocol provider and the > upgrade handler. This would have the nice benefit of giving consistent > authentication capabilities to all protocols we support (e.g. including > non-Remoting protocols like HornetQ) > > On Oct 8, 2013, at 1:05 PM, Stuart Douglas <sdouglas(a)redhat.com&gt; wrote: > >> Yes. If there is any security rules defined the security handler takes >> effect before the upgrade, so if the request is not authorised the >> upgrade will not go ahead. >> >> Web socket wise it is possible to get the authenticated principal from >> io.undertow.websockets.jsr.UndertowSession#getUserPrincipal() (assuming >> you are using JSR-356 web sockets). >> >> For built in HTTP upgrades such as EJB etc we leave authentication to >> remoting, after the connection has already been upgraded. >> >> Stuart >> >> ----- Original Message ----- >>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>> To: undertow-dev(a)lists.jboss.org >>> Sent: Tuesday, 8 October, 2013 6:54:14 PM >>> Subject: [undertow-dev] security and Http Upgrade/Websocket connection >>> requests >>> >>> Are we going to be able to authenticate/authorize HTTP Upgrade/Websocket >>> connection requests throw Undertow handlers and/or the new Servlet API? >>> >>> Thanks >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

Not sure what you are saying. At the WAR level, can I secure HTTP Upgrade requests in the same way I secure any other HTTP traffic? I want to be able to have per-deployment Undertow handlers that hook in our security plugins so that we can secure both HTTP and Websocket connections.

On 10/10/2013 7:00 AM, Stuart Douglas wrote: > The big problem with this is that is means the authentication process is > different depending on if HTTP upgrade is in use or not. At the moment the > HTTP upgrade is basically transparent, the connection behaves exactly the > same no matter which authentication mechanism is in use. > > Another problem is that if multiple protocols are being upgraded then each > one might have separate authentication requirements, e.g. if we do single > port mode then management connections will have a different authentication > requirements to EJB connections. > > None of these problems are insurmountable, however there is a lot of work > involved and there is no way it will get done in time for WF8, especially > because it does not really buy us anything we don't already have. > > Stuart > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: "Jason Greene" <jason.greene(a)redhat.com&gt; >> Cc: "Stuart Douglas" <sdouglas(a)redhat.com&gt;, undertow-dev(a)lists.jboss.org >> Sent: Tuesday, 8 October, 2013 9:24:07 PM >> Subject: Re: [undertow-dev] security and Http Upgrade/Websocket connection >> requests >> >> +1. Use HTTP for connection setup and auth...use any custom protocol >> theereafter. >> >> On 10/8/2013 2:18 PM, Jason Greene wrote: >>> IMO we should explore moving the auth portion to HTTP. We could implement >>> some kind of trust relationship between the protocol provider and the >>> upgrade handler. This would have the nice benefit of giving consistent >>> authentication capabilities to all protocols we support (e.g. including >>> non-Remoting protocols like HornetQ) >>> >>> On Oct 8, 2013, at 1:05 PM, Stuart Douglas <sdouglas(a)redhat.com&gt; wrote: >>> >>>> Yes. If there is any security rules defined the security handler takes >>>> effect before the upgrade, so if the request is not authorised the >>>> upgrade will not go ahead. >>>> >>>> Web socket wise it is possible to get the authenticated principal from >>>> io.undertow.websockets.jsr.UndertowSession#getUserPrincipal() (assuming >>>> you are using JSR-356 web sockets). >>>> >>>> For built in HTTP upgrades such as EJB etc we leave authentication to >>>> remoting, after the connection has already been upgraded. >>>> >>>> Stuart >>>> >>>> ----- Original Message ----- >>>>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>>>> To: undertow-dev(a)lists.jboss.org >>>>> Sent: Tuesday, 8 October, 2013 6:54:14 PM >>>>> Subject: [undertow-dev] security and Http Upgrade/Websocket connection >>>>> requests >>>>> >>>>> Are we going to be able to authenticate/authorize HTTP >>>>> Upgrade/Websocket >>>>> connection requests throw Undertow handlers and/or the new Servlet API? >>>>> >>>>> Thanks >>>>> >>>>> -- >>>>> Bill Burke >>>>> JBoss, a division of Red Hat >>>>> http://bill.burkecentral.com >>>>> _______________________________________________ >>>>> undertow-dev mailing list >>>>> undertow-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>>> >>>> _______________________________________________ >>>> undertow-dev mailing list >>>> undertow-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>> >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com