Spring Integration 中的安全性

安全性是任何現代企業（或雲端）應用程式中的重要功能之一。此外，對於建立在企業整合模式之上的分散式系統而言，安全性至關重要。訊息傳遞的獨立性和鬆散耦合性讓目標系統能夠使用訊息 payload 中的任何資料類型相互通訊。我們可以信任所有這些訊息，或保護我們的服務免受「感染」訊息的侵害。

從 6.3 版本開始，整個 spring-integration-security 模組已被移除，以支持更常見的 spring-security-messaging 程式庫所提出的 API。

保護通道安全

為了保護整合流程中的訊息通道安全，必須將 AuthorizationChannelInterceptor 新增至這些通道，或者可以將其設定為具有相應模式的全域通道攔截器

Java
XML

@Bean
@GlobalChannelInterceptor(patterns = "secured*")
AuthorizationChannelInterceptor authorizationChannelInterceptor() {
    return new AuthorizationChannelInterceptor(AuthorityAuthorizationManager.hasAnyRole("ADMIN", "PRESIDENT"));
}

<channel-interceptor pattern="securedChannel*">
    <beans:bean class="org.springframework.security.messaging.access.intercept.AuthorizationChannelInterceptor">
        <beans:constructor-arg>
            <beans:bean class="org.springframework.security.authorization.AuthorityAuthorizationManager"
                        factory-method="hasAnyRole">
                <beans:constructor-arg>
                    <beans:array>
                        <beans:value>ADMIN</beans:value>
                        <beans:value>PRESIDENT</beans:value>
                    </beans:array>
                </beans:constructor-arg>
            </beans:bean>
        </beans:constructor-arg>
    </beans:bean>
</channel-interceptor>

有關更多資訊，請參閱全域通道攔截器設定。

安全性內容傳播

為了確保我們與應用程式的互動根據其安全性系統規則是安全的，我們應該提供一些安全性內容以及身份驗證（主体）物件。 Spring Security 專案提供了一種靈活、規範的機制，用於通過 HTTP、WebSocket 或 SOAP 協定（也可以通過簡單的 Spring Security 擴充功能對任何其他整合協定執行）驗證我們的應用程式用戶端。它還提供了 SecurityContext，用於對應用程式物件（例如訊息通道）進行進一步的授權檢查。預設情況下，SecurityContext 通過使用（ThreadLocalSecurityContextHolderStrategy）綁定到當前 Thread 的執行狀態。它由安全方法上的 AOP（面向切面程式設計）攔截器存取，以檢查（例如）調用主體的 principal 是否具有調用該方法的足夠權限。這在當前執行緒中運作良好。但是，通常處理邏輯可以在另一個執行緒、多個執行緒甚至外部系統上執行。

如果我們的應用程式建立在 Spring Integration 元件及其訊息通道之上，則標準的執行緒綁定行為很容易設定。在這種情況下，安全物件可以是任何服務啟動器或轉換器，這些物件在其 <request-handler-advice-chain> 中使用 MethodSecurityInterceptor 保護（請參閱為端點新增行為），甚至可以是 MessageChannel（請參閱前面的保護通道安全）。當使用 DirectChannel 通訊時，SecurityContext 會自動可用，因為下游流程在當前執行緒上執行。但是，在 QueueChannel、ExecutorChannel 和帶有 Executor 的 PublishSubscribeChannel 的情況下，訊息會根據這些通道的性質從一個執行緒傳輸到另一個（或多個）執行緒。為了支援這種情況，我們有兩種選擇

在訊息標頭中傳輸 Authentication 物件，並在另一端提取並驗證它，然後再存取安全物件。
將 SecurityContext 傳播到接收傳輸訊息的執行緒。

這在 spring-security-messaging 模組中實作為 org.springframework.security.messaging.context.SecurityContextPropagationChannelInterceptor，可以將其新增到任何 MessageChannel 或設定為 @GlobalChannelInterceptor。此攔截器的邏輯基於從當前執行緒（從 preSend() 方法）提取 SecurityContext，並從 postReceive() (beforeHandle()) 方法將其填充到另一個執行緒。有關更多資訊，請參閱 SecurityContextPropagationChannelInterceptor Javadocs。

SecurityContext 的傳播和填充只是工作的一半。由於訊息不是訊息流中執行緒的所有者，並且系統應確保其安全免受任何傳入訊息的侵害，因此必須從 ThreadLocal 中清除 SecurityContext。 SecurityContextPropagationChannelInterceptor 提供了 afterMessageHandled() 攔截器方法實作。它通過在調用結束時從該傳播的主體中釋放執行緒來執行清除操作。這表示，當處理移交訊息的執行緒完成處理訊息（成功與否）時，上下文將被清除，以便在處理另一個訊息時不會意外地使用它。

當使用非同步閘道時，您應該使用 Spring Security 並行支援中的適當 AbstractDelegatingSecurityContextSupport 實作，以確保在閘道調用中傳播安全性內容。以下範例示範了如何執行此操作

@Configuration
@EnableIntegration
@IntegrationComponentScan
public class ContextConfiguration {

    @Bean
    public AsyncTaskExecutor securityContextExecutor() {
        return new DelegatingSecurityContextAsyncTaskExecutor(
                         new SimpleAsyncTaskExecutor());
    }

}

@MessagingGateway(asyncExecutor = "securityContextExecutor")
public interface SecuredGateway {

    @Gateway(requestChannel = "queueChannel")
    Future<String> send(String payload);

}