Авторизация и проверка с помощью ABAC/XACML

Я не уверен, где проходят границы авторизации с помощью ABAC/XACML и где мне следует использовать валидацию.

Пример 1

У меня есть класс Пользователь и класс Сообщение. Когда пользователь U1 создает новое сообщение M1, атрибут создателя M1 должен быть U1.

Пример 2

У меня есть класс Пользователь. Когда кто-то создает нового пользователя U2, размер пароля должен быть больше 8.

Пример 3

У меня есть класс Пользователь. Когда кто-то создает нового пользователя U3, имя пользователя должно быть уникальным.

Но где мне это проверить. Должен ли я проверить его программно или авторизовать его с запросом к PEP. В частности, пример 2 на самом деле не означает, что вам не разрешено делать эту проблему (авторизация), и более того, вы сделали что-то не так (проверка).


validation authorization access-control abac xacml
person benkuly    schedule 11.11.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Ни один из приведенных вами примеров не является хорошим примером ABAC/XACML.

Пример №1

Когда пользователь U1 создает новое сообщение M1, тогда атрибут создателя M1 должен быть U1.

Это полностью бизнес-логика. В процессе создания сообщения для атрибута владельца M1 будет установлено значение U1. Это не имеет ничего общего с XACML. XACML касается авторизации, т. е. того, разрешено ли пользователю выполнять действие. В этом случае вы можете написать правило XACML о том, может ли пользователь U1 создать сообщение; может ли пользователь U1 просматривать или редактировать сообщение, принадлежащее U2.

Пример #2

У меня есть класс Пользователь. Когда кто-то создает нового пользователя U2, размер пароля должен быть больше 8.

Это проверка PoV вашего приложения. Ваше приложение не связано с аутентификацией или паролями. Это зависит от менеджера паролей. Сам менеджер паролей (например, LDAP, AD...) имеет политики в отношении надежности/срока действия/формата пароля. Эти политики могут быть в XACML, хотя на сегодняшний день я видел только проприетарные форматы.

Пример 3

У меня есть класс Пользователь. Когда кто-то создает нового пользователя U3, имя пользователя должно быть уникальным.

Опять же, речь идет о проверке. Это не имеет ничего общего с вашим приложением, а скорее с решением для управления учетными записями пользователей, которое вы используете, например. LDAP. Там вы можете решить иметь правила, запрещающие одно и то же имя пользователя или запрещающие определенные символы, например. знак. Решения для управления пользователями определенно могут использовать XACML, но с точки зрения вашего приложения это ортогонально.

person David Brossard    schedule 20.11.2017
comment
Спасибо! Вы ответили на вопрос, но я думаю, что моя ошибка заключалась в том, что я использовал Users в примерах. Например. Пример 1 — это интерфейс REST, а Creator — его атрибут. Только админ может выбрать другого creator кроме себя. Пример 2 может быть BankAccount, который должен иметь положительный баланс при создании. Пример 3 может быть классом Building, который должен иметь уникальный Adress. Я думаю, что все три примера можно решить с помощью ABAC/XACML, но я не уверен, что они должны это делать. Как отличить авторизацию от проверки? Разве ABAC/XACML тоже не является бизнес-логикой? - person benkuly; 21.11.2017
comment
Короче говоря, это авторизация или проверка, когда мы работаем на уровне поля (может ли subject выполнить action например CREATE CHANGE DELETE с конкретным полем resource в зависимости от значения этого поле и другие ограничения)? - person benkuly; 21.11.2017
comment
это будет авторизация. Итог: вас волнует сообщение о том, что пользователь пытается выполнить определенное действие на данном ресурсе? Если да, то это авторизация - person David Brossard; 21.11.2017