Овладение RBAC в Logto: Всесторонний реальный пример

Введение#

Контроль доступа и безопасность - важные аспекты современных приложений, обеспечивающих соответствующий доступ пользователей к ресурсам. Управление доступом на основе ролей (RBAC) Logto предлагает разработчикам эффективный способ управления контролем доступа и безопасностью в их приложениях. В этой статье мы рассмотрим мощные функции реализации RBAC в Logto, используя реальный пример, который поможет вам понять и применять эти концепции в своих проектах.

Изучив оба фрагмента кода фронтенда и бэкенда, вы получите всестороннее представление об интеграции RBAC Logto в стек вашего приложения. К концу этой статьи вы будете хорошо подготовлены к использованию функций RBAC Logto для улучшения безопасности и контроля доступа в вашем проекте.

Представляем BookHarber: Использование интернет-магазина книг#

Чтобы эффективно продемонстрировать функции RBAC Logto, мы будем использовать реальный пример: BookHarber, интернет-магазин книг. BookHarber предлагает широкий ассортимент функций для клиентов и сотрудников, обеспечивая беспрепятственные и безопасные покупки.

Ключевые функции BookHarber включают:

1. Просмотр и покупка книг: Пользователи могут легко искать и покупать книги из разнообразной коллекции, охватывающей различные жанры и авторов.
2. Управление заказами и отслеживание логистики: Зарегистрированные клиенты могут управлять своими заказами, отслеживать доставку и получать обновления о своих покупках.
3. Особые предложения и праздничные мероприятия: BookHarber предоставляет эксклюзивные скидки и акции во время особых событий и праздников, чтобы привлечь и вознаградить свою клиентскую базу.
4. Поддержка клиентов: Клиенты могут открывать билеты поддержки для решения любых вопросов или проблем, с которыми они могут столкнуться, получая оперативную помощь от сотрудников BookHarber.
5. Управление клиентами: Сотрудники с разными ролями имеют возможность управлять различными аспектами платформы, такими как учетные записи клиентов, обработка заказов и решение проблем.

Роли#

В экосистеме BookHarber мы можем выделить несколько ключевых ролей пользователей, таких как:

1. Гость: Незарегистрированные пользователи, которые могут просматривать веб-сайт, искать книги и просматривать специальные предложения.
2. Клиент: Зарегистрированные пользователи, которые могут покупать книги, управлять заказами, отслеживать логистику и открывать тикеты поддержки.
3. Администратор магазина: Сотрудники, ответственные за общий контроль и операции платформы. С полным доступом.
4. Менеджер книг: Сотрудники, ответственные за управление книгами и категориями.
5. Агент службы поддержки клиентов: Сотрудники, ответственные за ответы на тикеты поддержки.
6. Поставщик внешней логистики: Внешние партнеры, ответственные за управление и отслеживание доставки и доставки заказов.
7. Сотрудник маркетинга: Сотрудники, ответственные за продвижение BookHarber, ответственные за управление специальными предложениями и событиями.

Проектирование областей для REST API BookHarber#

Чтобы эффективно реализовать систему RBAC Logto для BookHarber, нам нужно разработать области, соответствующие различным REST API. Области являются разрешениями, которые определяют уровень доступа конкретной роли для каждой конечной точки API. Назначив соответствующие области для каждой роли пользователя, мы можем гарантировать, что пользователи имеют доступ только к действиям и ресурсам, соответствующим их роли.

Давайте разработаем области для следующих REST API:

1. API категорий:
   • create:categories: POST /categories
   • write:categories: PUT /categories/:id
   • delete:categories: DELETE /categories/:id
   • list:categories: GET /categories
2. API книг:
   • create:books: POST /books
   • write:books: PUT /books/:id
   • delete:books: DELETE /books/:id
   • list:books: GET /books
   • read:books: GET /books/:id
3. API клиентов:
   • list:customers: GET /customers
   • write:customers: PUT /customers/:id
   • delete:customers: DELETE /customers/:id
   • read:customers: GET /customers/:id
4. API заказов:
   • create:orders: POST /orders
   • list:orders: GET /orders
   • read:orders: GET /orders/:id
   • write:orders: PUT /orders/:id
5. API событий:
   • create:events: POST /events
   • write:events: PUT /events/:id
   • list:events: GET /events
   • delete:events: DELETE /events/:id
6. API отслеживания заказов:
   • read:orderTracks: GET /orders/:id/tracks
   • create:orderTracks: POST /orders/:id/tracks
   • write:orderTracks: PUT /orders/:id/tracks/:trackId
7. API билетов:
   • create:tickets: POST /tickets
   • list:tickets: GET /tickets
   • read:tickets: GET /tickets/:id
   • write:tickets: PUT /tickets/:id

Назначение областей ролям#

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

Понимание различий между областями "list" и "read"#

Чтобы детальнее проиллюстрировать различия между "list" и "read" областями в контексте дизайна REST API и RBAC, давайте рассмотрим реальный пример, связанный с интернет-магазином книг, BookHarber.

Предположим, что у BookHarber два типа пользователей: клиенты и агенты службы поддержки клиентов. Клиенты могут создавать заказы, в то время как агенты службы поддержки клиентов отвечают за помощь клиентам с их заказами. Давайте посмотрим, как применяются области "list" и "read" к ресурсу API orders в этом сценарии.

1. List Scopes: Область "list" позволяет пользователю получать доступ к коллекции сущностей на системе. Например, область list:orders позволяет пользователю получать список всех доступных заказов. В контексте BookHarber эта область может быть полезна для администраторов магазина или других сотрудников, которым нужно иметь обзор всех заказов в системе. Однако, агенты службы поддержки клиентов не должны иметь доступ ко всему списку заказов, поскольку их роль заключается в оказании помощи отдельным клиентам для их конкретных заказов.
2. Read Scopes: Область "read" предоставляет пользователю разрешение на доступ к одному сущности с заданным ID. Например, область read:orders позволяет пользователю просматривать детальную информацию о конкретном заказе по его ID. В случае BookHarber эта область идеально подходит для агентов службы поддержки клиентов, которым нужно получить доступ к информации об определенном заказе клиента. Когда клиент открывает тикет поддержки, агент службы поддержки клиентов может использовать ID заказа, указанный в тикет, чтобы получить доступ и просмотреть информацию о конкретном заказе.

Понимание владения: Почему клиентам не нужны области "read" или "list" для своих заказов#

Во многих приложениях обычно пользователи имеют доступ к своим собственным ресурсам без явного предоставления соответствующих областей "read" или "list". Это связано с тем, что пользователи считаются владельцами этих ресурсов и естественно должны иметь к ним доступ. В случае нашего примера с BookHarber, клиенты могут создавать заказы, но не обладают областями "read:orders" или "list:orders".

Концепция владения играет важную роль в определении контроля доступа к определенным ресурсам в REST API. Признавая, что пользователи всегда могут получить доступ к своим собственным ресурсам, мы можем реализовать более эффективный и безопасный контроль доступа без предоставления ненужных разрешений. В случае с BookHarber это означает, что клиенты все равно могут просматривать и управлять своими заказами без необходимости каких-либо дополнительных областей.

Чтобы показать, как это работает, рассмотрим конечную точку GET /orders:

1. Если у пользователя есть область list:orders (например, администраторы магазина или сотрудники), они смогут просматривать все заказы в системе. Это дает им комплексный просмотр данных о заказах, необходимых для их роли.
2. Если у пользователя нет области list:orders (например, обычные клиенты), система вернет только заказы, принадлежащие пользователю. Это гарантирует, что клиенты все равно могут получать доступ к информации о своем заказе, не получив доступ к ненужным разрешениям.

Реализуя этот контроль доступа на основе владения, API может предоставить соответствующий уровень доступа различным ролям пользователей, сохраняя безопасность и индивидуальный пользовательский опыт. В сценарии BookHarber модель владения позволяет клиентам получать доступ к информации о своем заказе без необходимости "read:orders" или "list:orders" областей, упрощая дизайн контроля доступа и улучшая общий пользовательский опыт.

Настройка настроек в консоли Logto#

Чтобы завершить настройку в консоли Logto, выполните следующие шаги:

1. Создайте одностраничное приложение (SPA) для React: Настройте SPA в консоли Logto для вашего приложения React.
2. Создать ресурс API: Добавьте новый ресурс API с идентификатором https://api.bookharber.com.
3. Определите области для ресурса: Создайте необходимые области в рамках вновь созданного ресурса API.
4. Создайте роли и назначьте области: Определите роли пользователей для вашего приложения и назначьте соответствующие области каждой роли.
5. Назначьте роли пользователям: Назначьте соответствующие роли пользователям в вашем приложении, убедившись, что каждый пользователь (особенно сотрудник) имеет правильные разрешения на основе своей роли.

Защита API с использованием областей#

В нашем примере проекта, BookHarber, мы используем Express для бэкенд-сервиса и React для веб-страницы фронтенда. Этот раздел даст краткий обзор того, как мы можем интегрировать функции RBAC Logto с этими популярными технологиями, чтобы обеспечить безопасность нашего приложения.

Полная документация: https://docs.logto.io/docs/recipes/rbac/protect-resource

Фронтенд#

Чтобы инициализировать Logto в вашем приложении React, следуйте предоставленной здесь документации: https://docs.logto.io/docs/recipes/integrate-logto/react/

В дополнение к базовой настройке, вам необходимо указать "ресурс" и "области" в конфигурации:

Вот пример того, как сделать запрос API с помощью Logto:

Бэкенд#

Чтобы защитить API, следуйте: https://docs.logto.io/docs/recipes/protect-your-api/

В дополнение к примеру кода (https://docs.logto.io/docs/recipes/protect-your-api/node), нам нужно добавить проверку областей:

Заключение#

Система RBAC Logto - мощный инструмент для управления контролем доступа и безопасностью в современных приложениях. Используя функции RBAC Logto, вы можете гарантировать, что пользователи имеют надлежащий доступ к ресурсам на основе своих ролей, защищая чувствительные данные и функциональность от несанкционированного доступа.

В этой статье мы рассмотрели реальный пример интернет-магазина книг, BookHarber, и продемонстрировали, как проектировать области, назначать их пользовательским ролям и реализовывать функции RBAC Logto как в фронтенде, так и в бэкенде приложения.

Применяя эти концепции и техники к своим проектам, вы можете улучшить безопасность и контроль доступа ваших приложений, обеспечивая безупречный и безопасный пользовательский опыт. Будь то платформа электронной коммерции, система управления контентом или любой другой проект, требующий контроля доступа на основе ролей, система RBAC Logto предлагает гибкое и эффективное решение для удовлетворения ваших потребностей в контроле доступа.