Java SE 權限模型缺陷深度分析與替代方案 (XACML、第三方方案)

前言

Java SE 的 AccessController + Permission 架構設計於 Applet 時代，核心目標是「程式碼來源可信度」。隨著 Java 進入企業級應用，純粹基於代碼的權限模型暴露出嚴重管理與執行時缺陷，無法滿足細粒度授權 (Fine-Grained Entitlements, FGE) 需求。

Java SE 模型運作回顧

1. 敏感操作呼叫 SecurityManager.checkPermission(Permission)
2. AccessController 遍歷呼叫堆疊每個 Frame
3. 每 Frame 依 CodeSource (位置/簽名) 與 Principal (JAAS 登入身分) 計算權限集 4. Policy 提供者評估所有 Permission.implies()，任一通過即允許 5. 全堆疊通過 → 返回；否則拋 SecurityException

四大管理面缺陷

1. 權限爆炸

企業應用常需定義數百~數千自訂 Permission (如 TransferPermission, AccountEditButtonUIPermission...)，缺乏分類與階層，難以維護。

2. 資源模型破碎

每個 Permission 自行解析資源字串：FilePermission 用路徑通配符，SocketPermission 用 host:port。管理工具無法統一解析、建立資源拓撲。

3. 策略層級缺失

• 無「拒絕」規則，只能靠「未授權即拒絕」 → 需檢查所有 Grant 才能確認拒絕
• 無屬性基礎約束 (ABAC)，如「用戶地點 == 資源地點」
• 無義務 (Obligation) 機制，無法回傳決策附加資訊給 PEP

4. 審計困境

權限類封裝評估邏輯，外部審計工具需知曉所有可能 Permission 實作才能回答「誰能做什麼」，每版應用釋出皆需更新審計工具。

執行時缺陷

• 不必要的堆疊審查：企業授權關心用戶而非代碼，每次 checkPermission 仍遍歷全堆疊
• 評估邏輯硬編碼：AccessController 演算法不可替換，無法外部化 PDP (Policy Decision Point)
• 缺乏批量授權：單次請求只能檢查單一 Permission，頁面級多元素授權需多次呼叫
• 無查詢授權：無法詢問「用戶在資源樹下可存取哪些子資源」以動態渲染 UI

資料與功能安全一致性缺失

Java 模型僅解決「能否執行動作」，無法表達「能看見哪些資料列」。雙模型 (功能 + 資料) 維護成本高、易不一致；單純攔截存取則暴露過多資訊、使用者體驗差。

替代方案評析

建議採取行動

1. 熟悉 XACML 核心概念 (Subject/Resource/Action/Environment/Rule/Policy/PolicySet)
2. 評估市售 Fine-Grained Entitlements 產品 (Oracle Entitlements Server, Axiomatics, PlainID, 開源 AuthZForce 等) 3. 在新專案導入外部 PDP，舊系統以 Adapter 模式漸進遷移 4. 保留 Java SE Permission 保護 JVM 級資源 (檔案、網路、反射)，業務授權全權委託外部 PDP

結語

Java SE 權限模型歷史使命已畢，企業級授權需轉向基於 XACML 的專業化方案。本文不盡列舉所有缺陷，旨在提供決策參考框架。