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

Question

Я пытаюсь выяснить, как реализовать механизм авторизации, используя реализацию XACML Balana (механизм предоставления прав 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 и получения соответствующих медицинских карт.

См. Также Stackoverflow Q & A .