是的,策略可以寫入來自外部屬性存儲的引用屬性。
但是,實際上來自屬性的屬性通常並未在策略本身中指定,除了可能通過屬性ID中的命名模式指定。在XACML PDP參考體系結構中,請求上下文處理程序負責解析屬性ID併爲PDP生成值。
它是這樣的:當根據一組策略評估一個請求時,PDP在策略規則中遇到一個attributeID,它需要對請求做出決定。 PDP要求請求上下文處理程序從「無論哪裏」獲取該attributeID的值 - PDP不關心它來自哪裏。請求上下文處理程序可以查找隨請求提供的屬性中的屬性,也可以查找任意數量的外部屬性提供程序(如LDAP或AD或SAML)或普通舊數據庫中的屬性。請求處理程序可能會識別屬性ID中的命名模式(如名稱空間前綴)以知道從何處獲取它。
您希望您的attributeID足夠詳細,以瞭解它們是什麼以及它們的含義,但不是特定的,以至於當您將屬性提供程序移至其他計算機時,所有策略都會中斷。策略應該獨立於配置。
最終,請求處理程序查找屬性的位置是請求處理程序/ PDP服務器的配置問題,並且因產品供應商而異。
更新:要回答的第二次修正這個問題
你會寫你的策略執行的請求中提供的屬性值(S)和由外部源提供值的列表之間的比較。
請記住,屬性指示符返回一個值列表,因爲請求可能包含同一個attributeID的多個屬性值。您可以通過將屬性指示符包裝在「一次性」還原函數中,或者使用多對多交叉產品匹配函數來適應該問題,該函數將測試list1中的每個成員以獲得list2中的匹配。
除非您有特定的設計要求,只允許請求包含一個角色屬性,否則最好避免「一次性」減少,因爲它確實限制了您的選擇。你的Xacml 2.0策略可能看起來像這樣:(原諒語法錯誤,我的Xacml 2。0有點生鏽)
<Policy [...] RuleCombiningAlgorithm="deny-unless-permit">
<Rule [...]>
<Effect>Permit</Effect>
<Condition>
<Apply FunctionId=」urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of」>
<SubjectAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:role"
DataType="http://www.w3.org/2001/XMLSchema#string"/>
<SubjectAttributeDesignator
AttributeId="list-of-acceptable-roles-from-external-provider-attribute-id"
DataType="http://www.w3.org/2001/XMLSchema#string"/>
</Apply>
</Condition>
</Rule>
</Policy>
Xacml函數「at-least-one-member-of」取兩個列表作爲參數。對於第一個列表中的每個項目,它都會測試以查看該項目是否存在於第二個列表中。只要找到至少一個匹配,它就會返回true。
您示例中的屬性「... example:attribute:role」是您期望在請求中提供的屬性。如果要強制在請求中提供該屬性,可以在屬性標識符中設置MustBePresent =「true」。
「list-of-acceptable-roles ...」屬性是您的PDP上下文處理程序從某個外部提供程序識別並檢索的屬性ID。上下文處理程序尋找哪個前綴或模式以及從哪個提供程序獲取哪個提供程序是PDP配置的問題。
理想情況下,屬性id上的命名模式指示id與之相關聯的概念域或名稱空間,但是id沒有明確指示屬性值的物理位置或提供者。對於較長的應用程序生命週期和較低的維護成本,您希望能夠更改提供程序實施細節,而不必重寫所有策略。
您可以擁有供應商特定的屬性ID,這些ID可能只來自單個提供者,您可以擁有可由多個提供者提供的特定於應用程序的屬性ID,但僅對特定應用程序有意義,並且您可以擁有通用或標準化的屬性ID可能來自多個提供商,並可用於多個應用程序。 Oasis標準主體和特定於域的配置文件是查找標準化屬性ID及其語義或獲取關於如何組織自己的應用特定ID的想法的良好起點。
根據您的PDP和上下文處理程序的實現,還可以使用「Issuer」字段作爲限制屬性提供程序列表的方式。 Xacml規範並沒有多說使用Issuer字段,但解耦策略與提供者實現細節的相同目標仍然成立。
在回答第一個問題後,將問題重寫爲不同的問題確實沒有幫助。只需創建一個新問題,以便原始問題及其答案可以作爲後代的參考。 – dthorpe