Как сослаться на внешний набор разрешений в политике XACML?

Question

Первоначально я спросил: "Как вы пишете политику, требующую, чтобы субъекту был предоставлен доступ к запрошенному разрешению, где набор разрешенных разрешений находится во внешнем хранилище атрибутов. Можете ли вы сослаться на внешний набор разрешений в политике?" На второй вопрос был дан утвердительный ответ, поэтому я немного пересмотрю вопрос, чтобы сосредоточиться на том, "как".

Может ли кто-нибудь предоставить фрагмент политики xacml (или даже псевдо-xacml), который требует, чтобы идентификатор атрибута роли (будет предоставлен запросом) находился в наборе ролей, которые идентифицируются другим идентификатором атрибута (управляемым внешним хранилищем атрибутов).

Для обеспечения отправной точки ниже приведен пример из http://docs.oasis-open.org/xacml/2.0/XACML-2.0-OS-ALL.zip. В этом случае роль встроена.

<Subject>
    <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">administrator</AttributeValue>
        <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:role" 
                                DataType="http://www.w3.org/2001/XMLSchema#string"/>
    </SubjectMatch>
</Subject>

Answer 1

Да, политики могут быть записаны для ссылки на атрибуты, которые поступают из внешнего хранилища атрибутов.

Однако то, откуда на самом деле берутся атрибуты, обычно не указывается в самой политике, за исключением, возможно, шаблона именования в идентификаторе атрибута. В эталонной архитектуре XACML PDP обработчик контекста запроса отвечает за разрешение идентификаторов атрибутов и создание значений для PDP.

Это выглядит примерно так: при оценке запроса по набору политик PDP обнаруживает атрибут атрибута в правиле политики, который необходим для формирования решения о запросе. PDP запрашивает обработчик контекста запроса, чтобы получить значение этого attribute ID "от куда угодно" - PDP не волнует, откуда он берется. Обработчик контекста запроса может искать атрибут в атрибутах, предоставленных в запросе, или в любом количестве внешних поставщиков атрибутов, таких как LDAP или AD или SAML или простые старые базы данных. Обработчик запроса может распознавать шаблоны именования (например, префиксы пространств имен) в attribute ID, чтобы знать, где его получить.

Вы хотите, чтобы ваши атрибуты ID были достаточно конкретными, чтобы знать, что они есть и что они означают, но не настолько специфичными, чтобы все ваши политики ломались, когда вы перемещаете свой поставщик атрибутов на другой компьютер. Политики должны быть независимыми от конфигурации.

В конечном счете, когда обработчик запросов ищет атрибуты, это вопрос конфигурации обработчика запросов / сервера PDP, и он зависит от поставщика продукта.

Обновление: чтобы ответить на 2-ю редакцию на этот вопрос

Вы должны написать свою политику для сравнения значений атрибутов, указанных в запросе, со списком значений, предоставленных внешним источником.

Имейте в виду, что указатель атрибута возвращает список значений, поскольку запрос может содержать несколько значений атрибута для одного и того же attribute 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 "по крайней мере один член" принимает два списка в качестве параметров. Для каждого элемента в первом списке он проверяет, существует ли этот элемент во втором списке. Он возвращает истину, как только находит хотя бы одно совпадение.

Атрибут "...example:attribute:role" из вашего примера - это атрибут, который вы ожидаете предоставить в запросе. Если вы хотите принудительно указать, что атрибут должен быть указан в запросе, вы можете установить MustBePresent="true" в указателе атрибута.

Атрибут "список-приемлемых ролей..." - это идентификатор атрибута, который ваш обработчик контекста PDP распознает и получает от какого-либо внешнего поставщика. Какой префикс или шаблон ищет контекстный обработчик и от какого поставщика он выбирает, зависит от конфигурации PDP.

В идеале шаблон именования в идентификаторе атрибута указывает концептуальный домен или пространство имен, с которым связан идентификатор, но идентификатор явно не указывает физическое местоположение или поставщика значения (значений) атрибута. Чтобы продлить срок службы приложений и снизить затраты на обслуживание, вы захотите изменить детали реализации вашего провайдера без необходимости переписывать все ваши политики.

У вас могут быть специфичные для поставщика идентификаторы атрибутов, которые, вероятно, будут поступать только от одного поставщика, у вас могут быть специфические для приложения идентификаторы атрибутов, которые могут предоставляться несколькими поставщиками, но они имеют смысл только для конкретного приложения, и вы можете иметь общий или стандартизированный атрибут идентификаторы, которые могут поступать от нескольких поставщиков и использоваться в нескольких приложениях. Тело стандартов Oasis и специфичные для домена профили являются хорошей отправной точкой для поиска стандартизированных идентификаторов атрибутов и их семантики или для получения идей о том, как организовать свои собственные идентификаторы приложений.

В зависимости от реализации вашего PDP и обработчика контекста может также использоваться поле "Эмитент" как способ ограничения списка поставщиков для атрибута. Спецификация Xacml мало говорит об использовании поля Issuer, но те же цели отделения политики от деталей реализации провайдера по-прежнему сохраняются.