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

Question

Я оцениваю движки 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);?

Answer 1

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

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

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

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

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

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

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

Answer 2

1. Я не знаю для других реализаций XACML, но в отношении AuthzForce провайдеры атрибутов играют роль PIP в официальных терминах XACML (см. Определение PIP в спецификации XACML * Глоссарий ), то есть отвечает за получение любых дополнительных атрибутов, которые не находятся в контексте запроса XACML (это обычно означает, что они не были предоставлены PEP изначально), всякий раз, когда PDP нуждается в этом для оценкиполитика.Это относится к шагам 5-8 стандартной модели потока данных XACML (§3.1 из XACML 3.0 spec ).Кроме того, если вы внимательно прочитаете спецификацию 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 (через поставщиков атрибутов), если они могут быть разрешены центральным способом, например, атрибуты в каталоге компании или другой тип хранилища идентификаторов.