認証

すべての STOMP over WebSocket メッセージングセッションは、HTTP リクエストで始まります。これは、WebSockets（つまり、WebSocket ハンドシェイク）へのアップグレードリクエスト、または SockJS フォールバックの場合は、一連の SockJS HTTP トランスポートリクエストです。

多くの Web アプリケーションには、HTTP リクエストを保護するための認証と認可がすでに用意されています。通常、ユーザーは、ログインページ、HTTP 基本認証などのメカニズムを使用して、Spring Security を介して認証されます。認証されたユーザーのセキュリティコンテキストは HTTP セッションに保存され、同じ Cookie ベースのセッションの後続のリクエストに関連付けられます。

WebSocket ハンドシェイクまたは SockJS HTTP トランスポートリクエストの場合、通常、HttpServletRequest#getUserPrincipal() を介してアクセス可能な認証済みユーザーがすでに存在します。Spring は、そのユーザーを、そのユーザー用に作成された WebSocket または SockJS セッションに自動的に関連付け、その後、ユーザーヘッダーを通じてそのセッションを介して転送されるすべての STOMP メッセージに関連付けます。

要するに、典型的な Web アプリケーションは、セキュリティのためにすでに行っていること以上のことは何もする必要がないのです。ユーザーは HTTP リクエストのレベルで、クッキーベースの HTTP セッション（そのユーザーのために作成された WebSocket または SockJS セッションと関連付けられる）を通じて維持されるセキュリティコンテキストによって認証され、結果としてアプリケーションを流れるすべての Message にユーザーヘッダーがスタンプされることになります。

STOMP プロトコルには、CONNECT フレームに login および passcode ヘッダーがあります。これらは元々、STOMP over TCP 用に設計されており、必要です。ただし、WebSocket を介した STOMP の場合、デフォルトでは、Spring は STOMP プロトコルレベルの認証ヘッダーを無視し、ユーザーが HTTP トランスポートレベルですでに認証されていると想定します。WebSocket または SockJS セッションに認証されたユーザーが含まれていることが期待されます。