CIAM 102: Авторизация и управление доступом на основе ролей
Организация и арендатор отлично подходят для группировки идентификаторов, но они приводят к абсолютной демократии: каждый может делать что угодно в этой системе. Пока утопия остается загадкой, давайте посмотрим на управление доступом: Авторизация (AuthZ).
GaoFounder
Хватит тратить недели на аутентификацию пользователей
Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.
В предыдущей статье, мы ввели понятие аутентификации (AuthN) и авторизации (AuthZ), вместе с некоторыми терминами, вызывающими головную боль: идентификатор, организация, арендатор, и т.д.
Организация и арендатор отличаются тем, что хороши для группировки идентификаторов, но они приводят к абсолютной демократии: каждый может делать что угодно в этой системе. Пока утопия остается загадкой, давайте рассмотрим управление доступом: авторизация (AuthZ).
Notion - отличный пример. Для каждой страницы, которую вы владеете, вы можете выбрать, хранить ее в приватном режиме, доступной только вам, или поделиться ей с друзьями, или даже с общественностью.
Или, для онлайн-книжного магазина, вы хотите, чтобы каждый мог просматривать все книги, но клиенты могли просматривать только свои заказы, а продавцы управлять только книгами в своих магазинах.
AuthZ и AuthN являются неотъемлемыми компонентами сложной бизнес-модели. Они часто идут рука об руку; AuthZ проверяет доступ пользователя, а AuthN аутентифицирует идентификаторы. Оба необходимы для безопасной системы.
Вот одна из наиболее распространенных моделей AuthZ: Если IDENTITY выполняет ACTION над RESOURCE, тогда ACCEPT или DENY.
В примере с Notion, модель выглядит так: PERSON выполняет VIEW над PAGE.
Если страница является конфиденциальной:
Вы получите ACCEPT при выполнении VIEW над вашей PAGE.
Все остальные должны получить DENY при выполнении VIEW над вашей PAGE.
На основе консенсуса, индустрия разработала различные технологии авторизации, такие как контроль доступа на основе ролей (RBAC), контроль доступа на основе атрибутов (ABAC). Сегодня мы сосредоточимся на модели NIST RBAC Уровень 1: Flat RBAC.
В Logto ресурс (то есть API ресурс) обычно представляет собой набор сущностей или элементов, так как требуется использовать допустимый URL в качестве индикатора. Следовательно, мы определяем два ресурса:
Книги: https://api.bookstore.io/books
Заказы: https://api.bookstore.io/orders
Одно из преимуществ принуждения к формату URL состоит в том, что он может отображать на реальный адрес вашей API-услуги, что улучшает читабельность и узнаваемость при интеграции с другими компонентами системы.
Поскольку мы ввели понятие ресурса, в Logto мы также требуем, чтобы разрешения принадлежали ресурсу, наоборот, ресурсы могут иметь разрешения.
Давайте добавим некоторые разрешения в ресурсы:
Книги: read, create, delete
Заказы: read, read:self, create:self, delete
Хотя для имени разрешения нет требования, у нас есть следующее соглашение:
В то время как <action> требуется для описания разрешения, :<target> можно игнорировать для описания общей цели, т.е. ко всем сущностям или элементам ресурса. Например:
Разрешение read в ресурсе Книги означает действие по чтению произвольных книг.
Разрешение create:self в ресурсе Заказы означает действие создания заказов, принадлежащих текущему пользователю.
Точно также как присваивание роль-разрешение, присваивание пользователь-роль также является отношением «многие ко многим». Следовательно, вы можете назначить несколько ролей одному пользователю, и одну роль можно назначить нескольким пользователям.
Вот полная диаграмма отношений для модели RBAC уровня 1 в Logto:
В модели RBAC разрешения всегда "позитивны", что означает, что суд о разрешении прост: если у пользователя есть разрешение, тогда принять; в противном случае, отклонить.
Допустим, Алиса имеет роль seller, Боб и Кэрол имеют роль customer. Мы описываем действия на естественном языке в первую очередь, и после транспилируем их в стандартный формат авторизации: IDENTITY выполняет ACTION на RESOURCE, наконец даем заключение.
Алиса хочет добавить новую книгу на продажу:
Пользователь Алиса выполняет create на ресурсе Books (https://api.bookstore.io/books).
Поскольку Алисе было присвоено разрешение create на книги согласно их роли seller, результат ✅ ACCEPT.
Алиса хочет просмотреть все заказы, чтобы увидеть, соответствует ли продажа их ожиданиям:
Пользователь Алиса выполняет read на ресурсе Orders (https://api.bookstore.io/orders).
Так как Алисе было присвоено разрешение read на заказы в соответствии с их ролью seller, результат ✅ ACCEPT.
Боб хочет просмотреть список книг, чтобы увидеть, есть ли какие-нибудь книги, которые они хотят приобрести.
Пользователь Боб выполняет read на ресурсе Books (https://api.bookstore.io/books).
Так как Бобу было присвоено разрешение read на книги в соответствии с их ролью cusomter, результат ✅ ACCEPT.
Боб хочет просмотреть заказ Кэрол.
Так как это чужой заказ, разрешение read:self на Orders здесь не работает.
Пользователь Боб выполняет read на ресурсе Orders (https://api.bookstore.io/order).
Так как у Боба нет разрешения read на заказы, результат ❌ DENY.
Смотрите документ для подробностей, если вам интересно.
Logto сейчас имеет реализацию уровня 1 и будет двигаться к более высоким уровням на основе отзывов сообщества. Не стесняйтесь сообщить нам, если более высокий уровень подходит к вашим потребностям!
Помимо теории, у нас еще есть тяжелые технические работы, чтобы завершить, чтобы модель работала как ожидается:
Разработка клиента и сервера auth
Проектирование базы данных для RBAC
Проверка на разных сервисах
Безопасность и соответствие открытым стандартам
Управление ролями, разрешениями, ресурсами и назначением
Не паникуйте. Мы учли это и добавили поддержку из коробки, чтобы охватить все вышеуказанное. Проверьте 🔐 RBAC рецепт, чтобы узнать, как использовать RBAC в Logto.