Comments 5
Когда-то работал в Axiomatics, разрабатывающих как раз инструменты для XACML. Интересный механизм.
А если чуть более детально, чем интересный? Компаний, которые разрабатывают XACML инструменты, не так много, соответственно опыт сотрудника одной из них очень интересен. Поделитесь?
> Хотя эта схема из стандарта может выглядеть немного устрашающе на первый взгляд, в ней все довольно просто.

На самом деле нет :)

К сожалению, этот психологический прием не работает с XACML. Вспомнилась статья в университетском журнале — после слов «несложно показать, что» следовало несколько страниц формул. У вас похожий подход, «XACML простой», а затем, предположительно, многостраничное пояснение «простых моментов» :)

Например, PolicySet может содержать вложеный PolicySet, который в свою очередь является «контейнером» для других PolicySet'ов и т.д., соответственно финальная иерархия будет достаточно сложной для понимания (на каждом уровне свой combining algorithm и т.д.)

Все еще легко? Тогда насколько хорошо вы сможете объяснить факт существования следующей таблицы? :)

image

> Тестирование выполнения политик. Администратор может указать нужный контекст, выбрать политики и пошагово изучить процесс вычисления, используя для этого удобный интерфейс.

Мы ведь говорим о системе, которая может быть life-critical. Соответственно, один из вопросов: сможет ли Администратор быть на все 100% уверен в своем наборе политик проведя несколько «точечных» тестов с несколькими контекстами?

Но это я так, на самом деле спасибо за статью и за все детали. С ней порог вхождения существенно ниже.
У вас похожий подход, «XACML простой», а затем, предположительно, многостраничное пояснение «простых моментов» :)

Такое многостраничное объяснение я сделал для того, чтобы читатель смог правильно понять как все устроено. Понять основные принципы, которые на мой взгляд действительно просты.

Например, PolicySet может содержать вложеный PolicySet, который в свою очередь является «контейнером» для других PolicySet'ов и т.д., соответственно финальная иерархия будет достаточно сложной для понимания (на каждом уровне свой combining algorithm и т.д.)


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

Все еще легко? Тогда насколько хорошо вы сможете объяснить факт существования следующей таблицы? :)


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

Мы ведь говорим о системе, которая может быть life-critical. Соответственно, один из вопросов: сможет ли Администратор быть на все 100% уверен в своем наборе политик проведя несколько «точечных» тестов с несколькими контекстами?

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

image

Вот эта картинка судя по имени действия будет работать так:
«Редактировать, Создавать или Удалять документ может владелец, менеджер или старший менеджер в рабочее время»

потому что во всех действиях стоит название «Изменить документ»

Применение в коде мне не слишком понятно. Группа политик получается не вызывается, а вызывается политика «создать», которая должна чекнуть в какой группе она находится и запустить всю группу, при этом не зная какую из политик действия «изменить документ» нужно выполнить

Вообще правильно ли я понимаю что в более простом случае в базе стоит хранить массивы атрибутов под политику, а в момент проверки собирать их рекурсивно по имени аттрибутов?
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

Since 1996

Location

Россия

Employees

201–500 человек

Registered

17 April 2013