SEC-2736: WebSocket Outbound Authorization

Rob Winch (Migrated from SEC-2736) said:

While it sounded like a simple goal for our 4.0 release, outbound security has a number of challenges that make it reasonable to push off. For example:

• What does it mean for an outbound channel to require the role ADMIN? Is it the user that sent the message or the user that is receiving the message that requires the role?
• How do transfer the user who sent the message across the broker securely?One idea is to place the user's spring-session-id in the headers and then retrieve the user. However, this would expose the spring-session-id of the user who sent the message to the user that is receiving the message.
• Outbound authorization will have a larger impact on performance since a single inbound message can trigger LOTS of outbound messages.
• We need to keep a stack of the SecurityContext since outbound messages can be nested. Specifically if we have:

   @MessageMapping("/im")
    public void im(InstantMessage im, @CurrentUser User currentUser) {
        im.setFrom(currentUser.getEmail());
        messagingTemplate.convertAndSendToUser(im.getTo(),"/queue/messages",im);
        // If using outbound security SecurityContextChannelInterceptor
        // would clear the SecurityContextHolder after the message is sent
        // meaning now the message is null
    }

NOTE: Working on this at https://github.com/rwinch/spring-session/tree/websocket-outbound https://github.com/rwinch/spring-security/tree/websocket-outbound

The issue names the @MessageMapping flow, messagingTemplate.convertAndSendToUser, and SecurityContextChannelInterceptor; start there and review the websocket-outbound branches in spring-session and spring-security. Resolve the stated questions about outbound roles, secure sender identity, performance, and nested SecurityContext handling. Done requires an agreed design and implementation, but no files or tests are identified.