Да, политики могут быть записаны для ссылок на атрибуты, поступающие из внешнего хранилища атрибутов.
Однако, откуда фактически берутся атрибуты, обычно не указывается в самой политике, за исключением, возможно, шаблона именования в идентификаторе атрибута. В эталонной архитектуре XACML PDP обработчик контекста запроса отвечает за разрешение идентификаторов атрибутов и создание значений для PDP.
Это выглядит примерно так: при оценке запроса по набору политик PDP обнаруживает атрибут атрибута в правиле политики, который необходим для формирования решения о запросе. PDP запрашивает обработчик контекста запроса, чтобы получить значение этого attributeID «от куда угодно» - PDP не волнует, откуда он берется. Обработчик контекста запроса может искать атрибут в атрибутах, предоставленных в запросе, или в любом количестве внешних поставщиков атрибутов, таких как LDAP или AD или SAML или простые старые базы данных. Обработчик запроса может распознавать шаблоны именования (например, префиксы пространств имен) в attributeID, чтобы знать, где его получить.
Вы хотите, чтобы ваши attributeID были достаточно конкретными, чтобы знать, что они есть и что они значат, но не настолько специфичными, чтобы все ваши политики ломались, когда вы перемещаете свой поставщик атрибутов на другой компьютер. Политики должны быть независимыми от конфигурации.
В конечном счете, когда обработчик запросов ищет атрибуты, это вопрос конфигурации обработчика запросов / сервера PDP и зависит от поставщика продукта.
Обновление: чтобы ответить на 2-ю редакцию на этот вопрос
Вы должны написать свою политику, чтобы выполнить сравнение между значениями атрибутов, предоставленными в запросе, и списком значений, предоставленных внешним источником.
Имейте в виду, что указатель атрибута возвращает список значений, поскольку запрос может содержать несколько значений атрибута для одного и того же 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 "по крайней мере один член" принимает два списка в качестве параметров. Для каждого элемента в первом списке он проверяет, существует ли этот элемент во втором списке. Он возвращает true, как только находит хотя бы одно совпадение.
Атрибут «... example: attribute: role» из вашего примера - это атрибут, который вы ожидаете предоставить в запросе. Если вы хотите принудительно указать, что атрибут должен быть указан в запросе, вы можете установить MustBePresent = "true" в указателе атрибута.
Атрибут «список приемлемых ролей ...» - это идентификатор атрибута, который ваш обработчик контекста PDP распознает и извлекает из какого-либо внешнего поставщика. Какой префикс или шаблон ищет контекстный обработчик и от какого поставщика он выбирает, зависит от конфигурации PDP.
В идеале шаблон именования в идентификаторе атрибута указывает концептуальный домен или пространство имен, с которым связан идентификатор, но идентификатор явно не указывает физическое местоположение или поставщика значения (значений) атрибута. Чтобы продлить срок службы приложений и снизить затраты на обслуживание, вы захотите изменить детали реализации вашего провайдера без необходимости переписывать все ваши политики.
У вас могут быть специфичные для поставщика идентификаторы атрибутов, которые, вероятно, будут поступать только от одного поставщика, у вас могут быть специфичные для приложения идентификаторы атрибутов, которые могут предоставляться несколькими поставщиками, но они имеют смысл только для конкретного приложения, и вы можете иметь общие или стандартизированные идентификаторы атрибутов, которые могут поступать от нескольких поставщиков и использоваться в нескольких приложениях. Тело стандартов Oasis и специфичные для домена профили являются хорошей отправной точкой для поиска стандартизированных идентификаторов атрибутов и их семантики или для получения идей о том, как организовать свои собственные идентификаторы приложений.
В зависимости от вашего PDP и реализации обработчика контекста также возможно использовать поле «Эмитент» в качестве способа ограничения списка поставщиков для атрибута. Спецификация Xacml мало говорит об использовании поля Issuer, но те же цели отделения политики от деталей реализации провайдера по-прежнему сохраняются.