Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      In JavaEE 7 we have some security problems with WebSocket.

      An authenticated session, with a valid Session.getUserPrincipal()
      doesn't authenticates in the container on websocket events, so EJB / CDI calls are unauthenticated.

      I've tested with WildFly 8.2.0 and GlassFish 4.1, with a sample app
      which calls EJB methods from @onOpen, @onClose and @onMessage.

      Although we can workaround these issues with interceptors and vendor
      specific security managers, it's a common use case for JavaEE applications and an important requirement for cloud/SaaS applications.

      I've created an open-source library to get workaround these problems in
      JBoss/WildFly. It's called "JBoss Security Extended" and is available on maven central with GAV "com.github.panga:jboss-security-extended:1.0.0".

      Library source and docs:
      https://github.com/panga/jboss-security-extended
      WebSocket sample app source using library:
      https://github.com/panga/websocket-auth

        Issue Links

          Activity

          Hide
          Pavel Bucek added a comment -

          not sure whether this is a direct duplicate or just consequence of WEBSOCKET_SPEC-197. Anyway, I don't see what WebSocket spec can do here - if you have to call proprietary APIs to achieve what you want, we cannot really make that a requirement for all implementations, since that would imply tight integration with single CDI implementation.

          Show
          Pavel Bucek added a comment - not sure whether this is a direct duplicate or just consequence of WEBSOCKET_SPEC-197 . Anyway, I don't see what WebSocket spec can do here - if you have to call proprietary APIs to achieve what you want, we cannot really make that a requirement for all implementations, since that would imply tight integration with single CDI implementation.
          Hide
          panga added a comment -

          I think it's consequence of WEBSOCKET_SPEC-197 and it answers the question 4 of that issue "Is the caller Principal passed on to EJB from WebSocket (I think the answer is yes)?"

          The answer is No.

          I only need call proprietary API to workaround the problem because spec doesn't cover Websocket vs CDI/EJB integration.

          Containers should care about websocket integration with Java EE, not the implementations (Tyrus / Undertow).

          Show
          panga added a comment - I think it's consequence of WEBSOCKET_SPEC-197 and it answers the question 4 of that issue "Is the caller Principal passed on to EJB from WebSocket (I think the answer is yes)?" The answer is No. I only need call proprietary API to workaround the problem because spec doesn't cover Websocket vs CDI/EJB integration. Containers should care about websocket integration with Java EE, not the implementations (Tyrus / Undertow).
          Hide
          tremes added a comment -

          Hi,
          I am not 100% sure I understand this issue correctly but I think it's related to https://issues.jboss.org/browse/WELD-2028. This should be IMO clarified.

          Show
          tremes added a comment - Hi, I am not 100% sure I understand this issue correctly but I think it's related to https://issues.jboss.org/browse/WELD-2028 . This should be IMO clarified.
          Hide
          panga added a comment -

          You're right, but it's the container responsibility to integrate WebSocket with JAAS, there's nothing to do in WELD, because EJBs are also affected.

          I have a test case attached with the issue.

          Show
          panga added a comment - You're right, but it's the container responsibility to integrate WebSocket with JAAS, there's nothing to do in WELD, because EJBs are also affected. I have a test case attached with the issue.
          Hide
          arjan tijms added a comment -

          You're right, but it's the container responsibility to integrate WebSocket with JAAS,

          Note that JAAS is not the universal Java EE security framework. In fact, almost nothing in Java EE refers to JAAS, which is itself a Java SE framework from which Java EE only uses a minimal number of types. What you're probably looking for here is the integration of WebSocket with the native security internals of Servlet, EJB and JCA, such that the authenticated identity (the native, vendor specific implementation of it) propagates to WebSocklet.

          Servlet, EJB and JCA may use something JAAS based for the initial authentication, but there is no requirement for that and its just an implementation detail. JASPIC does define a bridge profile for JAAS LoginModules, but that is fully optional.

          As we're planning to define a (injectable) SecurityContext in the Java EE security EG that is intended to be used "everywhere", it would be great if we could somehow include WebSockets here. One thing to take into account here is that establishing an authenticated identity is only really specified for Servlet and SOAP, and is primarily per request. The authentication mechanism (e.g FORM or BASIC) has to be aware of the session. In other words, the authenticated identity doesn't automatically stick to the HTTP session.

          Show
          arjan tijms added a comment - You're right, but it's the container responsibility to integrate WebSocket with JAAS, Note that JAAS is not the universal Java EE security framework. In fact, almost nothing in Java EE refers to JAAS, which is itself a Java SE framework from which Java EE only uses a minimal number of types. What you're probably looking for here is the integration of WebSocket with the native security internals of Servlet, EJB and JCA, such that the authenticated identity (the native, vendor specific implementation of it) propagates to WebSocklet. Servlet, EJB and JCA may use something JAAS based for the initial authentication, but there is no requirement for that and its just an implementation detail. JASPIC does define a bridge profile for JAAS LoginModules, but that is fully optional. As we're planning to define a (injectable) SecurityContext in the Java EE security EG that is intended to be used "everywhere", it would be great if we could somehow include WebSockets here. One thing to take into account here is that establishing an authenticated identity is only really specified for Servlet and SOAP, and is primarily per request. The authentication mechanism (e.g FORM or BASIC) has to be aware of the session. In other words, the authenticated identity doesn't automatically stick to the HTTP session.

            People

            • Assignee:
              Unassigned
              Reporter:
              panga
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: