XACML 3.0 и несколько ресурсов

Question

Я пытаюсь выяснить, как реализовать механизм авторизации, используя реализацию Balana XACML (механизм предоставления прав WSO2 основан на Balana).

Когда пользователь запрашивает доступ к одному ресурсу (например, Боб хочет прочитать медицинскую карту), все просто.

Однако, скажем, Боб хочет прочитать все медицинские записи своих пациентов. Первая проблема здесь заключается в том, что должен быть способ выяснить, кто его пациенты. Мне также нужно получить атрибуты для каждой индивидуальной записи его пациентов. Дело в том, что я пытаюсь разобраться в этой ситуации, сводя к минимуму количество запросов атрибутов к моим PIP.

Перефразируя то, к чему я стремлюсь: я пытаюсь оценить, имеет ли Боб доступ к нескольким медицинским записям (записи неизвестны на момент создания запроса на принятие решения) на основе атрибутов, возвращаемых PIP (и я хочу, чтобы мои PIP например, иметь как можно меньше взаимодействий с базой данных).

В двух словах, я обнаружил, что при попытке управления доступом к коллекции ресурсов с помощью XACML все становится сложнее.

Я нашел несколько вариантов здесь:

1. Мой запрос содержит тему, действие, идентификатор ресурса и объем. Я использую профиль XACML Multiple Decision: PDP знает, что ресурсы потомков / потомков являются целевыми, поэтому он создаст несколько контекстов оценки для каждого потомка / потомка (но атрибуты ресурсов не были найдены). Затем, используя PIP, он будет извлекать атрибуты для каждого отдельного контекста оценки (например, получить идентификатор доктора Боба, а затем получить идентификатор доктора каждого отдельного ресурса). Если, например, мой PIP запрашивает базу данных, он будет выполнять множество запросов для каждого отдельного атрибута для каждого отдельного запроса, что сильно влияет на производительность.

2. Мой запрос содержит тему, действие, идентификатор ресурса. Я больше не использую профиль Multiple Decision. Однако, прежде чем создавать контекст оценки и просить PDP оценить мои запросы, я знаю, что мой ресурс на самом деле является коллекцией, поэтому я каким-то образом получаю все дочерние элементы / потомки и все их атрибуты, и только после того, как у меня есть вся эта информация, я вручную создаю индивидуальное решение. запросы для каждого потомка / потомка и вставьте туда все соответствующие атрибуты. Поэтому я даю PDP полный запрос на принятие решения, который содержит почти все необходимые атрибуты. Поскольку запросы на принятие решения имеют почти все атрибуты в контексте оценки, нет необходимости опрашивать мои PIP. Преимущество здесь в том, что я получил всю свою информацию до того, как PDP оценит решения, поэтому работа, которую должны выполнять PIP, сведена к минимуму. Однако я не уверен, должен ли я найти потомков / потомков и все их атрибуты до достижения PDP (где-то в обработчике контекста, как сказано в спецификации XACML).

3. Мой запрос содержит тему, действие, идентификатор ресурса. Я использую Multiple Decision Profile. У меня есть компонент, который может найти ресурсы для детей и потомков, и некоторые PIP. Все эти компоненты используют репозиторий, который гипотетически называется MedicalRecordsRepository. Этот репозиторий при запросе идентификаторов потомков / потомков также получает все атрибуты из базы данных и сохраняет всю эту информацию в кеше. Таким образом, впоследствии, при наличии нескольких контекстов оценки, которые оцениваются по отдельности, если PIP запрашивается для возврата атрибута, он получает атрибут из кэша репо. Таким образом, взаимодействие с базой данных сведено к минимуму. Однако проблема заключается в компоненте хранилища и его кэше.

Я прочитал спецификации, покопался, но пока не нашел решения этой проблемы. У кого-нибудь есть какие-либо идеи? Заранее спасибо!

Answer 1

В двух словах, я обнаружил, что при попытке управления доступом к коллекции ресурсов с помощью XACML все становится сложнее.

Вы правы. XACML хорошо обращается к транзакционному и функциональному управлению доступом. Он не очень хорошо справляется с контролем доступа к данным.

• контроль транзакционного доступа: может ли Алиса просматривать медицинскую карту №1?
• функциональный контроль доступа: может ли Алиса просматривать медицинские записи?
• контроль доступа к данным: какие медицинские записи может просматривать Алиса?

Я не уверен, что полностью понимаю ваши три подхода, но вы выделяете соответствующие проблемы, а именно

• не зная, сколько предметов
• извлечение атрибутов из внешнего источника атрибутов (представьте 10 атрибутов на каждую медицинскую карту, умноженных на 1 000 000 записей - это 10 миллионов просмотров)

По моему опыту, несколько запросов профиля решения хорошо работают, когда вы находитесь в тысячах запросов. Кроме того, я хотел бы рассмотреть обратный запрос аксиоматики (отказ от ответственности - я работаю для аксиоматики). Обратный запрос решает вашу проблему, предоставляя API, который позволяет задавать открытые вопросы, такие как

• Какие медицинские записи может просматривать Алиса?

Ответом будет набор условий, которые должны быть выполнены. Например, если ваша политика соответствует следующему (с использованием нотации ALFA):

Политика XACML с использованием нотации ALFA

policy accessMedicalRecord{
    target clause com.axiomatics.examples.actionId == "view" and objectType == "medical record"
    apply firstApplicable
    /**
     * Doctors can view medical records of patients they are assigned to
     */
    rule allowRegularAccess{
        target clause user.role == "doctor"
        condition patient.assignedDoctor == user.identifier
        permit
    }               
}

Образец запроса / ответа ARQ

• Запрос: Какие медицинские записи может просмотреть врач Алиса?
• Ответ: Разрешить, если patient.assignedDoctor == "Alice"

Ответ может быть переведен на язык запросов, например, SQL:

• SELECT id FROM MED_RECORDS WHERE assignedDoc = 'Alice';

Это может быть и другой язык запросов. Затем вы используете это для запроса источника данных, например, базы данных SQL и получения соответствующих медицинских карт.

Смотрите также этот Stackru Q & A.