Ваш вопрос содержит 2 вопроса:
- Как мне смоделировать мою политику?
- Как защитить свое приложение? (Исполнение решений)
Прежде всего, давайте смоделируем вашу политику в ALFA:
Правило. Продавец может просматривать автомобиль тогда и только тогда, когда присвоенный автомобилю идентификатор продавца совпадает с личностью запрашивающего пользователя.
В АЛЬФА это становится:
namespace com.axiomatics{
/**
* A sales person can view a car if and only if the car's assigned salesperson
* identifier is equal to the requesting user's identity.
*/
policy viewCars{
target clause user.role=="sales person" and actionId == "view" and objectType=="car"
apply firstApplicable
/**
*
*/
rule allowAssignedUser{
permit
condition car.assignedSalesPerson==user.identifier
}
}
}
Это ваше моделирование отсортировано.
Теперь, что касается второго вопроса: как мне обеспечить авторизацию? Я бы возражал против смешивания ролей, управляемых политиками Spring Security и XACML, если вы их правильно не задокументируете.
Есть два подхода, которые вы можете использовать.
- Используйте профиль множественного решения — это часть набора дополнительных профилей XACML 3.0 или
- Используйте подход обратного запроса — он характерен только для аксиоматики. Я не уверен, что WSO2 поддерживает это.
Профиль множественного принятия решений (MDP) определяет, как вы можете отправлять несколько запросов на авторизацию, написанных в xacml в точку принятия решения о политике (PDP) с помощью одного запроса. Это сэкономит вам несколько поездок туда и обратно. Ответ, который вы получите, будет содержать столько решений, сколько запросов на авторизацию в исходном отправленном запросе. Вы экономите время на транспортировке и оценке. Используйте MDP, когда вы знаете, сколько элементов вы хотите защитить, и когда это число составляет от 1 до 1000, но не больше (хотя, конечно, всегда стоит попробовать). Подробнее о MDP можно прочитать в блоге Axiomatics. . В вашем случае поток будет следующим:
- Звоните
getCarDetails(Object user).
- Вызовите базовую базу данных, чтобы получить все автомобили
- Позвоните в PDP в режиме MDP для всех найденных записей, чтобы получить решение.
- Вернуть только те записи, на которые у вас было разрешение
Главный недостаток заключается в том, что вы можете получить тысячи, если не миллионы записей из базы данных. Тогда использование MDP нецелесообразно.
Подход обратного запроса интересен, хотя и специфичен для аксиоматики. Он определяет новый интерфейс поверх XACML PDP, который позволяет запрашивать механизм авторизации обратным способом. Вместо того, чтобы спрашивать:
- Может ли Алиса просмотреть машину №123?
Обратный запрос позволяет вам спросить
- Какие автомобили может просматривать Алиса?
Вместо ответа «Разрешить» или «Запретить» ответ представляет собой выражение фильтра, такое как оператор SQL, например.
- ВЫБЕРИТЕ ИДЕНТИФИКАТОР ИЗ автомобилей, ГДЕ назначен SP='Alice';
Все, что вам нужно сделать, это использовать оператор SQL для вашей базы данных, чтобы запросить ее и вернуть только выделенные данные. Это работает независимо от того, сколько данных у вас есть в вашей базе данных. Вы можете найти дополнительную информацию о ARQ SQL через этот веб-семинар.
person
David Brossard
schedule
22.12.2014
