RBAC на практике: Внедрение безопасной авторизации для вашего приложения

У вас возникают трудности с внедрением безопасной и масштабируемой системы авторизации для вашего приложения? Управление Доступом на Основе Ролей (RBAC) — это отраслевой стандарт для управления правами пользователей, но его правильная реализация может быть сложной задачей. В этом руководстве мы покажем вам, как построить надежную систему RBAC, используя пример реальной Системы Управления Контентом (CMS).

Следуя этому руководству, вы узнаете:

• ✨ Как разработать и внедрить детализированные права доступа, которые дают вам точный контроль
• 🔒 Лучшие практики организации прав доступа в значимые роли
• 👤 Методы эффективного управления владением ресурсами
• 🚀 Способы сделать вашу систему авторизации масштабируемой и поддерживаемой
• 💡 Практическая реализация на примере реальной CMS

Полный исходный код для этого руководства доступен на GitHub.

Понимание основ RBAC#

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

Вы можете узнать больше о Что такое RBAC в Wiki по авторизации.

Вот ключевые принципы, которым мы будем следовать в нашей реализации:

Дизайн детализированных прав доступа#

Детализированные права предоставляют вам точный контроль над тем, что пользователи могут делать в вашей системе. Вместо широких уровней доступа, таких как "админ" или "пользователь", мы определяем конкретные действия, которые пользователи могут выполнять над ресурсами. Например:

• read:articles - Просмотр любой статьи в системе
• create:articles - Создание новых статей
• update:articles - Изменение существующих статей
• publish:articles - Изменение статуса публикации статей

Владение ресурсами и контроль доступа#

Владение ресурсами — это фундаментальное понятие в дизайне авторизации нашего CMS. Пока RBAC определяет, какие действия могут выполнять разные роли, владение добавляет личностное измерение в контроль доступа:

• Авторы автоматически имеют доступ к статьям, которые они создали
• Эта естественная модель владения означает, что авторы всегда могут просматривать и редактировать своё содержание
• Система проверяет как права роли ИЛИ владение при обработке операций со статьями
• Например, даже без права update:articles, автор все ещё может редактировать свои собственные статьи
• Такой дизайн сокращает необходимость в дополнительных правах роли, сохраняя при этом безопасность

Этот двухуровневый подход (роли + владение) создаёт более интуитивную и безопасную систему. Издатели и администраторы всё еще могут управлять всем содержанием с помощью своих прав роли, в то время как авторы сохраняют контроль над своей работой.

Проектирование безопасных API#

Давайте начнём с проектирования основной функциональности нашего CMS через его конечные точки API:

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

Для каждой конечной точки нам нужно учитывать два аспекта контроля доступа:

1. Владение ресурсом - Является ли пользователь владельцем этого ресурса?
2. Права на основе ролей - Позволяет ли роль пользователя эту операцию?

Вот как мы будем управлять доступом для каждой конечной точки:

Создание системы прав доступа, которая масштабируется#

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

Обратите внимание, что эти права необходимы только при доступе к ресурсам, которые вам не принадлежат. Владельцы статей могут автоматически:

• Просматривать свои собственные статьи (без необходимости read:articles)
• Редактировать свои собственные статьи (без необходимости update:articles)
• Удалять свои собственные статьи (без необходимости delete:articles)

Создание эффективных ролей#

Теперь, когда у нас определены наши API и права, мы можем создать роли, которые логически объединяют эти права:

Примечание: Авторы автоматически имеют права на чтение/обновление/удаление своих собственных статей, независимо от прав роли.

Каждая роль разработана с учётом конкретных обязанностей:

• Админ: Имеет полный контроль над CMS, включая все операции со статьями
• Издатель: Фокусируется на обзоре контента и управлении публикацией
• Автор: Специализируется на создании контента

Эта структура ролей создаёт чёткое разделение обязанностей:

• Авторы сосредоточены на создании контента
• Издатели управляют качеством и видимостью контента
• Администраторы поддерживают общий контроль системы

Конфигурация RBAC в Logto#

Прежде чем начать, вам нужно создать аккаунт в Logto Cloud, или вы также можете использовать самостоятельно развернутую версию Logto с помощью Logto OSS версии.

Но для этого руководства мы будем использовать Logto Cloud для простоты.

Настройка вашего приложения#

1. Перейдите в "Приложения" в Logto Console, чтобы создать новое React-приложение
   • Название приложения: Система Управления Контентом
   • Тип приложения: Традиционное Веб-приложение
   • URI перенаправления: http://localhost:5173/callback

Конфигурация ресурсов API и прав#

1. Перейдите в "API Resources" в Logto Console, чтобы создать новый ресурс API
   • Название API: CMS API
   • Идентификатор API: https://api.cms.com
   • Добавьте права к ресурсу API
     • list:articles
     • read:articles
     • create:articles
     • update:articles
     • publish:articles
     • delete:articles

Создание ролей#

Перейдите в Roles в Logto Console, чтобы создать следующие роли для CMS

• Администратор
  • с полными правами
• Издатель
  • с read:articles, list:articles, publish:articles
• Автор
  • с create:articles

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

Перейдите в раздел "Управление пользователями" в Logto Console, чтобы создать пользователей.

На вкладке "Роли" в деталях пользователя вы можете назначить пользователю роли.

В нашем примере мы создаём 3 пользователей с следующими ролями:

• Алекс: Администратор
• Боб: Издатель
• Чарли: Автор

Интеграция вашего фронтенда с Logto RBAC#

Теперь, когда мы настроили RBAC в Logto, мы можем приступить к его интеграции в наш фронтенд.

Сначала следуйте Logto Quick Starts, чтобы интегрировать Logto в ваше приложение.

В нашем примере мы используем React для демонстрации.

После того как вы настроили Logto в вашем приложении, нам нужно добавить конфигурации RBAC для работы Logto.

Не забудьте выйти и войти снова, чтобы это изменение вступило в силу, если вы уже вошли в систему.

Когда пользователь входит в систему с помощью Logto и запрашивает токен доступа для указанных выше ресурсов API, Logto добавит области (права), связанные с ролью пользователя, в токен доступа.

Вы можете использовать getAccessTokenClaims из useLogto hook для получения областей из токена доступа.

И вы можете использовать userScopes, чтобы проверить, есть ли у пользователя разрешение на доступ к ресурсу.

Интеграция вашего бэкенда с Logto RBAC#

Теперь пришло время интегрировать Logto RBAC в ваш бэкенд.

Промежуточное ПО авторизации на бэкенде#

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

Как вы видите, в этом промежуточном ПО мы проверяем, содержит ли запрос фронтенда действительный токен доступа и соответствует ли аудитория токена доступа ресурсу API, который мы создали в Logto Console.

Причина проверки ресурса API заключается в том, что наш ресурс API фактически представляет собой ресурсы нашего CMS-бэкенда, и все права на наш CMS связаны с этим ресурсом API.

Поскольку этот ресурс API представляет ресурсы CMS в Logto, в нашем фронтенд-коде мы включаем соответствующий токен доступа при выполнении запросов к API на бэкенде:

Теперь мы можем использовать промежуточное ПО requireAuth для защиты наших конечных точек API.

Защита конечных точек API#

Для API, которые должны быть доступны только пользователям с определёнными правами, мы можем добавить ограничения непосредственно в промежуточное ПО. Например, API создания статьи должен быть доступен только пользователям с правом create:articles:

Для API, которые должны проверять как права, так и владение ресурсом, мы можем использовать функцию hasScopes. Например, в API списка статей пользователи с правом list:articles могут получать доступ ко всем статьям, в то время как авторы могут получать доступ только к своим статьям:

На данный момент мы завершили внедрение RBAC. Вы можете проверить полный исходный код, чтобы увидеть полную реализацию.

Тестирование реализации CMS RBAC#

Теперь давайте протестируем нашу реализацию CMS RBAC с использованием трёх только что созданных пользователей.

Сначала давайте войдём в качестве Алекса и Чарльза и создадим несколько статей.

Поскольку Алекс имеет роль Админа, он может создавать, удалять, обновлять, публиковать и просматривать все статьи.

Чарльз, имея роль Автора, может только создавать свои собственные статьи и может только просматривать, обновлять и удалять статьи, которые ему принадлежат.

Боб, с ролью Издателя, может просматривать и публиковать все статьи, но не может их создавать, обновлять или удалять.

Заключение#

Поздравляем! Вы научились внедрять надёжную систему RBAC в ваше приложение.

Для более сложных сценариев, таких как построение мультитенантных приложений, Logto предоставляет комплексную поддержку организации. Ознакомьтесь с нашим руководством Создание многотенантного SaaS-приложения: Полное руководство от дизайна до реализации, чтобы узнать больше о внедрении контроля доступа на уровне организации.

Счастливого программирования! 🚀