ABAC相关标准在数据服务中的应用——XACML和NGAC的比较
可擴展訪問控制標記語言（Extensible Access Control Markup Language，XACML）和下一代訪問控制（Next Generation Access Control，NGAC）是兩種截然不同的基于屬性的訪問控制（Attribute-based Access Control，ABAC）標準。雖然它們的目標都是提供一種標準化的方式來表達和執行各種類型的訪問控制策略，以滿足各種數據服務上的多樣化策略的需要，但這兩個標準在描述和實施訪問控制策略的方式上有明顯的差異。
本文介紹了XACML和NGAC的標準規范，然后分別從5個方面對它們進行了比較，目的是幫助ABAC用戶和供應商在解決未來數據服務的策略實施需求時，能夠做出明智、正確的選擇。
關鍵詞：訪問控制；訪問控制機制；訪問控制模型；訪問控制策略；基于屬性的訪問控制；授權；可擴展訪問控制標記語言；下一代訪問控制；特權
?第一部分??
?ABAC概況和XACML規范?
壹
ABAC的發展概況
幾十年來，控制和管理對敏感數據的訪問一直是一個頗具挑戰性的任務。基于屬性（Attribute）的訪問控制（ABAC）代表了邏輯訪問控制發展的最新里程碑，它提供了一種基于屬性的方法來適應廣泛、多樣的訪問控制策略，并簡化了訪問控制管理。
大多數訪問控制方法都是基于發起訪問（例如讀取文件）請求的用戶的身份來實現的，要么直接基于用戶身份為其分配相應的能力（Capability），要么通過預定義的屬性類型（例如分配給用戶的角色或組）來間接授權。因為需要將能力直接與用戶或其屬性相關聯，這些訪問控制系統的建設和管理往往很麻煩。
此外，請求用戶的身份、組和角色通常也不足以表示實際的訪問控制策略。另一種方法是用屬性來表示策略，并根據用戶和資源的任意屬性，以及可選的環境屬性來授予或拒絕用戶的請求，這種訪問控制方法通常稱為基于屬性的訪問控制（ABAC），也是XACML和NGAC的固有特性。
ABAC引擎的訪問控制邏輯根據請求用戶、資源和環境的指派（Assign）屬性以及用這些屬性表示的策略來計算策略決策，如圖1所示。
圖1 ABAC的基本概念
有兩種方法來定義ABAC策略。最常見的方法是通過邏輯表達式來定義授權策略，邏輯表達式由屬性值和邏輯運算符（例如，AND，OR，≥，≠）組成。例如：
can_access(u，a，o)→ Role(u)=”doctor” AND Ward(u) = Ward(o) AND (a=read OR a=write)
定義了：對于任何用戶u和客體o，只要u具有doctor角色，且u和o的病房信息相同，且當前操作為read或write，則都允許u對o執行操作a。
XACML 、ABAC𝞪和HGABAC（基于層次組和屬性的訪問控制）所定義的策略規范語言都屬于這種表達方式。
第二種策略的定義方法是枚舉所有相關的關系配置。NGAC和LaBAC（基于標簽的訪問控制）屬于這一類。例如，NGAC通過使用（uai，arsi，oai）形式的關系組合來指定策略，意為：用戶屬性uai中的用戶擁有對客體屬性oai中的客體在訪問權限集arsi中的訪問權限。
XACML和NGAC都是ABAC標準，用于為用戶的數據服務環境引入便利的安全策略框架。一般來說，數據服務是為用戶提供數據的消費、操縱、管理和共享的應用程序，如員工考勤報告、工資單處理、公司日歷和健康福利管理等應用程序，這些應用都需要訪問控制的保護。XACML和NGAC為應用程序提供了一個通用的訪問控制工具，大大減輕了企業在安全管理中面臨的互操作性和可用性挑戰。具體的做法是，從每個應用的操作環境中刪除其實現訪問控制的功能組件，所有相應的訪問控制邏輯由一組提供訪問決策功能的公共訪問控制模塊來實現，這些模塊通過集中的策略和屬性存儲庫來支持這些應用程序。
從訪問控制的角度來看，數據服務在概念上可以被視為具有表示/邏輯層和操作環境層的應用程序，其不同層次由相應的功能和接口來描述。表示層為用戶提供了一個數據接口和方法，用于創建、顯示和更改數據。表示層不執行存儲、檢索或更改存儲數據狀態的操作，也不執行更改數據訪問狀態的操作（例如，讀取、寫入/保存、創建和刪除文件、提交、批準、調度），而是向操作環境層發出執行這些操作的請求。操作環境實現操作例程以執行訪問請求，并提供訪問控制以確保操作例程的執行受策略保護。
訪問控制機制由多個邏輯組件組成，它們相互協同以實現受策略保護的數據訪問。這些組件包括訪問控制數據（用于表達訪問控制策略和屬性），以及用于捕獲訪問請求和針對這些請求計算和執行訪問決策的一組函數。大多數操作環境以不同的方式實現訪問控制，每個環境都有不同的控制范圍（例如用戶、資源），每個環境都涉及不同的操作方式（例如讀取、發送、批準、選擇）和數據類型（例如文件、消息、工作項、記錄）。
這種異質性帶來了許多管理和策略執行方面的挑戰。在管理訪問策略和屬性時，管理員不得不處理大量的安全域。即使能在不同的操作環境中進行適當的協調，全局控制也很難可視化和實施運行。此外，由于操作環境以不同的方式實現訪問控制，因此很難跨操作環境來交換和共享訪問控制數據。XACML和NGAC試圖通過創建一種通用的、集中的方式來表達所有訪問控制數據（策略和屬性）和計算策略決策（針對應用程序表示層的訪問請求），從而緩解這些挑戰。
2014年，NIST發布了SP 800-162《基于屬性的訪問控制（ABAC）定義和思考》。發布該文檔有兩個目的，首先，它為聯邦機構提供了ABAC的權威定義及其功能組件的描述。SP 800-162將ABAC視為一種機制，包括4個功能層次：執行、決策、訪問控制數據和管理。第二，考慮到ABAC不同實現方法的潛力，SP 800-162強調了選擇ABAC進行部署的幾個考慮因素。這些考慮因素涉及操作效率、屬性和策略管理、支持的策略范圍和類型以及對行政審查和資源發現的支持等。基于這些方面，本報告對XACML和NGAC進行了分析和比較，還比較了它們在支持訪問控制功能與專有操作環境分離方面的能力，但并不打算為XACML或NGAC提供實現規范。
1
XACML
2003年，隨著面向服務體系結構（SOA）的出現，結構化信息標準促進組織（OASIS）發布了一個名為XACML的規范，提出了許多后來被認為是ABAC的元素。XACML在其授權過程中采用了三個組件：
?◆ XACML策略語言。采用規則、策略和策略集的形式來定義訪問控制要求，策略要素包括主體（用戶）、資源、動作（操作）和環境屬性，以及一組用于策略/規則組合的算法。
?◆ XACML請求/響應協議。用于查詢決策引擎，該引擎根據策略評估主體的訪問請求，并在響應時返回訪問決策。
?◆ XACML參考體系結構。用于部署軟件模塊以支持策略和屬性，并基于策略和屬性計算和執行訪問控制決策。
XACML是最早出現的ABAC標準，當前版本是2013年發布的XACML 3.0，在其發展過程中，它得到了研究人員和供應商的廣泛關注和認可。與較新的、仍處于初級階段的NGAC標準（最早的一部分內容發布于2013年，其他部分仍在開發中）相比，XACML已經被很多系統采用，許多開源和專有實現都涵蓋了其標準組件。
盡管無法一一討論各種XACML產品，但Sun XACML開源框架非常值得一提，因為它開創性地實現了XACML框架的所有組件，進而驗證了XACML標準的可行性，并對后續的XACML產品產生了較大影響。Sun XACML不僅是企業應用和研究性項目中使用最廣泛的訪問決策引擎，許多其他開源和專有XACML解決方案也都以Sun XACML作為基礎開發庫。
2
NGAC
2003年，NIST啟動了一個稱為策略機（Policy Machine）的項目，以尋求一個標準化的ABAC機制，允許在ABAC策略的表達和執行中通過更改一組固定的數據元素和關系，來實現靈活的授權過程。
如今，策略機已經從一個概念發展到正式規范，再發展到受臨時專利保護的NGAC和GitHub開源的參考實現。作為NGAC中的一個重要組成部分，策略機與美國國家標準協會/國際信息技術標準委員會（ANSI/INCITS）一系列以“下一代訪問控制”（NGAC）為題的標準化工作保持一致，并為其提供支持。除了表達和實施各種各樣的訪問控制策略，NGAC設施還可用于實現各種數據服務的關鍵安全組件，并為數據服務實施基于任務定制的訪問控制策略。NGAC標準化工作已經并將繼續在以下三個子項目下進行：
?◆ Project 2193–D：NGAC–實施要求、協議和API定義
?◆ Project 2194–D：NGAC–功能體系架構
?◆ Project 2195–D：NGAC–通用操作和抽象數據結構
NGAC初始標準發布于2013年，現在可以從ANSI標準庫獲取，名為INCITS 499–NGAC功能體系架構（NGAC–FA）。不過，現在正在根據2195-D項目的經驗和2193-D項目的反饋，進行一些相關的標準更新工作。
目前，Project 2195–D的標準已獲得批準，可從ANSI標準庫獲取，名為INCITS 526–NGAC通用操作和抽象數據結構（NGAC-GOADS）。
在三個NGAC項目中，Project 2193-D項目最不成熟，其提議的實施方法和支撐材料預計將在2016年夏末提交完畢（注：該報告的發布日期為2016.10）。
隨著策略機規范、NGAC GitHub開源發行版的推出，以及NGAC（旨在與策略機規范保持一致）作為國家標準的出現，商業和學術機構正在努力開發相關產品。目前，至少有一個NGAC的實現已經完成商業化部署，用于支持某云解決方案提供商為生命科學的臨床研究提供的內部應用程序。這個訪問決策引擎可能是第一個活動的、在生產環境中使用的策略機/NGAC實現，目前用于保護用戶的一些臨床試驗數據。在不久的將來，該公司的其余產品（它們管理著世界上絕大部分的臨床試驗數據）將與該訪問決策服務集成。策略機/NGAC實現的很大一部分已經開放源碼。
3
XACML和NGAC的項目起源
在企業IT體系結構的不同組件中指定和實施安全策略（尤其是訪問控制策略），使維護、修改和展示企業范圍內合規性的代價變得非常昂貴。開發XACML是為了滿足訪問控制對通用的策略表達語言的需求，以便在各種信息系統組件中管理所有策略元素的執行。該標準的第一個版本XACML 1.0由OASIS于2003年發布，當前版本是XACML 3.0，OASIS于2013年1月批準了該版本。
由于XACML規范缺少對其包含的策略的訪問控制模型，因此它需要一個額外的策略管理模型，XACML 3.0中的管理和委托概要（版本1.0）是一個滿足該需求的規范。因為只有當多個人具有能夠創建策略的管理權限時，策略背景下的管理（注：指受策略保護的管理操作）才有實際意義，并且由于這些操作總是來自更高層的權威實體（例如，集中式管理員），因此XACML的委托概要自然應該具有策略委托的功能，并且支持創建委托鏈。
發展NGAC的動機是不同的。雖然研究人員、安全從業者和策略制定者已經制定了各種各樣的訪問控制策略來解決現實世界中的安全問題，但這些策略中只有非常小的一部分可以通過現有技術執行，而能夠被所有機制執行的策略就更少了。NGAC的研究目的是設計一個通用的訪問控制框架，通過策略的配置來表達和實施任意的、特定組織的、基于屬性的訪問控制策略。NGAC從一組基本的、可重用的數據抽象和功能出發，為訪問控制提供了一個全新的視角，這些抽象和功能支持常見的和已實現的訪問控制策略，以及通用策略的組合，甚至那些尚不存在訪問控制機制的策略。
策略和屬性（包括委托）的管理從一開始就被視為NGAC框架的一部分。2003年首次開發的策略機是體現上述原則的概念驗證系統，隨后的迭代改進了策略的多樣性和授權的表達能力。出于規范策略機訪問控制模型和策略評估過程的需要，為了鼓勵策略機的大規模應用，開發了NGAC。
盡管XACML和NGAC有不同的起源和動機，但它們具有共同的主題，都是基于與用戶、操作或資源相關聯的屬性來進行授權。因此，XACML和NGAC都是基于ABAC模型的訪問控制框架。然而，在XACML中，授權是用包含屬性值的邏輯表達式表示的，而在NGAC中，授權是通過枚舉包含屬性值的關系來表示的。
目前，XACML和NGAC都適用于各種應用程序環境，例如文件系統，以及具有Web服務或RESTful API的分布式應用程序。
貳
XACML規范
XACML為ABAC實現定義了一種策略規范語言和參考體系結構。該標準包含用于表示請求、策略、屬性和函數的語法和語義，這些請求、策略、屬性和函數用于計算決策和執行策略，以響應主體對資源的訪問請求。
為了簡潔易讀，本節對XACML規范進行了概述，旨在突出XACML的基本特性，因此內容可能并不完整。在某些特殊情況下，XACML的細節和術語被替換為本文的術語，以簡化表述。
1
策略與屬性
XACML訪問請求由主體（Subject，通常指發出請求的用戶）屬性、資源（Resource，請求訪問的對象）屬性、操作（Action，對資源執行的操作）屬性和環境（Environment）屬性組成。
XACML屬性以“名-值”對的形式定義，其中屬性值可以是不同類型（例如integer、string）。屬性名/ID表示與主體、資源、操作或環境相關聯的屬性或特征。例如，在醫療情況下，主體屬性Role可能具有doctor、intern和admissions nurse等值，其值的類型均為string。主體和資源實例使用一組“名-值”對來指定它們各自的屬性。例如，醫療策略中使用的主體屬性可能包括：Role=“doctor”、Role=“consultant”、Ward=“pediatrics”、SubjectName=“smith”；環境屬性：Time=“12:11”；和資源屬性：resource-id=“medical-records”WardLocation=“pediatrics”，Patient=“johnson”。
盡管XACML不需要任何命名屬性的約定，但前綴Subject、Resource和Env分別用于命名主體、資源和環境屬性，以增強可讀性。
主體和資源屬性存儲在各自的存儲庫中，并在訪問請求時和計算決策之前通過策略信息點（PIP）進行檢索。XACML將操作形式化定義為請求的一部分，其屬性值包括read，write，submit和approve等操作。
環境屬性通常需要借助能夠檢測和報告環境數據的系統傳感器，并且與通過管理手段創建的主體和資源屬性有些不同。環境屬性不是主體或資源的特性，而是與訪問請求發生時的操作環境或上下文環境相關的可測量特征。這些環境特征與主體和資源無關，可能包括當前時間、一周中的某一天或威脅級別。
本文檔使用A()的函數形式來表示屬性值的計算結果，其參數可以是主體、資源、操作或環境。例如A(e)，其中e是環境，可能等于09:00（時間）或low（威脅級別）；A(s)，其中s是主體，可能等于smith（姓名）和doctor（角色）。使用元組來表示主體、資源或環境所擁有的多個屬性。例如，A(s1)=<smith，doctor>，其中第一個屬性對應于主體s1的名稱，第二個屬性對應于主體s1所擁有的角色。
如圖2所示，XACML訪問策略被組織為策略集（PolicySet）形式，策略集由策略和其他策略集（可選）組成，而策略由規則（Rule）組成。策略和策略集存儲在策略檢索點（PRP）中。因為并非所有的規則、策略或策略集都與給定的請求相關，所以XACML引入了一個“目標（Target）”的概念。一個目標定義了一個簡單的布爾條件，如果屬性滿足該條件（計算結果為真），則由策略決策點（PDP）確定繼續進行后續計算。如果沒有目標與請求匹配，則PDP計算的決策結果為“不適用（NotApplicable）”。
圖2 XACML策略的構造結構
與目標相似，規則也包含一組布爾條件（Condition），如果計算結果為True，則觸發效用動作（Permit或Deny）的執行。如果某個規則的目標條件計算結果為True，但該規則的條件由于任何原因而無法計算，則該規則的效果是不確定的。與目標的（匹配）條件相比，規則或策略的條件通常更復雜，并且可以包括涉及用于比較屬性值的邏輯運算符（例如，“greaterthan-equal”、“less-than”、“string-equal”）的函數。條件可用于表示訪問控制關系（例如，醫生只能查看其負責的病房中患者的病歷）或屬性值的計算（例如，sum(x,y) lessthan-equal:250）。
為了提高互操作性，所有屬性都具有已知的數據類型，并且所有使用這些屬性的函數也都有適當的類型。盡管這些標準數據類型和函數已經可以支持靈活的策略表達式，但XACML仍然進一步定義了數據類型和函數的擴展規范。
2
組合算法
因為一個策略可能包含多個規則，而一個策略集也可能包含多個策略或規則集，每個規則、策略或策略集可能產生不同的決策結果，包括允許（Permit）、拒絕（Deny）、不適用（NotApplicable）或不確定（Indeterminate）。XACML通過一系列組合算法來協調這些可能沖突的單個決策，每個算法代表一種將多個局部決策合并成單個全局決策的方法。AXCML定義的標準組合算法，包括：
?◆ 拒絕覆蓋（Deny-override）。如果任何決策評估為拒絕，或沒有決策評估為允許，則合并結果為拒絕。如果所有決策都評估為允許，那么合并結果就是允許。
?◆ 允許覆蓋（Permit-override）。如果任何決策評估為允許，則合并結果為允許，否則合并結果為拒絕。
?◆ 首項適用（First-applicable）。按評估項在組合列表的順序，將第一項的決策結果（允許、拒絕或不確定）作為合并結果。
?◆ 唯一適用（Only-one-applicable）。如果合并列表中只有一個決策適用，則以該決策的結果作為合并結果，如果有多個決策適用，則合并結果為不確定。
在策略中的規則和策略集中的策略上應用組合算法后，獲得PDP的最終決策結果。組合算法可用于構建日益復雜的策略。例如，假設僅當聚合（最終）決策為Permit時，PDP才允許主體請求，則“允許覆蓋”算法的本質是針對Permit的“OR”操作（只需存在一個結果為Permit的決策），“拒絕覆蓋”的本質是針對Permit的“AND”操作（所有決策都必須為Permit）。
除了標準的組合算法集之外，XACML還包括一個標準的擴展機制，可以用來定義其他算法。
3
?職責和建議
XACML包含了職責（Obligation）和建議（Advice）的概念。規則、策略或策略集中指定的職責（可選）是PDP向PEP發出的指令，說明在允許（或拒絕）訪問請求之前（或之后）PEP必須執行的操作。
建議與職責類似，唯一的區別是建議可以被PEP忽略。
例子：
?◆ 如果Alice被拒絕訪問文檔X：通過電子郵件通知她的經理，Alice試圖訪問文檔X。
?◆ 如果拒絕用戶訪問文件：通知用戶拒絕其訪問的原因。
?◆ 如果準許用戶查看文檔X：在傳輸文檔前，為其添加水印。
最典型的職責是在批準訪問請求后，審記和記錄用戶的訪問事件。
應該注意的是，執行職責或建議指令的功能超出了XACML的能力，通常需要由特定應用的PEP實現和執行。
4
?策略示例
下面給出兩個XACML策略的規范示例。為了保持與XACML相同的語義，使用了相同的元素名，但是為了增強可讀性，策略和規則采用了偽代碼（而不是準確的XACML語法）定義。附錄C中包含了第一個策略（策略1）的標準XACML格式。
策略1適用于“醫生或實習生對病歷的所有讀寫操作”（即策略的目標），包括三個規則。因此，當具有“doctor”或“intern”角色的主體發出讀取或寫入“medical-records””資源的請求時，該策略被視為“適用”。
這些規則沒有對目標的細化，而是描述了允許醫生或實習生對病歷進行讀寫請求的條件。如果分配給醫生或實習生的病房與患者所在的病房不同，規則1將拒絕任何訪問請求（read或write）。規則2明確拒絕實習生在任何情況下的write訪問請求。規則3在特殊情況（病人處于危重狀態）下，允許“doctor”對病歷進行讀寫訪問，而不管規則1的條件是否滿足。由于該策略的目的是在這些特殊情況下允許訪問，因此使用了“允許覆蓋”的策略組合算法，如果只有規則1或規則2中所述的條件適用，則仍然拒絕訪問（注：規則1或2適用時，它們都產生Deny的決策）。
<Policy PolicyId=“Policy 1”rule combing algorithm=“permit overrides”>
? ? ? ? ? ? ?// Doctor Access to Medical Records//?
<Target>
/* :Attribute-Category :Attribute ID :Attribute Value */
:access-subject :Role :doctor
:access-subject :Role :intern
:resource :Resource-id :medical-records
:action :Action-id :read
:action :Action-id :write
</Target>
<Rule RuleId= “Rule 1” Effect= “Deny”>
<Condition>
Function: string-not-equal
/* :Attribute-Category :Attribute ID */
:access-subject :WardAssignment?
:resource :WardLocation
</Condition>
</Rule>
?
<Rule RuleId=“Rule 2” Effect = “Deny”>
<Condition>
Function: and
Function: string-equal
/* :Attribute-Category :Attribute ID :Attribute Value */?
:access-subject :Role :intern
Function: string-equal
/* :Attribute-Category : Attribute ID :Attribute Value */
:action : Action-id :write
</Condition>
</Rule>
?
<Rule RuleId=“Rule 3” Effect=“Permit”>
<Condition>
?Function: and
?Function: string-equal
?/* :Attribute-Category :Attribute ID :Attribute Value */?
?:access-subject :Role :doctor
?Function: string-equal
?/* :Attribute-Category :Attribute ID :Attribute Value */
?:resource :PatientStatus :critical
?</Condition>
</Rule>
</Policy>
策略和屬性指派一起定義了授權狀態。表1通過指定屬性名和值來定義策略1的授權狀態。
表1. 策略1的屬性名稱和值以及授權狀態
| 主體屬性和值域 | Role = {doctor, intern} WardAssignment = {ward1, ward2} |
| 資源屬性和值域 | Resource-id = {medical-records} WardLocation = {ward1, ward2} PatientStatus = {critical} |
| 操作屬性和值域 | Action-id = {read (r), write (w)} |
| 系統中，兩個主體 (s3, s4) 和三個資源 (r5, r6, r7)的屬性指派 | A(s3) = <doctor, ward2>, A(s4) = <intern, ward1>, A(r5) = <medical-records, ward2>, A(r6) = <medical-records, ward1>, A(r7) = <critical> |
| 授權狀態 | (s3, r, r5), (s3, w, r5), (s3, r, r7), (s3, w, r7), (s4, r, r6) |
策略2適用于“國稅局代理和審計師獲取納稅申報表”（策略的目標），包含兩條規則。當角色為“IRS代理或審計員”的用戶通過寫請求訪問資源“納稅申報表”時，此策略為“適用策略”。這些規則沒有對目標細化，但規定了允許IRS代理人或審計員向納稅申報表記錄執行寫操作的條件。如果訪問時間（環境變量）在上午8點到下午6點之間，規則1將允許適用的訪問請求。如果IRS代理人或審計員試圖寫他自己的納稅申報表，即使規則1中的條件滿足，規則2也將拒絕該請求。由于該策略的目的是防止國稅局雇員更改自己的納稅申報表，因此使用了“拒絕覆蓋”的組合算法，但若規則2的條件不滿足，仍將允許訪問。
<Policy PolicyId = “Policy 2” rule-combining-algorithm=”deny-overrides”>
? ? ? ? ? ? ?// IRS Agent and Auditor Access to Tax Returns //
<Target>
/* :Attribute-Category : Attribute ID : Attribute Value */
:access-subject :Role :IRS-agent
:access-subject :Role :auditor
:resource :Resource-id :tax-returns
:action :Action-id :write
</Target>
<Rule RuleId = “Rule 1”? Effect=”Permit”>
<Condition>
Function: and
/* :Attribute-Category : Attribute ID : Attribute Value
:environment : Time : ≥ 08:00?
:environment : Time : ≤ 18:00
</Condition>
</Rule>
<Rule RuleId = “Rule 2”? Effect=”Deny”>
<Condition>
Function: string-equal
/* :Attribute-Category :Attribute ID?
: access-subject :SubjectName
: resource :Resource-owner
</Condition>
</Rule>
</Policy>
5
訪問請求與響應
XACML規范了訪問請求和決策響應的數據傳輸格式，稱為XACML上下文。請求和響應格式代表了PDP與PEP之間的標準接口。如果PEP沒有在XACML上下文中生成訪問請求，那么PEP和PDP之間就需要一個上下文處理器。該處理器將特定應用環境的請求（來自PEP）轉換為XACML上下文請求，然后提交給PDP，還要將從PDP接收的XACML上下文響應轉換為特定應用環境的響應，然后再轉發給PEP。
請求上下文由一個或多個與策略元素（主體、資源、操作和環境）相關聯的屬性組成。例如，如果IRS代理Smith請求在上午9:30寫入Brown的報稅表，XACML訪問請求將攜帶主體屬性Subject-id和Role（屬性值分別為“Smith”和“IRS代理”），資源屬性resource-id和resource-owner（屬性值分別為“Tax-returns”和“Brown”），操作Action-id（值為“write”），環境屬性time（值為“09:30”）。該訪問請求的XACML代碼如下。
<Request>?
<Subject>
<Attribute AttributeId=”access-subject;Subject-id”>
<AttributeValue>smith</AttributeValue>
<Attribute AttributeId=”access-subject;Role”>
<AttributeValue>IRS-agent</AttributeValue>
</Subject>
<Resource>
<Attribute AttributeId=”resource;Resource-id”>
<AttributeValue>tax-returns</AttributeValue>
<Attribute AttributeId=”resource:Resource-owner”>
<AttributeValue>brown</AttributeValue>
</Resource>
<Action>
<Attribute AttributeId=”action;Action-id”>
<AttributeValue>write</AttributeValue>
</Action>
<Environment>
<Attribute AttributeId=”environment;time”>
<AttributeValue>09:30</AttributeValue>
</Environment>
</Request>?
策略2（3.4節）適用于此請求，因為其目標包括角色為“IRS代理或審計員”以“寫”模式訪問“資源稅申報表”的任何主體。該策略的規則1指定了允許訪問的時間區間，規則2拒絕了訪問主體與資源所有者相同（IRS代理或審計員訪問其自己的納稅申報表）的訪問請求。
響應上下文包含一個或多個從PDP獲得的、與訪問請求對應的評估結果，如決策、狀態、職責或建議（可選）。如上所述，決策結果包括：允許、拒絕、不適用或不確定（在發生錯誤的情況下）。狀態用于返回與錯誤相關的信息（可選）。對適用的策略或策略集，響應還可以選擇性地包括一個或多個義務或建議。
如果根據策略2來評估上述請求，則其XML編碼的響應如下：
<Response>
<Result>
<Decision>Permit</Decision>
<Status>
<StatusCode Value=”status:ok”/>
</Status>
</Result>
</Response>
6
委托
到目前為止，前面討論的XACML策略都是由單個授權機構創建和修改的訪問策略。單一授權機構（例如集中式管理員）被認為是可信的，這些訪問策略也不需要攜帶“頒發者（Issuer）”信息?；谛湃蔚恼Z義，這些策略所屬的類型或類可以稱為“可信的訪問策略”。但是在沒有任何其他類型策略的情況下，XACML策略庫中的策略都被簡單稱為“訪問策略”。可信策略的優點是可以被PDP直接用于計算決策。
為了能夠通過委托（從集中式管理員/單一授權機構到下級管理員（被委托的機構））來創建策略，XACML引入了一種新的策略（稱為管理策略）。這種策略能夠指定多個授權機構，用于：（A）創建訪問策略，或（b）創建一個或多個管理策略來指定更多的下級授權機構。這種指定的授權機構稱為受托方，受托方所擁有權限的域稱為情境（Situation）。這種策略管理能力要求XACML能夠規范委托策略的定義，從而產生了委托鏈（由一個或多個管理策略組成，并以訪問策略終結）。
?管理策略所引入的委托和情境兩個概念被封裝在它的目標中。因此，管理策略中的目標在內容和語義上與訪問策略中的目標不同?！拔小笨梢员徽J為是一種與主體類型相同的屬性類別，代表被授予創建訪問策略（完結委托鏈）或管理策略（添加到委托鏈）權限的實體。情境通過指定特權域來限制該權威機構的“領地”范圍，特權域用主體、資源和操作的屬性組合來表示。如果受托方創建了一個策略，為其特權域所覆蓋的資源授予訪問權限，則這種策略的類型為非可信訪問策略。非可信訪問策略與訪問策略（在沒有委托策略的策略存儲庫中）很容易區別開來，因為前者應該始終有一個頒發者。另外，如果受托方決定在該特權域的范圍內行使進一步委托的權利（而不是行使創建訪問策略的權利），則他創建的管理策略被稱為非可信管理策略。
這樣，在支持委托的XACML策略存儲庫中，存在4種子類型的策略：
●（可信）訪問策略
● 非可信訪問策略
● 可信管理策略
● 非可信管理策略
根（Root）或委托策略（即委托鏈）的起點是管理策略的一個子類，稱為可信管理策略?？尚殴芾聿呗允怯蓜摻?#xff08;可信）訪問策略的同一機構創建的，因此，可信管理策略也沒有頒發者標記，因為它總是由可信的集中式管理員創建。?
回顧一下，管理策略是通過一系列授權，將創建訪問策略的權利直接或間接地委托給多個機構。因此，可信管理策略授予受托方創建非可信管理策略或非可信訪問策略的權限。因此，委托鏈必須從可信管理策略開始，以非可信訪問策略結束，中間選擇性地包括一個或多個非可信管理策略。新創建的非可信管理策略或非可信訪問策略的情境是可信管理策略的情境的子集（特權范圍相同或更小）。此外，非可信管理策略或非可信訪問策略包括一個頒發者標記（其值與受托方相同）。所有這些策略至少有一個規則具有“允許”或“拒絕”效用。
6.1
委托鏈示例
如前所述，委托鏈的起點是可信管理策略，它的目標中存在一個受托方（下級管理員）和一個情境（下級管理員可以授權或進一步委托的特權域）。在圖3示例中，可信管理策略將“Smith”指定為下級管理員，將“Situation1”指定為特權域，Smith可以在其上對資源的訪問授權或執行進一步的委托。
圖3 XACML委托鏈（從下到上）的示例
回想一下，非可信管理策略也有一個受托方（其指定的下級）和與該受托方關聯的特權域。此外，非可信管理策略還應具有頒發者標記，該標記的值必須與某些管理策略中的受托方標記的值一致。只有創建非可信管理策略的受托方才會成為頒發者標記。在圖3中，一個由Smith發布的非可信管理策略（在上面討論的可信管理策略的授權下），指定Jones作為受托方（下級管理員），關聯的特權域是“Situation2”。特權域“Situation2”的范圍必須是特權域“Situation1”（在上面討論的可信管理策略的中指定）的子集。?
就像下級管理員Smith一樣，其委托方Jones可以對其特權域中指定的資源行使進一步的委托權或訪問授權。如果Jones對其特權域內的資源行使訪問授權（與Smith不同），則她將創建的訪問策略將是非可信訪問策略。在圖3中，Jones發布了一個非可信訪問策略（在Smith授予她的權限下），訪問權限的范圍被指定為“Situation3”。這個作用域必須是Smith委托給她的特權域（Situation2）的子集。?
XACML策略存儲庫中的委托策略（形成委托鏈）數量相對較少。大多數策略是由單個授權機構創建的（可信）訪問策略，如圖3所示。
6.2
委托鏈中的訪問請求處理
在沒有任何委托鏈的情況下，系統中的所有訪問策略都是（可信）訪問策略。在這些情況下，如果PDP能夠將請求中的屬性與訪問策略的目標相匹配，則該訪問策略就被視為適用的策略，并自動作為參與策略包含在相關的策略組合算法中（因為該策略是可信的）。在存在一個或多個委托鏈的情況下，PDP可以發現匹配目標（相對于訪問請求）來自非可信訪問策略中。由于它被指定為非可信訪問策略，因此只有在驗證策略頒發者（非可信訪問策略始終具有頒發者標記）的權威性后，PDP才會考慮將其包含在策略組合算法中。
權威性驗證通過查找導向可信管理策略的委托鏈來完成，該委托鏈在指向可信管理策略的路徑中可能包含0個或多個非可信管理策略。當策略被視為圖中的節點時，查找委托鏈的過程轉化為在該圖中查找/構造一條從非可信訪問策略節點到可信管理策略節點的路徑。為了構造圖中的每個邊，PDP（使用XACML上下文處理器）構造了一個管理請求，如圖3所示。
管理請求的結構與訪問請求相同，但除了基本的屬性類別（訪問主體、資源和操作）之外，它還使用兩個額外的屬性類別，即委托（delegate）和決策信息（decision-info）。如果策略Px恰好是一個適用的（匹配的）非可信訪問策略，則使用以下方法從策略Px生成管理請求，以便構造一條到策略Py的邊：
使用上述屬性構造出來的管理請求將按照策略Py的目標進行評估。如果評估結果為“允許”，則在策略Px和Py之間構造一條邊。總體邏輯是驗證策略Px的發布具有合法性，為此，應該存在一個策略，其“委托”設置為Px的策略頒發者。如果該策略是Py，則表示策略Px是在策略Py授權的基礎上發布。然后，從策略Py開始構造邊，直到找到到達可信管理策略的邊。
選擇適用策略以納入委托鏈組合算法的過程如圖4所示。假設對于一個訪問請求，匹配的目標可以在三個非可信訪問策略P31、P32和P33中找到。如果可以構造（通過一條邊或多條邊）從每一個策略到可信管理策略的路徑（從而驗證每個策略的發布合法性），則這些策略都可以成為適用策略（因此可以包括在相關的組合算法中）。在圖4中，可以從策略P31和P32構建這樣的路徑。從策略P31出發，此路徑經過非可信管理策略P21到達可信管理策略P11。從策略P32開始，此路徑經過非可信管理策略P22到可信管理策略P12。但是，非可信訪問策略P33不存在這樣的路徑。因此，在計算最終訪問決策的組合算法中，將僅使用策略P31和P32，而策略P33將被丟棄（由于無法驗證其權威性）。
圖4 利用授權鏈進行策略評估
下面是一個更具體的示例，說明了如何使用委托鏈來選擇適用的策略，這些策略用于組合算法以獲得最終的訪問決策。該示例給出了一個策略集，該策略集由4個策略組成：
?◆ 策略P1：可信管理策略，授予John（受托人）為“任何具有醫生角色的用戶讀取病歷”的情境創建策略的權限。
?◆ 策略P2：由John在P1授權下發布的非可信管理策略，授予Jessica（受托人）為“任何具有醫生角色的用戶讀取病歷”的情境創建策略的權限。由于P1的受托人與P2的策略頒發者匹配，并且策略P1和P2的情境相同，發布策略P2的權限顯然來自策略P1。因此P1和P2形成一個委托鏈。
?◆ 策略P3：Jeff發布的非可信訪問策略，授權Carol能夠讀取病歷。
?◆ 策略P4：Jessica發布的非可信訪問策略，使Carol能夠讀取病例。由于P2的受托人與P4的策略頒發者匹配，并且策略P2和P4的情境相同，發布策略P4的權限顯然來自策略P2。因此P2和P4形成了一個委托鏈。
上述4個策略的偽代碼形式如下：
<Policy Set>
<Policy P1> /* Trusted Administrative Policy */
<Target> /*:Attribute-Category :Attribute ID :Attribute Value */
:access-subject :role :doctor
:resource :resource-id :medical-records
:action :action-id :read
:delegate :subject-id :john
</Target>
<Rule R1>
Effect: PERMIT
</Rule R1>
</Policy P1>
<Policy P2> /* Untrusted Administrative Policy */
<Policy Issuer> john </Policy Issuer>
<Target> /*:Attribute-Category :Attribute ID :Attribute Value */
:access-subject :role :doctor
? :resource :resource-id :medical-records
? :action :action-id :read
? :delegate :subject-id :jessica
</Target>
<Rule R2>
? Effect: PERMIT
</Rule R2>
? </Policy P2>
?
<Policy P3> /* Untrusted Access Policy */
? <Policy Issuer> Jeff </Policy Issuer>
<Target> /*:Attribute-Category :Attribute ID :Attribute Value */
? :access-subject :subject-id :carol
? :resource :resource-id :medical-records
? :action :action-id :read
? </Target>
? <Rule R3>
? Effect: PERMIT
? </Rule R3>
?</Policy P3>
?<Policy P4> /* Untrusted Access Policy */
? <Policy Issuer> Jessica </Policy Issuer>
?<Target> /*:Attribute-Category :Attribute ID :Attribute Value */
? :access-subject :subject-id :carol
? :resource :resource-id :medical-records
? :action :action-id :read
? </Target>?
? <Rule R4>
? Effect: PERMIT
? </Rule R4>
</Policy P4>
<Policy Set>
通過將一個策略中的情境和受托人與另一個策略中的情境和策略頒發者匹配起來，可以看出P1、P2和P4形成了一個委托鏈，P3不屬于任何委派鏈。鑒于上述委托結構，考慮如何解決下列訪問請求REQ1。
<Request REQ1>?
<Attributes> /* :Attribute-Category : Attribute ID : Attribute Value */
:access-subject :subject-id :carol
:access-subject :role :doctor
:resource :resource-id :medical-records
:action :action-id :read
</Attributes>
</Request REQ1>
通過將請求REQ1中的屬性（及值）與策略集中策略目標的屬性（及值）匹配，可以發現只有策略P3和P4直接匹配，因為策略P1和P2包含委托屬性。由于策略P3和P4都是非可信訪問策略，因此必須通過發送管理請求來驗證它們各自的合法性。由于策略P3不屬于任何委托鏈，因此無法驗證其合法性。然而，策略P4的合法性可以通過委托鏈P1、P2、P4來驗證。
用于創建訪問策略的PAP接口也可用于創建支持委托所需的其他策略，包括非可信訪問策略、可信管理策略和非可信管理策略。在支持委托的系統中，至少需要兩類策略管理員，第一種是有權創建訪問策略的系統管理員，第二種是被授權創建非可信管理策略或非可信訪問策略的委托管理員，而這些非可信策略應符合當前策略存儲庫中任何可信管理策略授權的情境（或其子集）。
7
XACML體系架構
XACML參考體系結構定義了必要的功能組件（如圖5所示），以實現其策略的實施。其授權過程包含7個步驟，并依賴于4個功能層：執行、決策、訪問控制數據和管理。
PDP（負責計算針對主體請求的策略決策）是整個系統架構的核心。訪問請求（從PEP發往PDP）和策略決策（從PDP發往PEP）均通過標準化的請求和響應語言表達。PEP作為與其應用程序緊密耦合的操作環境組件來實現。PEP可能不能以XACML語法生成請求，也不能處理與XACML語法兼容的授權響應。為了將本地格式（與操作環境相關）的訪問請求轉換為XACML訪問請求（或將XACML中的PDP響應轉換為本地格式），XACML體系結構包括一個上下文處理器。上下文處理器還為訪問請求上下文提供其他屬性值（可以從PIP檢索）。在圖5中，上下文處理器沒有顯式地用組件表示，因為它被認為是PEP或PDP的一個組成部分。
請求由從PIP中提取的屬性組成，這些屬性至少應滿足目標匹配的需要。PIP雖然被表示為一個邏輯存儲庫，但實際上它也可以包含多個物理存儲庫。在計算決策時，PDP查詢存儲在PRP中的策略，如果請求的屬性不足以進行規則和策略評估，PDP可以請求上下文處理器在PIP中搜索其他屬性。存儲在PIP和PRP中的信息和數據共同組成了訪問控制數據并定義了當前授權狀態。
圖5 XACML參考體系結構
策略管理點（如PAP1）使用XACML策略語言來創建存儲在PRP中的訪問控制數據，包括策略規則、作為策略容器的策略集以及規則/策略組合算法等。PRP可以存儲可信或非可信策略。盡管沒有包括在XACML參考體系結構中，第2策略管理點（PAP2）用于創建和管理存儲在PIP中的訪問控制數據。PAP2實現了創建和管理屬性（名稱和值）所必需的管理例程。資源訪問點（RAP）用于對資源執行操作。在PDP返回許可決策的情況下，PEP向RAP發出命令以執行對資源內容的操作。如圖5中的虛線框所示，與PEP一樣，RAP也運行在應用程序的操作環境中，獨立于PDP及其支持組件。PDP及其支持組件通常以集中式授權服務器的模塊形式實現，集中式授權服務器可以為多種類型的操作提供授權服務。
總結
以上是生活随笔為你收集整理的ABAC相关标准在数据服务中的应用——XACML和NGAC的比较的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Flink SQL JSON Forma
- 下一篇： 如何解决ubuntu vi编辑器上下箭头