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

Question

Фон

У меня есть бэк-офис, который управляет информацией из разных источников. Часть информации находится в базе данных, к которой может обращаться бэк-офис, а часть управляется с помощью доступа к веб-службам. Такие службы обычно предоставляют операции CRUD плюс постраничный поиск.

Существует система контроля доступа, которая определяет, какие действия пользователю разрешено выполнять. Решение о том, может ли пользователь выполнить какое-либо действие, определяется правилами авторизации, которые зависят от базовой модели данных. Например. есть правило, которое позволяет пользователю редактировать ресурс, если он является владельцем этого ресурса, где владелец является столбцом в таблице ресурсов. Существуют и другие правила, такие как «пользователь может редактировать ресурс, если этот ресурс принадлежит организации, а пользователь является членом этой организации». Этот подход хорошо работает, когда модель предметной области непосредственно доступна для системы контроля доступа. Его главное преимущество заключается в том, что он избегает репликации информации, которая уже присутствует в модели предметной области.

Когда данные для манипулирования поступают из веб-службы, такой подход начинает вызывать проблемы. Я вижу различные подходы, о которых я расскажу ниже.

Реализация контроля доступа в сервисе

Этот подход кажется естественным, потому что в противном случае кто-то может обойти контроль доступа, вызвав службу напрямую. Проблема в том, что бэк-офис не имеет возможности узнать, какие действия доступны пользователю для конкретного объекта . Из-за этого невозможно отключить опции, недоступные пользователю, такие как кнопка «Изменить».

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

Реализация контроля доступа в бэк-офисе

Предполагая, что служба доверяет приложению backoffice, можно решить реализовать контроль доступа в backoffice. Похоже, это решает вопрос о том, какие действия доступны пользователю. Основная проблема с этим подходом заключается в том, что больше невозможно выполнять постраничный поиск , потому что теперь служба будет возвращать все совпадающие сущности вместо совпадающих сущностей, которые пользователь также имеет право просматривать.

Внедрение централизованной службы контроля доступа

Если бы контроль доступа был централизован в одном сервисе, каждый мог бы использовать его для просмотра прав доступа к конкретным объектам. Однако мы бы потеряли способность использовать модель домена для реализации правил контроля доступа . Этот подход также связан с производительностью, поскольку для возврата списков результатов поиска, содержащих только авторизованные результаты, невозможно отфильтровать запрос к базе данных с помощью правил контроля доступа. Необходимо выполнить фильтрацию в памяти после получения всех результатов поиска .

Заключение

Я застрял, потому что ни одно из вышеперечисленных решений не является удовлетворительным. Какие еще подходы можно использовать для решения этой проблемы? Есть ли способы обойти ограничения предложенных мною подходов?

Answer 1

Различайте компоненты вашей системы контроля доступа и реализуйте каждый, где это имеет смысл.

Доступ к конкретным результатам поиска в списке должен осуществляться службой, которая считывает результаты, а пользовательский интерфейс никогда не долженнеобходимо знать о результатах, к которым у пользователя нет доступа.Если пользователь может или не может редактировать или взаимодействовать другими способами с данными, которые ему разрешено видеть, служба должна возвращать эти данные с флагами, указывающими, что пользователь может делать, и пользовательский интерфейс должен отражать эти флаги.Служба, реализующая эти взаимодействия, должна , а не доверять пользовательскому интерфейсу, она должна проверять, есть ли у пользователя доступ при вызове службы.Возможно, вам придется реализовать логику управления доступом в нескольких запросах к базе данных.

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

Answer 2

Я понимаю, что мой ответ очень опоздал - на 3 года позже.Стоит пролить новый свет на вековую проблему.Еще в 2011 году access-control не был таким зрелым, как сегодня.В частности, существует новая модель abac вместе со стандартной реализацией xacml , которая делает возможной централизованную авторизацию.

В вопросе OP OP пишет:после повторного централизованного контроля доступа:

Реализация централизованной службы контроля доступа

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

Недостатки, которые упоминает ОП, могут быть истинными в домашней системе контроля доступа,в RBAC или в ACL.Но они больше не верны в abac и xacml .Давайте рассмотрим их по одному.

Возможность использовать модель домена для реализации правил контроля доступа

С управлением доступом на основе атрибутов ( abac ) и расширяемымЯзык разметки контроля доступа ( xacml ), можно использовать модель домена и ее свойства (или атрибуты) для написания политик контроля доступа.Например, если используется случай, когда врач желает просмотреть медицинские записи, модель домена будет определять объект Doctor с его свойствами (местоположение, единица измерения и т. Д.), А также объект Medical Record.Правило в XACML может выглядеть следующим образом:

• Пользователь с ролью == doctor может выполнить действие == представление объекта типа == медицинская карта, если и только если doctor.location== medicalRecord.location.
• Пользователь с ролью == doctor может выполнить действие == редактировать объект типа == медицинская карта, если и только если doctor.id == medicalRecord.assignedDoctor.id

Одним из ключевых преимуществ XACML является точное отражение бизнес-логики и доменной модели ваших приложений.

Проблема производительности - возможность фильтровать элементы из БД

В прошлом действительно было невозможно создавать выражения фильтра.Это означало, что, как указывает OP, сначала нужно будет извлечь все данные, а затем отфильтровать данные.Это было бы дорогой задачей.Теперь, с XACML, можно добиться обратного запроса.Возможность выполнить обратный запрос - создать вопрос типа «Какую медицинскую карту может просматривать Алиса?» вместо традиционного бинарного вопроса «Может ли Алиса просматривать медицинские записи # 123?» .Ответом обратного запроса является условие фильтра, которое можно преобразовать в оператор SQL, например, в этом сценарии SELECT id FROM medicalRecords WHERE location=Chicago, если, конечно, доктор находится в Чикаго.

Как выглядит архитектура?

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

Answer 3

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

Не совсем.Возвращайте поле / свойство флагов из веб-службы для каждой записи / объекта, которые затем можно использовать для настройки пользовательского интерфейса в зависимости от того, что может сделать пользователь.Флаги основаны на той же информации, которая используется для контроля доступа, к которому служба все равно обращается.Это также позволяет сервису поддерживать метод доступа AJAX на основе браузера и пропустить часть backoffice в будущем для дополнительной гибкости.