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