11:54 a.m.
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
1:05 p.m.
New subject: security and Http Upgrade/Websocket connection requests
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 -----
1:18 p.m.
New subject: security and Http Upgrade/Websocket connection requests
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:
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
2:24 p.m.
+1. Use HTTP for connection setup and auth...use any custom protocol
theereafter.
On 10/8/2013 2:18 PM, Jason Greene wrote:
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6 a.m.
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 -----
8:45 a.m.
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:
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:21 a.m.
Yes. Web socket connection are initiated by a filter, which is always the last filter in
the chain, so if you are using JSR-356 websockets the upgrade will only happen if all
servlet security rules are satisfied. So basically yes, if you secure your servlet app you
also secure websockets.
I was talking about the HTTP upgrade we do for Wildfly services, such as remote EJB and
management.
Stuart
4167
days inactive
4169
days old
6 comments
3 participants
participants (3)
-
Bill Burke -
Jason Greene -
Stuart Douglas