Вы подняли отличный вопрос. XACML был разработан для того, что я бы назвал транзакционной авторизацией, то есть авторизацией конкретной транзакции или потока. Например:
- Политика: медсестра может просматривать медицинскую карту пациента в своем отделении.
- Запрос: может ли медсестра Джо просмотреть медицинскую карту № 123?
Проблема заключается в том, что вы хотите контролировать доступ к большому или даже неизвестному количеству элементов. В этом случае вы можете (теоретически) просто отправить большое количество запросов. Вы даже можете использовать профиль множественного принятия решений XACML который позволяет создавать такие запросы, как:
- Запрос: может ли медсестра Джо просмотреть медицинскую карту № 123, 124, 125, 126 ...?
Затем вы получите столько ответов, сколько у вас было элементов MDP в запросе. Вы даже можете сделать матрицу, например.
- Запрос: может ли медсестра Джо просматривать и редактировать медицинские записи № 123, 124, 125, 126 ...?
- Ответ: 2х4 = 8 решений.
Однако он по-прежнему не так хорошо масштабируется (может доходить до тысяч, но вряд ли миллионов), и он не будет работать в сценариях разбивки на страницы и когда вы не знаете, сколько элементов у вас есть. Это не работает при разбивке на страницы, потому что представьте, что вы извлекаете 10 элементов (через разбиение на страницы), которые вы будете отображать, а затем авторизуете каждый из них. Вы рискуете, что на вашей странице окажется менее 10 элементов, что мешает работе пользователей.
В своем вопросе вы намекаете на использование обязательств и советов. Это вариант, но насчет недостатка вы правы. Он скрывает семантику authZ внутри совета и усложняет единичный случай. Это то, чем станет ваша политика
- Политика: медсестра может просматривать медицинскую карту пациента + обязанности: фильтр по отделению
Это требует большой работы над точкой применения политики (PEP).
Так какая альтернатива?
Использование обратного запроса (ARQ)
Компания Axiomatics (которая - отказ от ответственности - это то место, где я работаю) предложила новый API поверх PDP, который позволяет запрашивать политики открытым способом, который называется Обратный запрос. Вот сообщение разработчика по этой теме.
Вместо того, чтобы отправлять полномасштабные запросы XACML, вы отправляете частичный запрос (открытый вопрос), например.
- Что может просматривать Алиса?
Запрос может быть как общим, так и конкретным. Ниже приведены все действительные запросы:
- Что может случиться?
- Что может сделать Алиса?
- Что может просматривать Алиса?
- Какую медицинскую карту может просматривать Алиса?
- Какую медицинскую карту отделения скорой помощи может просмотреть Алиса?
- ...
Ответ будет набором выражений фильтра, вычисленных на основе политик, которые должны быть выполнены.
С учетом ранее заявленной политики
- Политика: медсестра может просматривать медицинскую карту пациента в своем отделении.
- Пользовательские метаданные: Алиса работает медсестрой в онкологической больнице округа Кук в Чикаго.
Возможные ответы были бы
- What can happen?
- Answer: A nurse can view the medical record of a patient in their department.
- What can Alice do?
- Answer: view the medical record of a patient in oncology.
- What can Alice view?
- Answer: medical record of a patient in oncology.
- Which medical record can Alice view?
- Answer: one of a patient in oncology.
- Which medical record in department ER can Alice view?
Запросы в вышеупомянутом примере сосредоточены на Алисе. Вместо этого вы могли сосредоточиться на ресурсе (медицинской карте) или даже на действии. Вам остается выбирать.
Надеюсь, это поможет, Дэвид.
person
David Brossard
schedule
22.05.2018
