Важной частью безопасности аутентификации любой платформы (PaaS) является возможность ограничить и/или определить конкретное приложение или пользовательские "права" или разрешения на основе пользователя или приложения или на аутентификацию.
Общая модель разрешения, найденная в современных API-интерфейсах платформы или продукта, основана на идее "Области" . В моих исследованиях GitHub, Facebook, Instagram, Etsy (и более) все используйте этот стиль моделирования разрешений в своих реализациях OAuth. Однако эта модель "видимости", по-видимому, касается только того, как внешние (т.е. Сторонние) приложения получают доступ к данным, прошедшим проверку подлинности.
Внутренне модели разрешений, похоже, либо более сфокусированы на модели, основанной на роли (администратор, модератор, пользователь и т.д.), либо ряд других пользовательских реализаций.
Мой вопрос таков: "Какая модель разрешения лучше всего подходит для современного PaaS, который хотел бы как ограничить своих пользователей от определенных действий, так и ограничить сторонние приложения от доступа к данным пользователей и как это можно было бы сконфигурировать в осознанный способ?"
Мои первоначальные исследования привели меня к внутреннему и внешнему использованию модели разрешений на основе области. К сожалению, архитектура такой системы не является тривиальной. Я видел несколько методов создания такой архитектуры:
AR-friendly реляционный способ DB:
Создание нескольких таблиц с таблицами соединений для отношения "многие ко многим" между списком разрешений, доступными разрешениями пользователей, токеном пользователя и активными разрешениями токенов пользователя.
Пользователь может пройти аутентификацию с помощью токена и указать столько разрешений, которые будут доступны на этом токене до, разрешения, установленные для этого пользователя
Умный способ маскировки бит:
Использование простого целочисленного столбца в наборе данных для хранения целочисленного значения
Целочисленное значение обращается двояким образом, используя побитовые операторы для установки, получения, переключения (и т.д.) разрешений пользователя или их токена, представляя разрешение как один бит
Кажется, что они кажутся плюсами и минусами каждого. Дружественный AR-интерфейс выглядит как его очень гибкое решение, но также кажется, что это может быть серьезный удар по производительности, поскольку нужно будет запускать несколько подключений/запросов, и экземпляры модели ORM должны быть созданы на каждой проверке подлинности вызов. Метод Бит-маскирования кажется, что он будет очень быстрым и эффективным, но будет менее интуитивно понятным для разработки и будет более подвержен ошибкам. Кроме того, бит-маскирование, похоже, было бы предельным решением в том смысле, что оно легко разрешило бы очень "двоичную" модель разрешения (может или не может) без промежуточной среды/счастливой среды и что это ограничит разрешения для жесткий 64-разрядный предел, основанный на аппаратных ограничениях.
Есть ли другой способ моделирования или архивирования разрешений, который Im не видит/не думает? Или я нахожусь на правильном пути, и рассмотрение производительности не так сильно беспокоит (насколько реляционный метод идет), как Im делает это?
Большое вам спасибо!
Какая модель разрешения лучше всего подходит для современного PaaS, который хотел бы как ограничить своих пользователей от определенных действий, так и ограничить сторонние приложения от доступа к данным пользователей и как это можно было бы сконструировать сознательным образом?
Я бы начал с обзора Spring ACL безопасности. Они используют бит-маски и могут (относительно) легко интегрироваться с кешем, например, ehcache. Если вы используете JPA для доступа к данным, вы также можете использовать кэш JPA.
http://static.springsource.org/spring-security/site/docs/current/reference/springsecurity.html
Схема:
http://static.springsource.org/spring-security/site/docs/3.0.x/reference/appendix-schema.html
OAuth: