OAuth2 и контроль доступа на основе ролей

Question

У меня есть приложение Rails, выступающее в качестве поставщика OAuth 2.0 (с использованием гема oauth2-provider ). Он хранит всю информацию, связанную с пользователями (учетные записи, личную информацию и роли). Есть 2 клиентских приложения, которые аутентифицируются через это приложение. Клиентские приложения могут использовать тип предоставления client_credentials для поиска пользователей по электронной почте и выполнения других операций, для которых не требуется код авторизации. Пользователи также могут входить в клиентские приложения, используя тип предоставления пароля.

Теперь проблема, с которой мы сталкиваемся, заключается в том, что роли пользователей определяются глобально на хосте ресурса. Таким образом, если пользователю назначена роль admin на хосте ресурса, этот пользователь будет admin на обоих клиентах. Мой вопрос: что мы должны сделать, чтобы иметь более детальный контроль доступа? То есть пользователь может быть editor для app1, но не для app2.

Полагаю, простой способ сделать это - изменить имена ролей следующим образом: app1-admin, app2-admin, app1-editor, app2-editor и т. Д. Более важный вопрос: реализуем ли мы всю эту систему? правильно; то есть мы должны хранить так много информации на хосте ресурса, или мы должны денормализовать данные в клиентских приложениях?

Денормализованная архитектура будет выглядеть так: все пользовательские данные на хосте ресурса, локализованные пользовательские данные на каждом клиентском хосте. Так что user@example.com будет хранить свою личную информацию на хосте ресурса, а его роль editor будет храниться на клиенте app1. Если он никогда не воспользуется им, app2 мог бы полностью забыть о его существовании.

Недостаток денормализованной модели заключается в большом дублировании данных (идентификаторов учетных записей, ролей) и кода (модели User и Role на каждом клиенте, отдельные интерфейсы управления и т. Д.).

Есть ли какие-либо недостатки в хранении данных отдельно? Оба клиентских приложения пользуются большим доверием - мы сделали их оба - но мы, вероятно, добавим дополнительные клиентские приложения, которые не находятся под нашим контролем, в будущем.

Answer 1

Самый правильный способ использовать oAuth и другие подобные внешние методы авторизации, как я вижу, для строгой аутентификации.Вся логика бизнеса / авторизации должна всегда обрабатываться на вашей серверной части, и вы всегда должны вести центральный учет пользователя, ссылаясь на внешнюю информацию по внешнему типу службы аутентификации.

Наличие многоуровневого/ multipart доступ, также необходим, если вы хотите, чтобы ваши настройки были масштабируемыми и ориентированными на будущее.Это стандартный дизайн, который отделен от любой логики авторизации и всегда имеет прямое отношение к бизнес-правилам.

Stackoverflow делает что-то вроде этого, запрашивая создание реальной учетной записи на сайте после Вы входите в систему с помощью внешнего метода.

Обновление: Если сайты действительно похожи, вы можете поднастроить этот дизайн для объекта для приложения, который поддерживает правила доступа для конкретного приложения.Этот объект также должен наследоваться от глобального объекта, который имеет глобальные правила (таким образом, вы можете, например, наложить запрет на приложение или предприятие).

Я бы пошел на объекты, которые содержат настройки доступа и роли, которые могут быть связаны с экземплярами настроек уровня приложения и глобальными настройками только для автоматизации / сжатия назначения доступа.

На самом деле выМожно использовать этот дизайн, даже если они не слишком похожи.Это поможет вам избежать лишних настроек и бессмысленных (деловых) ролей.Вы можете определить роль только по названию / назначению должности, а затем наложить свои ограничения, связавшись с соответствующей настройкой параметров доступа.