J2EE應用程序的授權概念和解決方案
什么是授權？
授權就是基于用戶的權限或用戶的類別（在這種情況下，“用戶”可能指某個外部系統，而不一定是個人）管理對受保護系統資源的訪問。因此，授權假定已進行了身份驗證，因為如果不知道用戶是誰，則根本無法提供恰當的訪問控制——而不是在通常情況下所有用戶都具有相同的權限。稍后我們將詳細說明各種授權模式或方式，但首先我們將對其做一個簡要的總結。
基于角色的授權
基于角色的授權基于用戶是某類用戶的成員這一事實提供對資源的訪問。這通常依賴于用戶具有在用戶注冊中心定義的組標識。此方法定義受保護系統的各個組件，并將這些組件映射到能夠對其進行訪問的用戶組。這種類型的授權是 J2EE 領域的標準模式。總的說來，這是一種非常粗粒度的安全形式，用于處理對系統的功能領域的訪問，可以由 URL 或對 EJB 組件的方法調用進行定義。這并不是說無法使用角色定義更細粒度的保護，但這樣做的效果通常不好。
基于實例的授權
與 J2EE 基于角色的授權通常提供的授權相比，此模式提供了更細粒度的授權，可以一直細化到項目內的單個對象的級別。我們現在討論的是數據保護，而不只是功能保護。
基于關系/所有權的授權
這種類型的授權是基于實例的模式的一個特例，在基于實例的模式中，在應用程序的數據結構內存在用戶與某些其他受保護的數據之間的所有權關系。這通常意味著必須將授權規則嵌入到應用程序本身的數據訪問邏輯之中。
用戶界面自定義
雖然這不是真正的授權類型，但與此緊密相關的一個問題是對用戶界面進行自定義，以使其僅顯示允許特定用戶看到的特定功能。例如，菜單或門戶頁將不會顯示未授權用戶訪問的鏈接或 Portlet。這實際上是一種預先授權；授權詢問“我能這樣做嗎？”，而預先授權則詢問一個略為不同的問題“如果我詢問是否能進行此操作，答案會是什么？”不過，正如我們稍后將看到的，這兩種情況下的編碼技術可以完全相同。
J2EE 基于角色的授權
基于角色的授權通過僅將資源提供給已分配相應角色的用戶來保護資源。J2EE 提供了通過使用聲明和編程技術來完成此任務的標準方法。我們稍后將在授權技術部分中詳細討論 J2EE 安全性。不過，務必理解 J2EE 領域中的角色概念。關鍵要記住，J2EE 角色不是一組人員。它們是特定于應用程序的邏輯名稱，可以在部署時映射到用戶和組。角色本身通常表示 J2EE 應用程序中的權限集合。
實際定義哪些用戶屬于哪些組是在用戶注冊中心中進行管理的。這可以是企業 LDAP 服務器，也可以是僅由單個應用程序使用的數據庫，但用戶和組信息的存儲庫位于 J2EE 環境之外。在 J2EE 應用程序內，您可以基于這些角色定義和命名安全角色及約束資源訪問。因此，角色是權限集合；為了使用它，必須在部署應用程序時將其綁定到某一組用戶。可以按名稱將其映射到一個或多個用戶，也可以映射到一個或多個用戶組，還可以映射到二者的任意組合。術語主體通常是指用戶或用戶組。
您將看到，雖然 J2EE 角色可能通過簡單的一對一映射緊密地映射到注冊中心組，但并不一定非得如此；在最簡單的情況下，可以將“manager”角色映射到稱為“manager”的組，但 J2EE 角色的強大之處在于，它提供了出色的靈活性，能夠在組織發生更改時更改綁定，而無需進行編程更改。以下列情況為例，假定特定的應用程序功能僅對法律部門的員工可用，而這些員工都屬于 Department 102。可以在應用程序中創建一個名為“legal”的 J2EE 角色，并綁定到注冊中心組“Dept102”。如果以后對該部門進行了重組，其中一半的員工轉到了 Department 507，則可以更改綁定，以映射到“Dept102”和“Dept507”。然后，當屬于這兩個部門的任何員工經過了系統的身份驗證后，就會向其授予“legal”角色，系統會向其提供恰當的訪問權限。
自定義基于角色的授權
即使使用編程 API，仍然會有因 J2EE 角色模型不夠靈活而難以滿足業務需求的情況。不過，在草率行事前，應該對以 J2EE 模型為基礎（而不是將其替換）進行構建的可能性進行分析。這樣做的優勢包括：
利用本機應用服務器身份驗證對創建完全安全的系統至關重要。（請參見 IBM WebSphere 開發者技術期刊: WebSphere Application Server V6 高級安全性加強——第 1 部分）。
良好的安全性可提供深度防御；使用多種方法并不一定是壞事。
可以首先使用 J2EE 執行基本的聲明性安全功能，然后使用自定義方法來執行更為詳細的身份驗證邏輯。
從頭編寫可以免費獲得的功能并不劃算！
另外要注意，有時候，可以通過應用服務器安全運行時的其他可插入功能來獲得所需的靈活性。例如，如果需要角色-組映射在運行時具有動態性（根據用戶登錄時提供的信息），則可以使用 JAAS 登錄擴展來滿足此需求（請參見 Advanced authentication in WebSphere Application Server）。在 WebSphere Application Server V5.1.1 或更高版本中，可以在 Trust Association Interceptor 或 JAAS 登錄模塊中創建動態組成員身份。不過，如果角色與上下文相關（基于具體的應用程序使用情況），則可能需要購買或構建授權框架。醫療應用程序就是上下文使用模式的一個例子：醫生可以一次性登錄到系統，但根據所查看的病人或醫療實體（如醫院或診所）的上下文的不同，該醫生的角色可能會從檢查醫師更改為主治醫師。此更改是在會話過程中動態更改的，而不僅限于進行身份驗證時可用的信息。
只要認為 J2EE 應用程序授權本身不足以解決您的問題，下一個問題就是要確定是否構建或購買授權解決方案。IBM Tivoli® Access Manager 等企業安全產品提供了靈活的、基于策略的功能授權。不過，將這些功能與應用服務器相集成可能有一定的挑戰性。您需要考慮的一些問題包括：
是否使用專用 API？
將提供何種功能？
授權請求外部化會帶來何種性能損失？
Java Authorization Contract for Containers (JACC) 是一種基于標準的方法，用于將外部安全管理器與應用服務器集成。JACC 提供了將安全授權的權限檢查委托給外部提供程序的功能。由于授權檢查是在容器將控制權交給應用程序前進行的，因此 JACC 具有能夠清楚區分自定義授權邏輯和應用程序邏輯的優勢，從而滿足了關注點分離的需求。不過，使用 JACC 時有一些方面需要特別注意，因此有必要更深入地探討 JACC，以準確了解其執行的工作以及可對其加以應用的場合。我們稍后將對 JACC 進行更為詳細的討論。
基于實例的授權
顧名思義，基于實例的授權就是將訪問權限授予某個對象的特定實例。基于實例的授權通常使用訪問控制列表（Access Control List，ACL）來保護實例，而 ACL 存儲在某種類型的策略存儲區中，并且可用來制定訪問決策。可以將 J2EE 角色作為 ACL 使用，不過這個方法可能會不方便。正如我們前面所討論的，J2EE 角色終究只是一個名稱，是可以綁定到任何一組主體的邏輯構造。這種方法不能很好地擴展來大量使用 ACL，也不能處理在應用程序執行時動態修改 ACL 的情況；因為我們曾提到，部署描述符在應用程序啟動時以靜態方式定義 J2EE 角色。考慮到這些限制，在許多情況下，更好的方法可能是使用外部安全解決方案或 ACL 基于實例的安全性自定義框架。
為了更便于理解，讓我們看一個例子。假定我們有一個新的 J2EE 人力資源系統，可允許用戶執行打印相關的任務，如將文檔發送到打印機和查看與管理打印隊列。由于可打印數據的敏感特征，需要進行某些限制。例如，可能存在有關授權哪些用戶使用或管理哪些打印機的規則。還可能存在有關在每天的特定時段使用打印機的規則；或許會考慮連夜在特定的打印機上打印敏感材料。
我們可以使用標準的 J2EE 基于角色的安全性來管理打印機訪問。例如，可以為打印機和所需訪問類型的每種組合定義一個角色，最終得到“Allowed_to_print_to_PrinterX”或“Allowed_to_manage_queue_for_PrinterY”之類的角色。然后，我們必須在應用程序中編寫代碼，以使用 isUserInRole() 調用遍歷所有可能的角色，從而驗證當前用戶是否被授權執行他們所嘗試的任何打印相關操作，而且我們必須將每個角色綁定到相應的用戶注冊中心條目。
正如您所看到的，這并不是授權需求的一個條理非常清楚的實現。添加任何新打印機都會要求對應用程序進行更改；而有關何人可以進行何種操作的規則的變化則會要求重新將這些角色綁定到主體，并重新部署應用程序。此外，我們尚未開始考慮時段問題。我們需要能夠存儲與每臺打印機對應的可配置信息，但在標準 J2EE 授權模式中，實際上卻沒有任何地方能夠放置此類信息。
現在，如果我們要使用獨立的授權服務，這可以極大地簡化解決方案，因為我們將只需要詢問授權服務，當前用戶是否可以對某個對象執行某項操作。所有這些都將外部化，從而極大地簡化了編程模型，并使得對外部提供程序的更改以實時的方式反映到正在運行的應用程序中。我們稍后將再次對此問題進行討論。
所有權關系
直接所有權是用戶和某些受保護數據間的一種十分常見的基于實例的關系。例如，在經紀業應用程序中，理財顧問可以查看其個人客戶的帳戶，但卻不能查看公司的其他客戶的帳戶。部門經理可以查看所屬的理財顧問的所有客戶的所有帳戶，但卻不能查看其他部門的客戶的帳戶，諸如此類。在這種情況下，權限內置到應用程序的數據結構中。
應用程序很少會采用以下這種方式，即向用戶界面提供用于檢索所有數據的帳戶列表，然后再向每一行應用基于 ACL 的權限。這里存在的主要問題是性能：與在 Java 代碼中進行篩選相比，在數據庫引擎中進行行篩選通常要快得多。盡管緩存可能在一定程度上減輕這種性能影響，但如果使用特定大小的數據塊檢索數據來支持用戶界面分頁，則可能出現另一個問題。如果篩選在應用程序中進行，則無法知道請求了多少行，因此可能導致通過多次調用來獲取單頁數據的情況。
遺憾的是，盡管存在種種缺陷，這種應用程序端篩選方法卻被經常使用。如果應用程序使用對象關系映射工具來執行數據訪問，然后嘗試以某種通用方式將安全機制應用到實例化的類，則尤其可能出現問題。這是對計算資源的一種極為低效的使用，獲得可接受的性能和可伸縮性的可能性非常小。
唯一合理的方法是讓數據庫進行篩選。如果數據庫知道最終用戶的標識，或通過修改對實際數據訪問邏輯的篩選將授權邏輯嵌入到應用程序中（通常通過將相應的項目添加到 SQL 語句的 Where 子句中），則可以通過利用本機數據庫授權來實現此目的。取決于應用程序復雜性，或許可以開發一個使用元數據描述授權規則的自定義框架，以自動將安全更改應用到 SQL。如果將存儲過程用于數據訪問，則這些存儲過程也是應用這些規則的最佳場所。
用戶界面自定義
動態修改用戶界面，以僅向用戶顯示其能夠執行的操作，這樣的做法常常也被視為授權的一個方面。雖然這很有爭議，但它無疑是一個常見的問題；向用戶顯示他們未被授權執行的鏈接的做法肯定非常不好（并可能招致黑客攻擊）。
自定義 UI 以刪除鏈接和菜單選項的做法與基于角色的授權非常相似。這通常只是簡單地使用 isUserInRole() 調用來遍歷各項，從而驗證用戶是否應該看到此項。還可以采用相同的方式自定義表單上的實際數據，不過這可能會導致進行冗長煩瑣的編程，而且不能提供足夠的靈活性，具體取決于業務需求。當需要將訪問控制自定義與其他類型（如用戶首選項）集成時，這種方法可能會變得尤為復雜。如果用戶能夠訪問允許開發自己的特定 UI 組件視圖的某種首選項工具，則該工具也需要識別授權規則元數據，以防止用戶向其個性化表單添加其不應該具有訪問權限的項。正如前面討論自定義基于角色的授權時所提到的，可能會存在數據視圖與上下文相關的情況，并不能僅簡單地基于靜態角色對其進行調整。
【編輯推薦】
