是的，可以编写策略来引用来自外部属性存储的属性。
但是，通常不会在策略本身中指定属性的实际来源，除非可能通过属性 ID 中的命名模式来指定。在 XACML PDP 参考架构中，请求上下文处理程序负责解析属性 ID 并为 PDP 生成值。
它是这样的：在根据一组策略评估请求时，PDP 在策略规则中遇到一个属性 ID，它需要形成关于请求的决策。 PDP 要求请求上下文处理程序“从任何地方”获取该属性ID 的值——PDP 并不关心它来自哪里。请求上下文处理程序可以在随请求提供的属性中查找属性，或者在任意数量的外部属性提供者中查找属性，例如 LDAP 或 AD 或 SAML 或普通旧数据库。请求处理程序可能会识别attributeID 中的命名模式（如命名空间前缀）以了解从何处获取它。
您希望您的属性 ID 足够具体，以了解它们是什么以及它们的含义，但不要太具体以至于当您将属性提供程序移动到另一台机器时，您的所有策略都会中断。策略应该独立于配置。
最终，请求处理程序在哪里查找属性取决于请求处理程序/PDP 服务器的配置，并且会因产品供应商而异。
更新：回答此问题的第二次修订
您将编写策略以在请求中提供的属性值与外部来源提供的值列表之间进行比较。
请记住，属性指示符会返回值列表，因为请求可能包含同一个属性 ID 的多个属性值。您可以通过将属性指示符包装在“唯一”归约函数中，或使用多对多叉积匹配函数来测试 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。 Oasis 标准机构和特定领域的配置文件是查找标准化属性 ID 及其语义或了解如何组织您自己的应用特定 ID 的良好起点。
根据您的 PDP 和上下文处理程序实现，也可以使用“Issuer”字段作为约束属性提供者列表的一种方式。 Xacml 规范对 Issuer 字段的使用没有太多说明，但将策略与提供者实现细节分离的相同目标仍然存在。