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>
> To: "Jason Greene" <jason.greene(a)redhat.com>
> Cc: "Stuart Douglas" <sdouglas(a)redhat.com>,
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> 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>
>>>> 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
>