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

簡介

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

問題在於授權僅限於握手。 這表示一旦建立連線，就無法為 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]