眾所周知，WS-Security設定的目標之一是對SOAP消息強制執行完整性和/或保密。 在完整性的情況下，添加到SOAP消息的簽名是數學過程的結果，該過程涉及發送者的私鑰，從而導致加密的消息摘要。

默認情況下，大多數框架（例如WSS4J）僅對正文進行簽名。 如果要添加額外的標頭（例如Timestamp標頭），則需要明確指示對其進行簽名。 使用WSS4J例如Spring的支持，你可以設置包含本地元素名稱的逗號分隔的列表，并使用securementSignatureParts屬性對應的命名空間。

在下面的示例中，如何指示它對Body和Timestamp元素（及其同級元素）進行簽名。 這將導致將兩個數字簽名附加到消息中：

<property name="securementSignatureParts" value="{}{http://schemas.xmlsoap.org/soap/envelope/}Body;{}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp"> </property>

最終，SOAP消息將與XML數字簽名數據以及大多數情況下包含證書的BinarySecurityToken一起發送。 到目前為止沒有新內容。 但是，令我吃驚的是，似乎沒有廣泛了解BST的目標是什么，也不知道如何使用它來控制身份驗證。 讓我嘗試闡明一下：與SOAP消息一起發送的發件人的證書起著標識的作用。 您可以將其與用戶名++進行比較。 應該清楚的是，消息中的證書不能被信任，用戶名也不能不經過密碼驗證。 到目前為止，每個人都對此表示同意： “是的，當然，需要對證書進行驗證才能被信任，然后您便會被設置！” 但這還不是全部。 證書的驗證與身份驗證不同。 消息中的證書有效并且由已知CA簽名的事實不足以考慮發件人是否已通過身份驗證。 例如：在最惡意的時刻，我本可以截取消息，更改內容，基于我的私鑰創建新的簽名并用我的證書替換消息中的BST。 我的證書完全可以是正式的CA簽名證書（甚至由您使用的同一CA簽名），因此它可以通過驗證檢查。 如果框架只是簡單地驗證消息中的證書，那么我們將完全沒有安全性。

注意：如果您是通過安全傳輸發送郵件，則可能是我無法截獲該郵件。 但是安全傳輸大多在實際端點之前終止，而使一小部分傳輸“不安全”。 盡管這部分將主要在公司內部進行，但是我想指出的是，無論您的傳輸多么安全，端點都有責任驗證發件人的身份。 例如; 在異步系統中，SOAP消息可能已經放置在消息隊列上，以便稍后進行處理。 當由端點開始處理時，安全傳輸的蹤跡早已消失。 您必須使用消息中包含的信息來驗證身份。

為了解決此漏洞，我們有兩個解決方案：第一個解決方案進一步建立在我們已經描述的基礎上：消息中的證書根據信任庫中的CA根證書進行了驗證。 在這種情況下，建議首先縮小可信CA的范圍。 例如，您可以在有限的CA列表中與客戶達成協議，以從中獲取證書。 這樣一來，您已經降低了信任更多“灰色區域” CA的風險，因為這些CA可能不遵循發出如此嚴格的證書的規則（例如，正確檢查其客戶的身份）。 其次，由于您的受信任CA發出的*每張*證書都將被視為“已認證”，因此我們將通過發出一些額外的支票來彌補漏洞。 使用WSS4J，可以基于證書的主題DN屬性配置匹配模式。 他們對此有一個不錯的博客條目： http : //coheigea.blogspot.ie/2012/08/subject-dn-certificate-constraint.html 。 我們可以指定證書的DN必須匹配給定值，如下所示：

Wss4jHandler handler = ... handler.setOption(WSHandlerConstants.SIG_SUBJECT_CERT_CONSTRAINTS, "CN = ...");

注意：目前在Wss4jSecurityInterceptor中使用Spring對WSS4J的支持尚無此設置器，因此您必須對其進行擴展才能啟用此功能！

總結正在執行的步驟：

消息中包含的證書已根據您的受托機構中的受信任CA進行了驗證。 驗證成功后，它將通知應用程序證書仍然有效，并且實際上已由您認為可信的CA分發了該證書。

• 此檢查為我們保證了證書確實屬于證書聲稱屬于的一方。

您也可以選擇在吊銷時檢查證書，以便我們不再繼續信任被明確吊銷的證書。

WSS4J將檢查證書的某些屬性是否與特定服務的所需值匹配（主題DN證書約束支持）。

• 這將是身份驗證步驟； 一旦發現證書有效，我們將檢查證書的所有者是否也是我們要授予訪問權限的證書的所有者

最后，通過創建消息的新摘要來驗證消息中的簽名，將其與消息中的解密摘要進行比較，依此類推。

請注意，默認情況下不進行此檢查（至少在使用WSS4J時）！ 如果您不指定它，而只是將您的CA添加到信任庫中，您將留下一個安全漏洞！

第二種解決方案不需要額外的配置，并且僅取決于要在信任庫中顯示的發送者的證書。
消息中包含的證書與信任庫中的證書匹配。 如果它們匹配，則對發送者進行身份驗證。 無需針對CA驗證證書，因為在信任庫中導入的證書是顯式可信的（WSS4J仍將檢查證書是否未過期，并可能對其進行吊銷檢查）。 同樣，信任庫中沒有CA證書（或CA中間證書）！ 也只有您要授予訪問權限的發件人的證書。 因此，通過從信任庫中添加（或刪除）其證書來控制訪問。

這要求您在最初導入證書時要謹慎，因為您必須確保它們實際上代表發送者。 但這是在將證書添加到信任庫時以及在添加CA證書（如第一個解決方案）時始終必須執行的操作。

結論

假設您可以限制受信任的CA，則在大多數情況下，第一種解決方案是首選的，也是最具擴展性的。 對于新客戶端，不需要對信任庫進行任何更改。 匹配的屬性可以存儲在外部，因此很容易更改/添加。 另外，當客戶端證書過期或被吊銷時，您無需執行任何特殊操作。 發件人將在給定時刻使用新證書，并將根據您的信任庫中的CA直接對其進行驗證。 在第二種解決方案中，您將必須將新證書添加到受托者中，并將舊證書保留一段時間，直到執行切換為止。

總體經驗教訓：水密安全很難。 IT領域的＃1規則（假設是所有麻煩的源頭）在這里確實是正確的。 持懷疑態度，并確保您完全了解正在發生的事情。 在您確定默認設置之前，請不要信任默認設置。 房子警報的默認設置（例如123456）也不是好主意。 Tomcat安裝上的默認管理員密碼也不是。

參考： WS-Security：在Koen Serneels –技術博客博客中， 使用BinarySecurityToken進行 JCG合作伙伴 Koen Serneels的身份驗證 。

翻譯自: https://www.javacodegeeks.com/2013/09/ws-security-using-binarysecuritytoken-for-authentication.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的WS-Security：使用BinarySecurityToken进行身份验证的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。