Где дважды проверить атрибуты XACML-запроса в отношении поставщиков атрибутов в PDP?

Я оцениваю движки PDP и в данный момент даю попробовать AuthzForce Core. Оценка запроса со стороны PDP до сих пор проходит довольно хорошо:

//My request and pdp configuration files
File confLocation = new File("D:/docs/XACML/AuthZForce/IIA001/pdp.xml");//pdp.xml tells the pdp where the policies xml files are
File requestFile = new File("D:/docs/XACML/AuthZForce/IIA001/Request.xml");

//I instantiate the pdp engine and the xacml parser
final PdpEngineConfiguration pdpEngineConf = PdpEngineConfiguration.getInstance(confLocation, null, null);
PdpEngineInoutAdapter<Request, Response> pdp = PdpEngineAdapters.newXacmlJaxbInoutAdapter(pdpEngineConf);
XmlUtils.XmlnsFilteringParser xacmlParserFactory = XacmlJaxbParsingUtils.getXacmlParserFactory(false).getInstance();

//I parse the request file
Object request = xacmlParserFactory.parse(requestFile.toURI().toURL());
if (request instanceof Request) {
    //At this point I could access all request attributes or alter them

    //I let the PDP evaluate the request
    Response response = pdp.evaluate((Request) request);

    //I check the results inside the response
    for (Result result : response.getResults()) {
                    if (result.getDecision() == DecisionType.PERMIT) {
                        //it's permitted!

                    } else {
                        //denied!
                    }
    }
}

Теперь, согласно литературе, подобной [1], я не должен доверять атрибутам в данном запросе-xacml-файле. Когда бы ни было возможно, я должен проверить у Поставщика атрибутов (например, базы данных пациентов), действительно ли данные атрибуты (например, дата рождения пациента) действительно принадлежат пациенту, чтобы предотвратить атаки.

В противном случае злоумышленник может сделать пациента моложе в Запросе, чтобы получить доступ к записи пациента в качестве родительского опекуна.

Вопросы

  1. Является ли проверка запросов в отношении поставщиков атрибутов задачей PDP или другого лица?
  2. OASIS указал что-то конкретное по этому вопросу? Например, рабочий процесс или синтаксис файлов конфигурации
  3. Есть ли способ, чтобы мой движок pdp знал о поставщиках атрибутов?
  4. Должен ли я просто проверить предоставленный запрос самостоятельно перед Response response = pdp.evaluate((Request) request);?
Источник

2 ответа

Решение
  1. Я не знаю других реализаций XACML, но в отношении AuthzForce провайдеры атрибутов играют роль PIP в официальных терминах XACML (см. Определение PIP в глоссарии спецификации XACML), то есть отвечают за получение любых дополнительных атрибутов, которых нет в контекст запроса XACML (обычно это означает, что они не были предоставлены PEP изначально) всякий раз, когда PDP это необходимо для оценки политики. Это относится к шагам 5-8 стандартной модели потока данных XACML ( §3.1 спецификации XACML 3.0). Кроме того, если вы внимательно прочитаете спецификацию XACML, вы заметите, что фактическая сущность, вызывающая PIP для PDP, является так называемым обработчиком контекста. На практике это вопрос реализации, обработчик контекста может принимать разные формы. В AuthzForce это просто подкомпонент PDP, но он может быть и на стороне PEP, который зависит от приложения, особенно в типичном сценарии ABAC/XACML, где PDP является удаленным сервисом с точки зрения PEP. и, возможно, PDP общается со многими PEP в совершенно разных прикладных средах.
  2. Как упоминалось ранее, для рабочего процесса посмотрите раздел 3.1 Модель потока данных в основной спецификации XACML. Что касается синтаксиса, базовая спецификация XACML определяет синтаксис для политик, запросов и ответов на решения об авторизации, и ничего больше на данный момент. Вы можете найти другие вещи в профилях XACML, но не такие вещи, как синтаксис конфигурации, насколько мне известно.
  3. В AuthzForce механизм PDP получает информацию о поставщиках атрибутов с помощью конфигурации PDP, т.е. pdp.xml файл в вашем примере. Вам понадобятся два других файла (каталог XML и схема) в зависимости от того, какой поставщик атрибутов вы хотите использовать. Это задокументировано в разделе " Использование поставщиков атрибутов" в вики AuthzForce Core.
  4. Ваш код кажется мне тестовым кодом, так как вы получаете запрос xacml из локального файла, так что кажется, что вы имеете полный контроль над ним, поэтому нет необходимости проверять дальше. В более общем смысле, это зависит от фактического варианта использования, на самом деле, универсального правила для этого нет. Некоторые атрибуты (например, идентификатор субъекта в результате аутентификации) являются специфическими и известны только PEP в его собственной среде приложения, поэтому они являются обязанностью PEP. За некоторые другие атрибуты, скорее всего, несет ответственность PDP (через поставщиков атрибутов), если они могут быть разрешены центральным способом, например, атрибуты в каталоге компании или другой тип хранилища идентификаторов.
Источник

В дополнение к превосходному ответу @cdan, вот еще несколько указателей:

Является ли проверка запросов в отношении поставщиков атрибутов задачей PDP или другого лица?

PDP всегда доверяет информации (атрибутам), которую он получает, будь то от PEP или от PIP. Таким образом, PDP не нужно проверять значения, полученные от PEP, путем проверки с помощью PIP. Это непродуктивно и неэффективно. Если вы не можете доверять PEP для отправки правильного значения, как вы можете доверять ему, чтобы обеспечить принятие правильного решения?

OASIS указал что-то конкретное по этому вопросу? Например, рабочий процесс или синтаксис файлов конфигурации

Нет, мы не. Поведение PIP выходит за рамки спецификации XACML.

Есть ли способ, чтобы мой движок pdp знал о поставщиках атрибутов? Должен ли я просто проверить предоставленный запрос самостоятельно, прежде чем Response response = pdp.evaluate((Request) request);?

PDP должен быть настроен с PIP. PDP будет использовать все PIP, которые он может.

Источник
Другие вопросы по тегам