Комментарии 6
Когда-то работал в Axiomatics, разрабатывающих как раз инструменты для XACML. Интересный механизм.
> Хотя эта схема из стандарта может выглядеть немного устрашающе на первый взгляд, в ней все довольно просто.
На самом деле нет :)
К сожалению, этот психологический прием не работает с XACML. Вспомнилась статья в университетском журнале — после слов «несложно показать, что» следовало несколько страниц формул. У вас похожий подход, «XACML простой», а затем, предположительно, многостраничное пояснение «простых моментов» :)
Например, PolicySet может содержать вложеный PolicySet, который в свою очередь является «контейнером» для других PolicySet'ов и т.д., соответственно финальная иерархия будет достаточно сложной для понимания (на каждом уровне свой combining algorithm и т.д.)
Все еще легко? Тогда насколько хорошо вы сможете объяснить факт существования следующей таблицы? :)
> Тестирование выполнения политик. Администратор может указать нужный контекст, выбрать политики и пошагово изучить процесс вычисления, используя для этого удобный интерфейс.
Мы ведь говорим о системе, которая может быть life-critical. Соответственно, один из вопросов: сможет ли Администратор быть на все 100% уверен в своем наборе политик проведя несколько «точечных» тестов с несколькими контекстами?
Но это я так, на самом деле спасибо за статью и за все детали. С ней порог вхождения существенно ниже.
У вас похожий подход, «XACML простой», а затем, предположительно, многостраничное пояснение «простых моментов» :)
Такое многостраничное объяснение я сделал для того, чтобы читатель смог правильно понять как все устроено. Понять основные принципы, которые на мой взгляд действительно просты.
Например, PolicySet может содержать вложеный PolicySet, который в свою очередь является «контейнером» для других PolicySet'ов и т.д., соответственно финальная иерархия будет достаточно сложной для понимания (на каждом уровне свой combining algorithm и т.д.)
Да, они могут вкладываться друг в друга сколько угодно. Но это сложность не XACML, это сложность бизнес-правила, которое представляет собой такую громоздкую иерархию условий. XACML в данном случае лишь показывает свою гибкость, раз позволяет описывать бизнес-правила любой сложности.
Все еще легко? Тогда насколько хорошо вы сможете объяснить факт существования следующей таблицы? :)
Тут просто показано то, как различные алгоритмы комбинации комбинируют четыре возможных результата вычислений. Мне кажется, что тут нет ничего сложного.
Мы ведь говорим о системе, которая может быть life-critical. Соответственно, один из вопросов: сможет ли Администратор быть на все 100% уверен в своем наборе политик проведя несколько «точечных» тестов с несколькими контекстами?
Я считаю, что может. Тестирование это лишь один из вариантов проверки. К этой задаче можно подойти по разному автоматически анализируя политики и возможные атрибуты.
Вот эта картинка судя по имени действия будет работать так:
«Редактировать, Создавать или Удалять документ может владелец, менеджер или старший менеджер в рабочее время»
потому что во всех действиях стоит название «Изменить документ»
Применение в коде мне не слишком понятно. Группа политик получается не вызывается, а вызывается политика «создать», которая должна чекнуть в какой группе она находится и запустить всю группу, при этом не зная какую из политик действия «изменить документ» нужно выполнить
Вообще правильно ли я понимаю что в более простом случае в базе стоит хранить массивы атрибутов под политику, а в момент проверки собирать их рекурсивно по имени аттрибутов?
«не определено, но могло бы быть разрешено» (indeterminate{D}), который относится к тем правилам, во время оценки которых произошла ошибка, а их эффект в случае успешной оценки был бы «запретить».
Наверное имело в виду эффект в случае успешной оценки был бы «разрешить».?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Знакомство с XACML — стандартом для Attribute-Based Access Control