Authentication

모든 STOMP over WebSocket 메시징 세션은 HTTP 요청으로 시작합니다. 이는 WebSockets로 업그레이드하기 위한 요청(즉, WebSocket 핸드셰이크)일 수도 있고, SockJS 폴백의 경우에는 일련의 SockJS HTTP 전송 요청일 수도 있습니다.

많은 웹 애플리케이션은 이미 HTTP 요청을 보호하기 위한 인증과 인가를 구현해 두고 있습니다. 일반적으로 사용자는 로그인 페이지, HTTP Basic 인증 또는 다른 방식과 같은 메커니즘을 사용하여 Spring Security를 통해 인증됩니다. 인증된 사용자를 위한 시큐리티 컨텍스트는 HTTP 세션에 저장되며, 동일한 쿠키 기반 세션에 있는 이후의 요청들과 연관됩니다.

따라서 WebSocket 핸드셰이크나 SockJS HTTP 전송 요청의 경우, 일반적으로 HttpServletRequest#getUserPrincipal()을 통해 접근 가능한 이미 인증된 사용자가 존재합니다. Spring은 그 사용자와 그를 위해 생성된 WebSocket 또는 SockJS 세션을 자동으로 연관시키고, 이어서 해당 세션을 통해 전송되는 모든 STOMP 메시지와 user 헤더를 연관시킵니다.

요약하면, 일반적인 웹 애플리케이션은 시큐리티를 위해 이미 하고 있는 것 외에 추가로 아무 것도 할 필요가 없습니다. 사용자는 쿠키 기반 HTTP 세션을 통해 유지되는 시큐리티 컨텍스트와 함께 HTTP 요청 수준에서 인증되며(이는 그 사용자를 위해 생성된 WebSocket 또는 SockJS 세션과 연관되고), 그 결과 애플리케이션을 흐르는 모든 Message에 user 헤더가 찍히게 됩니다.

STOMP 프로토콜에는 CONNECT 프레임에 login과 passcode 헤더가 있습니다. 이는 원래 STOMP over TCP를 위해 설계되었으며, 그 경우에는 필요합니다. 그러나 STOMP over WebSocket의 경우, 기본적으로 Spring은 STOMP 프로토콜 수준의 authentication 헤더를 무시하고, 사용자가 이미 HTTP 전송 수준에서 인증되어 있다고 가정합니다. 기대되는 바는 WebSocket 또는 SockJS 세션이 인증된 사용자를 포함하고 있다는 것입니다.