WebLogic Server的Identity Assertion--转载
在一些典型的公司Web應用程序安全部署中，訪問受保護應用程序的用戶通過企業身份/訪問管理產品，如Netegrity 的 SiteMinder，IBM 的WebSEAL 和Oblix 的 Oblix COREid。然而，身份驗證服務被委派給應用程序自身的提供程序或應用服務器。
應用服務器根據Web應用程序部署描述文件中定義的安 全約束來授權用戶。然而，在已配置安全約束用于提供身份驗證之前，Web容器需要確定用戶經過了身份驗證才能開始工作。也就是說，前端訪問管理器需要提供 一些信息給后端Web容器，以保證Web容器不會試圖重新認證經過身份驗證的用戶。要實現這一點，前端訪問管理器可能需要把用戶憑證(用戶名/密碼)交給 后端服務器。然而，這會由于下面兩個原因受挫：
- 在典型部署中，前端身份管理軟件和后端應用服務器之間的連接不通過安全套接字層(SSL)，這意味著用戶證書將以非加密的純文本形式傳遞。
- 即使連接是安全的，后端服務器仍會用前端訪問管理器傳來的證書，對已認證的用戶再進行一次身份驗證，除非它能驗證請求來自一個可靠來源，即已認證的用戶。
這一情形需要進行周邊身份驗證，也就是只能在前端訪問管理器對用戶進行身份驗證。BEA?WebLogic?Server 為實現身份斷言提供了Identity Assertion。本文為您詳細分析了WebLogic Server中Identity Assertion的實現。建議您先回顧http://e-docs.bea.com/wls/docs81/dvspisec/ia.html中Identity Assertion提供程序的產品文檔。
簡介
從高級觀點出發，Identity Assertion是通過從前端訪問管理器向后端應用服務器傳遞令牌來實現的。從根本上來說，斷言是關于主體(比如用戶)的一些事實(陳述)的聲明。令牌 是從一個系統傳到另一系統的一條信息，它可被用于確認某個特定用戶的身份。令牌和斷言相結合，即構成了Identity Assertion的基礎。本質上，Identity Assertion提供程序是一種特殊的身份驗證形式，它讓用戶或系統流程能使用令牌進行身份斷言。
Web應用程序安全
在介紹Identity Assertion的實現細節前，讓我們簡要說明Web應用程序安全模式的原理。servlet規 范提供了通過servlet容器實現Web應用程序安全的指導方針。規范指定的兩種安全形式是聲明性的和程序性的。當Web應用程序安全為聲明性時，安全 性通過部署符（web.xml）在應用程序之外進行配置。身份驗證方法，或者說提示用戶登錄的方法，將通過Web描述符文件web.xml中 的<login-config>元素來指定。如果登錄配置出現并且包含一個不為零的值，在訪問任何<security- constraint>約束的資源之前，用戶必須進行身份驗證。
當用戶試圖訪問受保護的Web資源時，Web容器就會激活身份驗證機制，該身份驗證機制已經為部署描述文件(web.xml)中的資源進行了配置，它位于<login-config>元素內部的<auth-method>標簽之間，就像這樣：
<login-config><auth-method>BASIC</auth-method></login-config>以下是實現Web應用程序安全的有效身份驗證方法：
- NONE：不提示用戶進行身份驗證。
- BASIC：Web服務器提示用戶輸入用戶名/密碼并對提供的信息進行身份驗證。在此身份驗證方式中，用戶不能定制搜集用戶名/密碼的表單。
- FORM：在這種情況下，您可以定制通過HTTP瀏覽器顯示給終端用戶的登錄屏幕和錯誤頁。
- CLIENT-CERT：這是一種比基本方法或表單方法更安全的身份驗證方法。它使用服務器的SSL和HTTP，或者帶有公共密鑰證書(Public Key Certificates(的客戶端身份驗證。安全套接字層(SSL)為TCP/IP連接提供了數據加密、服務器身份驗證、消息完整性和可選的客戶身份驗證。后面您會看到,WebLogic Server?正是使用這種身份驗證形式執行身份斷言的。
當Web應用程序安全是程序式時，servlet 容器能實現某些HttpServletRequest 接口的方法，用于身份驗證/授權試圖訪問受保護資源的用戶。Servlet 容器為程序式安全提供了額外的方法，這些方法在規范中都沒有提到。在WebLogic Server?中，提供額外方法的類是weblogic.servlet.security.ServletAuthentication。 ServletAuthentication 允許servlet 中基于表單的身份驗證和程序式身份驗證。它通過Security Realm 執行身份驗證調用，并為會話設置用戶信息。weak()方法用于密碼認證而strong()用于基于證書的身份驗證。后面我們將使用來自該類的方法，允許 通過相同Web應用程序的多重身份驗證機制來對Web應用程序用戶進行身份驗證。
Web應用程序部署
圖1代表Web應 用程序常用的部署模型。如圖所示，當用戶試圖訪問受保護的Web應用程序時，前端訪問管理器將對這些用戶進行身份驗證，并把認證過的用戶路由到后端應用服 務器。如果Web應用程序在部署描述文件中定義了安全約束而且角色/屬性存儲在目錄服務器上，servlet容器調用安全API從底層目錄獲得用戶/組的 信息。
?
圖1 Web 應用程序部署
讓我們大概了解一下有效用戶訪問受保護資源必須經過的步驟，如部署模型中所示。
- 用戶請求受保護的Web資源。
- 前端Web服務器/身份驗證服務器對用戶進行認證。
- 如果用戶通過認證，請求就被傳給后端應用服務器。
- 然而，由于身份驗證規則/安全約束配置在Web應用程序描述文件中，servlet 容器需要從底層目錄存儲器中獲得用戶/組信息。
- 應用服務器為了使傳入的主題與底層存儲器的屬性相關聯，它需要確保用戶是經過認證的。
- 為執行上述安全需求，應用服務器應該重新認證用戶，或假定來自前端訪問管理器的請求是已認證用戶發出的。
- 然而，不推薦從應用服務器進行額外的重新認證，因為這需要額外的系統開銷。為避免額外的重新認證調用，應用服務器的另一選擇是假定來自前端訪問管理器的請求來自已認證用戶，從而繞過身份驗證步驟。
Identity Assertion或周邊身份驗證為應用服務器提供了一種機制，用于斷言前端請求是來自已認證用戶的，從而避免了重新認證。這通過配置令牌來實現，令牌能與HTTP頭部請求一起從前端訪問管理器傳遞到后端應用服務器。下一節對此進行了詳細的解釋。
令牌概述
令牌主要是兩方之間傳遞的秘密代碼。本質上，令牌是關于主體的斷言或聲明，該主體被斷言方看作是聲明性的（可信任的）。當接收方收到令牌，它會進行一組 操作驗證傳入的令牌。如果令牌被驗證過，就假定請求來自可信任的資源，接收方就不會進行額外的身份驗證。在典型的Web環境中，令牌是通過HTTP頭部或 cookie傳遞的。
在當前實現中，WebLogic Server?的默認Identity Assertion 提供程序支持下列令牌：X.509、CSI.PrincipalName、CSI.ITTAnonymous 和CSI.X509CertChain CSI.DistinguishedName。“支持”令牌類型本質上意味著Identity Assertion 提供程序的運行時類（也就是IdentityAsserter SSPI實現）能用assertIdentity方法來驗證令牌類型。
由于上述令牌可能無法滿足所有應用程序的需求，您可以為自己的環境輕松地建立新的自定義令牌。建立自定義令牌需要編寫自定義Identity Assertion 提供程序，該程序能實現IdentityAsserter Security Service Provider Interface (SSPI)。WebLogic Server?的SSPI 提供了開發自定義安全提供程序的途徑。自定義令牌類型可以像一段字符串那樣簡單。例如，在Custom Identity Assertion Provider Implementation中定義下列代碼片段，也就定義了一種新的令牌類型。
public final static String MY_TOKEN_TYPE = "MyCustomIAToken";
定義了新的令牌類型后，可以按BEA產品文檔中描述的WebLogic Console 一樣，對其進行配置。一旦配置完成并進行了激活，這些令牌就可被WebLogic Security 架構用于斷言傳入請求的身份。
序列圖
圖2給出了執行Identity Assertion 期間的步驟順序：
?
圖2 身份斷言序列
與JAAS的關系
有一點很重要，Identity Assertion不受到JAAS 的保護，也就是說JAAS對實現Identity Assertion不提供任何特定的指導。Assertion和JAAS唯一的關聯是Identity Assertion 的實現返回一個javax.security.auth.callback.CallbackHandler（http://java.sun.com/j2se/1.4.2/docs/api/javax/security/ auth/callback/CallbackHandler.html）。 您可能會想起，當 JAAS LoginModule 需要與用戶通信時（例如，要求用戶輸入用戶名和密碼），它是通過調用CallBackHandler 實現的。然后CallBackHandler()方法生成適當的 CallBack 來獲得請求的信息。在Identity Assertion的情況下，自定義安全提供程序驗證請求中傳遞的令牌是有效的，隨后生成唯一的NameCallBack。
多重身份驗證機制
在本文前面，我們回顧了Web應用程序安全模型。在登錄配置中關于指定身份驗證方法的問題之 一是，在某個指定時間，一個Web應用程序只能配置一個身份驗證方法。然而在某些情況下，需要從多個源為用戶提供服務，也就是說，來自包含已定義令牌的可 信任來源（前端訪問管理器）的用戶和那些不是來自可信任來源的用戶。可能包括來自內部網絡的用戶，他們可以直接訪問應用服務器。換句話說，依賴于請求的來 源，servlet 安全實現可能需要生成兩種不同的CallBackHandlers。然而，servlet 規范中沒有規定允許多重身份驗證方法。這需要調用特定于Web容器提供程序的編程式解決方案。正如我前面指出的，WebLogic 為Web應用程序內部的程序式身份驗證提供weblogic.servlet.security.ServletAuthentication。 ServletAuthentication 方法為身份驗證提供了兩種重要的方法：
- weak()：從請求中獲取用戶名和密碼后，為AUTHENTICATED或FAILED_AUTHENTICATION返回一個int值，對該用戶進行認證，并將其設置到會話中。
- strong()：與“WebLogic”（默認）域相反，強身份驗證使用客戶端證書鏈作為身份驗證憑證。
圖3提供了此配置的步驟。在Identity Assertion 中，servlet 容器調用ServletAuthentication的strong()方法。為相同的Web應用程序實現多重身份驗證方法（基于CLIENT-CERT 和FORM方法），選項包含在登錄表單通過編程調用方法。也就是說，登錄表單先執行強身份驗證（CLIENT-CERT）。如果在請求頭部或cookie 中出現了一個有效令牌，就允許用戶對資源進行訪問。如果強身份驗證失敗，登錄表單會提示輸入用戶名和密碼。要注意的是，因為BASIC形式的身份驗證不提 供定制身份驗證表單的能力，也沒有在表單中提供編程能力，所以不可能通過編程方式對BASIC和CLIENT-CERT身份驗證方法進行組合。
?
圖3 使用多重身份驗證方法時的步驟
替代解決方案
Identity Assertion不是這個問題唯一可行的解決方案。其他解決方案包括在兩方之間傳遞共享秘鑰（或令牌）。在這種情況下，發送方和接收方要事先都同意共享 的秘鑰。如果帶有正確共享秘鑰值的請求到達時，接收方就能相信請求是來自可信任來源并允許訪問底層資源。
其他解決方案諸如基于IP的信任也可以在此使用。在這種情況下，在請求被授權進行訪問之前，應用程序會檢查請求是否來自預配置的、可信任的IP地址。通常是DMZ中Web服務器的IP。
結束語
本文詳細介紹了BEA?WebLogic Server?如何提供一種機制來通過Identity Assertion執行周邊身份驗證。當前端訪問管理器執行身份驗證，而多個后端服務器相信來自前端的請求是經過認證的，并且不需要額外身份驗證時，這種 方法就非常有用。
來源：http://middleware123.com/weblogic/security/520.html
轉載于:https://www.cnblogs.com/davidwang456/p/3816515.html
總結
以上是生活随笔為你收集整理的WebLogic Server的Identity Assertion--转载的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java 理论与实践: JDK 5.0
- 下一篇： WebLogic Server的单点登陆