CIAM 102: Авторизация и управление доступом на основе ролей

Предыстория#

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

Определение ролей#

Вкратце, роль - это группа разрешений. Давайте создадим две роли customer и seller и назначим им разрешения следующим образом:

Вы можете заметить, что присваивание разрешение-роль представляет собой отношения «многие ко многим».

Назначение ролей пользователям#

Точно также как присваивание роль-разрешение, присваивание пользователь-роль также является отношением «многие ко многим». Следовательно, вы можете назначить несколько ролей одному пользователю, и одну роль можно назначить нескольким пользователям.

Соединение точек#

Вот полная диаграмма отношений для модели 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.

Другие уровни RBAC#

В модели NIST RBAC есть четыре уровня:

• Flat RBAC
• Иерархический RBAC
• Ограниченый RBAC
• Симметричный RBAC

Смотрите документ для подробностей, если вам интересно.

Logto сейчас имеет реализацию уровня 1 и будет двигаться к более высоким уровням на основе отзывов сообщества. Не стесняйтесь сообщить нам, если более высокий уровень подходит к вашим потребностям!

На практике#

Помимо теории, у нас еще есть тяжелые технические работы, чтобы завершить, чтобы модель работала как ожидается:

• Разработка клиента и сервера auth
• Проектирование базы данных для RBAC
• Проверка на разных сервисах
• Безопасность и соответствие открытым стандартам
• Управление ролями, разрешениями, ресурсами и назначением

Не паникуйте. Мы учли это и добавили поддержку из коробки, чтобы охватить все вышеуказанное. Проверьте 🔐 RBAC рецепт, чтобы узнать, как использовать RBAC в Logto.

Заключительные заметки#

RBAC - мощная модель управления доступом для большинства случаев, но нет совершенного решения. У нас все еще есть некоторые вопросы:

• Мне нужны высокие уровни RBAC?
• Как RBAC сравнивается с другими моделями авторизации?
• Как определить модель авторизации между разными организациями?