[callout title=2014 年 12 月 11 日更新]雖然最初是關於 Spring Security 4.0.0.M2，但部落格已更新，以反映 Spring Security 4.0 RC1 中的改進。[/callout]

簡介

以前，應用程式可以使用 Spring Security 在 WebSocket 應用程式中執行身份驗證。 這是可行的，因為 HttpServletRequest 的 Principal 將傳播到 WebSocket 會話。

問題是授權僅限於握手階段。 這意味著一旦建立連線，就無法為 WebSocket 應用程式的授權提供任何粒度。

使用 Spring Security 的訊息傳遞支援

Spring Security 4.0.0.RC2 透過 Spring Messaging 抽象引入了對 WebSockets 的授權支援。 要提供授權，只需擴充套件 AbstractSecurityWebSocketMessageBrokerConfigurer 並配置 MessageSecurityMetadataSourceRegistry。 例如

public class WebSocketSecurityConfig extends
          AbstractSecurityWebSocketMessageBrokerConfigurer {
    protected void configureInbound(MessageSecurityMetadataSourceRegistry messages) {
      messages
        . simpDestMatchers("/user/queue/errors").permitAll()
        . simpDestMatchers("/**").hasRole("ADMIN");
      }
  }

[callout title=直接 JSR-356 支援]我們一直在考慮直接與 JSR-356 整合。 然而，目前這非常困難，因為 JSR-356 非常底層，目前沒有提供必要的抽象。[/callout]

這將確保

• 任何使用者都可以訪問 /user/queue/errors 目標
• 任何包含目標標頭的其他訊息只能由具有 ROLE_ADMIN 角色的使用者訪問

XML 名稱空間支援

類似地，我們可以使用 Spring Security XML 名稱空間支援定義上述配置。 等效的配置是

<websocket-message-broker>
    <!-- pattern matches on the destination header -->
    <intercept-message pattern="/user/queue/errors" access="permitAll" />
    <intercept-message pattern="/**" access="hasRole('ROLE_ADMIN')" />
</websocket-message-broker>

方法安全和 WebSockets

我們還可以將方法安全性與 WebSockets 結合使用。 例如，以下方法只能由具有 ROLE_ADMIN 角色的使用者呼叫

	@PreAuthorize("hasRole('ROLE_ADMIN')")
	@MessageMapping("/trade")
	public void executeTrade(Trade trade, Principal principal) {

示例應用程式

您可以在 rwinch/spring-websocket-portfolio 的 security 分支中找到完整的授權示例。

下一步是什麼？

雖然這解決了我們的授權問題，但我們仍然缺少一種在透過 WebSockets 傳送訊息時保持 HttpSession 活動狀態的良好機制。 在下一篇文章中，我將更詳細地討論這些問題是什麼，以及 Spring Session 如何緩解這些問題。

[callout title=SpringOne 2GX 2014 即將到來]儘快在達拉斯（德克薩斯州）預訂 SpringOne 的位置，時間為 9 月 8 日至 11 日。 這絕對是瞭解所有最新動態並提供直接反饋的最佳機會。 從 0 到 Spring Security 4.0 會議將包含有關如何開始使用 Spring Security 的詳細資訊，並深入探討 Spring Security 4 中的新功能。當然，還有許多其他 令人興奮的 Spring 相關演講！[/callout]