+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