WebSphere Message Broker（簡稱 Message Broker）作為企業級的整合中間件和服務總線，提供了廣泛的連接性，支持包括 MQ、HTTP、FTP、web services、CICS 等幾十種不同的傳輸方式和協議。在安全方面，每種協議都有各自的用戶身份信息傳輸方式和處理方式。
在介紹 Message Broker 的安全驗證和訪問控制之前，讓我們簡單看看幾種常用的通訊和傳輸協議的相關安全規范與標准。
超文本傳輸協議（HTTP，Hypertext transfer protocol）定義了浏覽器和 WEB 服務器之間的數據交互規范，是所有 WEB 應用程序的通訊標准。
HTTP 協議的安全信息傳遞和驗證標准有許多種，包括 HTTP Basic，Digest 等等。其中，最常見的是 HTTP Basic 標准。它由 HTTP 1.0/1.1 的規范定義，所有主流的浏覽器都支持該標准。在傳輸上，它將用戶名和密碼使用 BASE64 方式編碼後，添加到 HTTP 頭的 Authorization 屬性中。對方收到請求後，從消息頭的 Authorization 屬性中解析出用戶信息。
其中，d2FuZ2xpOndhbmdsaQ==就是用戶名和密碼加密後的字符串。
HTTP Basic 的方式最簡單，它不要求服務端保留會話的狀態，也不需要其它額外的組件，這非常適合於 Message Broker 的應用場景。為了通用性和處理無關性， Message Broker 通常都會設計為無狀態模式，不保留會話信息，如果需要安全驗證，就要求每次 HTTP 請求都攜帶安全驗證信息。而使用 HTTP Basic，可以在所有請求頭中都加入編碼後的用戶身份信息。
但 HTTP Basic 對用戶名和密碼只是簡單編碼，安全性不高。如果需要更高的安全性，可以使用 HTTPS 的安全傳輸方式，保證用戶名和密碼在傳輸過程中不被竊取。
WebSphere MQ 的消息分為消息頭和消息體兩部分。其中，消息頭由若干用於描述消息的屬性組成，是固定的，不允許擴展。在消息頭中，與安全有關的屬性只有用戶標識（User）一個，並且限制最長 12 位字符。但沒有用於存放密碼的屬性。
因此，如果遵循 MQ 的消息頭標准，就只能傳遞用戶名信息，且用戶名需要小於或等於 12 個字符。如果要求更完備的用戶身份信息（例如用戶名 + 密碼），就需要在 MQ 的消息正文中定義。
Java 消息服務（JMS，Java Message Service）是 Java EE 規范定義的標准 API 接口，用於訪問不同的消息中間件，例如 WebSphere MQ、SonicMQ 等。JMS 也將消息分為消息頭和消息體，但與 MQ 不同的是，JMS 允許自定義消息頭，將用戶名和密碼（或者加密後的密碼）放入消息頭的指定屬性。（如果 JMS 底層訪問的是 WebSphere MQ，自定義的消息頭其實也位於 MQ 的消息正文中）
不論是 MQ 還是 JMS，都可以將用戶信息放在消息頭的某個屬性中，但並沒有類似 HTTP Basic 的標准或規范。當然，也可以在定義消息的數據格式時，將安全信息定義在消息正文中。
Web service 使用簡單對象訪問協議（SOAP，Simple Object Access Protocol）進行通訊，但 SOAP 定義的是數據交互的標准，在底層仍然使用 HTTP 協議或 JMS 作為傳輸協議。
最初 Web Service 並沒有與安全相關的規范和標准，大家就借用底層傳輸協議的安全機制。例如，如果使用 HTTP 作為 Web Service 的傳輸協議，就使用 HTTP Basic 的安全驗證方式；如果使用 JMS 作為 Web Service 的傳輸協議，則將用戶身份信息寫入 JMS 的消息頭。當前，新開發的應用已經不再使用這種老的安全機制了，但仍然有不少老系統還在用。
這種依賴具體傳輸協議的安全方式非常不利於程序的通用化，隨著 Web Service 的不斷發展，大家就提出了 WS-Security 協議規范。WS-Security 將用戶身份信息從傳輸協議中抽取到 SOAP 消息中，並具體提出了 SOAP 頭的相關定義標准。這樣，用戶信息的傳遞就被提升到 SOAP 協議中，不論 Web Service 底層使用的通訊協議是 HTTP 協議還是 JMS 協議，都是相同的處理方式。
如上所示，安全元素 <wsse:Security> 位於 SOAP 請求頭（Header）部分。這個示例是 WS-Security 規范定義的最簡單的用戶令牌形式（UsernameToken），只包含用戶名和密碼元素，並且全部明文傳輸，沒有加密。WS-Security 規范非常靈活，有為了適用於不同的情況，WS-Security 定義了不同的令牌形式，包括 UsernameToken，以及 X.509 Certificate Token，SAML Token，LTPA Token 等。另外，WS-Security 還支持不同的報文加密方式和數字簽名方式。
WS-Security 規范非常繁雜，通常需要借助第三方類庫才能實現對其的全面支持。
因此，對於 Web Service 協議，有兩種安全處理標准，一種是借助底層的 HTTP 或 JMS 協議的處理標准，另一種是遵循 WS-Security 的處理標准，WS-Security 標准中又包括了許多種安全令牌方式和加密，處理方式。
以上只是三種常見協議的安全信息傳輸和處理規范，已經非常之復雜，需要學習不同的協議標准，熟悉不同的協議 API，才能完成安全控制功能。每增加一種協議，就需要編寫一套用於安全控制和處理的代碼。這顯然不是最優的解決方法。
為此，Message Broker 提供了安全管理器（Security Manager）組件，它位於傳輸協議和通訊協議之上，以統一的方式實現對不同協議消息的安全信息抽取，驗證和檢查。安全管理器屏蔽了協議細節，用戶不用關心消息是 HTTP 協議，還是 MQ 協議，或者 Web Services，甚至不用關心安全驗證和控制，只需要簡單的配置，就可以實現 Message Broker 的流程安全。
安全管理器主要有三個功能：
身份識別
從傳來的請求中獲取相關的用戶信息。例如從 HTTP Basic 中抽取出編碼後的用戶名和密碼，並解碼。常見的用戶身份信息是用戶名和密碼，也可以是一個 ID，Token，或數字證書等。
身份驗證
驗證傳來的用戶身份信息是否可以被正確識別。如果是用戶名 + 密碼方式，要驗證密碼是否正確；如果是證書方式，要驗證證書是否有效。
權限驗證
即使通過了身份驗證，也不一定有權限訪問目標資源。權限驗證功能就是判斷該用戶身份是否具備相應資源的訪問權限。
當有消息進來時，安全管理器會自動處理與協議有關安全事項，解析出相關的用戶身份信息，並將其保存到消息樹的 Properties 節點下，隨後的身份驗證，權限驗證都需要使用這些屬性。
5.message_header.gif
以上屬性共有八個，分為兩組：source 和 mapped，分別代表原始的信息和映射後的信息。
以原始身份信息組（source）為例，包括四個屬性：Type（類型）, Token（身份令牌）, Password（密碼）, IssuedBy（簽發人）。
同樣，映射後的信息組也具有相同的四個屬性。
其中，Type（類型）表示用戶的身份類型，有如下取值：
username（僅用戶名）
usernameAndPassword（用戶名及密碼）
SAML（僅用於 WS-Security SOAP）
kerberosTicket
LTPA（僅用於 WS-Security SOAP）
X.509（用於 HTTP, MQ, SCA, SOAP）
UniversalWsse（僅用於 SecurityPEP 節點；SecurityPEP 見下文說明）
查看本欄目
Token（身份令牌）通常會存放用戶名，例如 MQ 消息的 MQMD.username 屬性，或 HTTP Basic 方式解析得到的用戶名。對於 SAML 和 WSSE token 這樣的樹形結構，Token 以字符流的形式存在，使用時需要用 XMLNSC 解析器進行解析。
需要注意的是，對於 HTTP，MQ 等傳輸協議，安全管理器能夠按照相應的規范，自動處理。但對於使用了 WS-Security 標准的 Web services 消息，還需要在 Broker 上定義策略集（Policy Set），聲明傳來的認證令牌方式，加密方式等。否則，安全管理器無法正確解析出用戶身份信息，消息樹中的用戶身份屬性值會一直為空。
安全管理器從協議中解析出用戶身份信息，並將其保存到消息樹的相關屬性後，還可以進行身份認證和權限驗證，判斷消息攜帶的身份信息是否有權限訪問指定的資源。安全概要文件（Security Profile）就是進行相關的設置。
安全概要文件提供了聲明式的安全管理功能，用戶不需要開發任何代碼，只需要創建一個安全概要文件，並進行相應的設置，即可做到消息級別的安全控制，處理消息流中的每一個消息。
在 Message Broker Explorer 中選擇 Broker，右鍵，屬性，在彈出窗口的左側選擇“安全性”，右側窗口就會出現名為“安全概要文件”的按鈕。
6.security_profile.gif
安全概要文件的設置項分為如下幾個部分：
認證（Authentication）
這部分配置使用什麼樣的外部安全提供者（Security Provider）驗證用戶的身份，外部安全提供者也叫做 PDP（Policy Decision Points）。目前支持以下三種方式：
LDAP（只支持用戶名密碼形式）
WS-Trust v1.3 標准
TFIM v6.1（Tivoli Federated Identity Manager）
如果選擇了 LDAP 方式，在最下方的“LDAP 參數”部分配置相關的 LDAP 連接和搜索選項；如果選擇了另外兩種標准，則在“Security Token Service（STS）參數”部分配置服務地址。
“認證配置”項是只讀的，無法直接修改。下同。
映射（Mapping）
如果沒有統一的用戶身份管理系統，往往會出現各個應用系統中用戶信息不一致的情況。例如，某用戶在系統 A 中的賬戶是 aaa，但在系統 B 中的是 bbb。如果這兩個系統之間要通過 Message Broker 進行服務調用或數據交互，就需要對兩個系統的用戶身份進行轉換或映射，將 A 系統傳來的 aaa 賬戶映射為 B 系統的 bbb。
映射部分支持以下兩種標准：
WS-Trust v1.3
TFIM v6.1(Tivoli Federated Identity Manager)
進行身份映射時，使用的是消息樹安全屬性的 source 組（IdentitySourceXXX），映射的結果會存到 mapped 組中（IdentityMappedXXX）。
授權 （Authorization）
用戶身份成功通過認證和映射後，還需要進行授權驗證，查看是否具備相關服務的訪問權限。與認證部分相同，訪問授權也支持三種標准：
LDAP
WS-Trust v1.3
TFIM v6.1(Tivoli Federated Identity Manager)
授權驗證優先使用消息樹安全屬性 mapped 組（IdentityMappedXXX）的相關屬性，如果 mapped 組的屬性值為空，則使用 source 組（IdentitySourceXXX）的屬性。
傳播 （Propagation）
許多情況下，Message Broker 不僅需要攔截處理傳來的消息，驗證其攜帶的安全信息，還要將相關身份信息再傳遞給被調用方。例如，如果被調用方的目標系統也設置了安全驗證，那麼 Message Broker 向目標系統轉發的請求中也需要攜帶身份信息。
打開傳播設置，安全管理器就可以將傳來的用戶身份信息附加到請求中，再傳播出去。
如果傳來的安全信息形式與傳出的形式不同，安全管理器還可以自動實現相應的轉換。例如，傳來的消息（消息流的 inbound）使用的是 WS-Security 標准，而將傳輸的消息（消息流的 outbound）要求 HTTP Basic，安全管理器（Security Manager）會自動識別並處理。
但是，安全信息並不能自動實現任意形式間的轉換。例如，傳來的用戶身份信息是用戶名 + 密碼的形式，並不能自動轉換為證書。
如果安全管理器（Security Manager）在進行安全傳播時遇到了不能處理的身份類型，會拋出異常。
密碼顯示（passwordValue）
如果安全信息是用戶名 + 密碼的形式，為了保密考慮，可能不希望在流程處理過程中看到或讀取到明文的密碼值。
安全概要文件支持不同的密碼值顯示方式：
PLAIN：明文顯示
OBFUSCATE：用 base64 加密
MASK：顯示為 *
如果需要在流程中通過代碼讀取用戶的密碼信息，就必須將密碼的顯示方式設置為 PLAIN（明文）。
安全概要文件的所有配置部分都是可選的，可以創建一個安全概要文件，但不做任何設置，這時，安全管理器只會將用戶的身份信息抽取保存到消息樹的相關屬性，但不做認證，映射和授權檢驗。
安全概要文件定義了 Message Broker 安全管理器對於安全信息的處理方法，可以創建多個安全概要文件，用於不同的情況。
當決定為 Message Broker 的某個消息流啟用安全設置時，需要在包含該流的部署包（BAR）中進行相應的配置。安全概要文件可以應用在流程級別（FLOW），也可以應用在流程中的某個節點（NODE）。流程和節點之間具有繼承關系，如果在流程級別設置了安全概要文件，該流程的所有節點都會自動繼承。
7.bar_configuration.gif
如果沒有創建任何安全概要文件，或者創建了但沒有為消息流設置，則表示關閉消息流的安全功能。在這種情況下，Message Broker 不會處理傳來消息的用戶身份信息。
關於 Security PEP 節點
絕大多數情況下，消息流的安全驗證都是在消息進入時進行的，只需要給消息流創建並設置一個安全概要文件，Message Broker 就可以完成全部安全處理。但是，如果安全檢查不是在消息入口處，而是在消息流的中間處理環節進行，就需要使用 Security PEP 節點。
例如，某企業的服務調用分 web services 方式和 RESTFul 兩種，Web Service 方式采用 WS-Security 安全標准，RESTFul 則使用 HTTP Basic 的方式。兩種服務的入口地址（endpoint）是相同的，Message Broker 需要根據傳來的消息內容判斷是哪種服務方式，然後在決定使用哪種安全驗證方式。安全驗證發生在消息流的中間，而不是入口。這時，可以在消息流中加入一個 Security PEP 節點，該節點會調用安全管理器的相關功能，實現相應的安全驗證和訪問控制。
關於安全驗證失敗的情況
大部分的消息入口節點，包括 MQInput、HTTPInput、SCAInput、SCAAsyncResponse 等，在安全驗證失敗後會走到節點的 Failure 端。
如果是 MQ 或 HTTP，還可以選擇"Treat Security Exceptions as normal exceptions"，讓其在驗證失敗時拋出異常，而不是走到 Failure 端。用這種方式也可以調試安全異常信息，使其輸出錯誤堆棧。
SOAPInput 節點是個例外，如果安全驗證失敗，不會走到 Failure 端，而是返回一個 SOAP Fault 消息。
另一個例外是 Security PEP，如果失敗會拋出異常，終止流程執行。
關於緩存及清理
為了效率考慮，安全管理器默認會啟用緩存，驗證、映射、授權的相關結果都會被緩存起來，默認過期時間是 60 秒。
可以通過命令強制要求清除緩存（可僅清除指定用戶）。命令格式如下：
mqsireloadsecurity <BRK_NAME> -u <USER_NAME>
也可以根據需要調整緩存的過期時間，例如調整為 600 秒：
mqsichangeproperties <BRK_NAME> -b securitycache -o SecurityCache -n cacheTimeout -v 600
查看本欄目
