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