Несколько дней назад некоторые из моих коллег обратились ко мне по поводу проблемы с под названием , которое представляет собой платформу для обмена заметками, разработанную для нашего университета и призванную помочь студентам эффективно обмениваться главными заметками, вопросами прошлых экзаменов и обучающими материалами . приложением с открытым исходным кодом Makaut Buddy на YouTube. Хотя они успешно разработали систему загрузки ресурсов, они столкнулись с проблемой обеспечения того, чтобы только авторизованные лица могли загружать контент. Как показано в демо ниже, любой пользователь может создать ресурс после регистрации. Это представляло собой большую проблему, поскольку мы не могли регулировать то, что пользователи загружают, а некоторые даже могли загружать вредоносный или тревожный контент. https://youtu.be/NVyf_wb-WPE?embedable=true Первоначально они определили роль администратора и предоставили избранной группе лиц административные привилегии. Однако по мере увеличения количества ролей код становился все более сложным и трудным в управлении. Именно тогда у меня возникла идея написать эту статью, чтобы повысить осведомленность об эффективных способах управления авторизацией с использованием модели управления доступом на основе ролей (RBAC) с помощью сторонних инструментов авторизации, таких как Permit. Помимо внедрения RBAC, мы также внедрили систему подтверждения запроса на доступ. Эта система гарантирует, что любой пользователь, желающий загрузить контент, должен сначала запросить доступ, который администратор затем может одобрить или отклонить. Этот дополнительный уровень безопасности помогает нам поддерживать целостность контента на Makaut Buddy. В этой статье я использовал в качестве языка программирования и в качестве платформы. Однако обсуждаемые здесь концепции не зависят от языка, и вы можете реализовать их на предпочитаемом вами языке программирования. JavaScript Next.js К концу этой статьи вы научитесь реализовывать базовую модель RBAC в своем приложении. С учетом вышесказанного, давайте погрузимся! Что такое авторизация? Помните те утренние спешки в школу? Охранник, проверяющий ваше удостоверение личности, является прекрасным примером аутентификации. Они проверяют вашу личность как студента, допущенного в кампус. Но это только первый шаг. Даже после того, как вас опознали, вы ведь не пойдете просто так в любой класс, верно? Вот тут-то и пригодится авторизация. Воспринимайте расписание занятий как свое разрешение. Он предоставляет вам доступ к определенным областям (классам) в зависимости от вашей роли (учащегося, зачисленного в этот класс). Вам не будет разрешено войти в учительскую или в закрытую секцию библиотеки, даже если вы студент (аутентифицированный). Разница между аутентификацией и авторизацией подобна вопросу «Кто вы?» против «Что вам разрешено делать?» Зачем нам нужна модель RBAC для авторизации 🤔? Авторизация важна в каждой организации, поскольку она не позволяет отдельным лицам выполнять действия, на которые у них нет разрешения. Это обеспечивает безопасность организации и помогает предотвратить потери. Проиллюстрируем вышеизложенное утверждение примером: В компании есть старшие инженеры с большим опытом, а также несколько стажеров, которые все еще учатся. Вы можете себе представить, какую катастрофу это могло бы вызвать, если бы и старший инженер, и стажер имели одинаковый уровень разрешений. Стажеры, которые еще учатся, могут по незнанию допустить ошибку, за которую компании придется расплачиваться. В подобных ситуациях модель управления доступом на основе ролей работает лучше всего, поскольку разрешения не назначаются отдельным лицам, а назначаются ролям. Например, только старший инженер или технический руководитель может удалять ресурсы, тогда как все стажеры могут только просматривать ресурсы и управлять ими. Далее давайте посмотрим, как можно реализовать RBAC в приложении. Как реализовать RBAC в приложении: 1. Определите роли и разрешения Во-первых, нам нужно определить роли и назначить разрешения для каждой роли. Примечание. Роль — это должность или цель, которую кто-то имеет в организации. Нам нужны роли, чтобы мы могли различать людей на основе разрешений или привилегий, назначенных этой роли. 2. Назначьте роли пользователям Нам нужен способ назначить роль каждому пользователю приложения. Обычно это делается после регистрации пользователя. 3. Создайте API авторизации Нам нужен API в нашем бэкэнде, который принимает операцию, которую пользователь хочет выполнить, и проверяет авторизацию пользователя. Схема ниже поможет вам лучше понять: Однако мы не собираемся реализовывать всю модель с нуля. Вместо этого мы собираемся использовать сторонний инструмент авторизации под названием Permit, который сделает для нас весь процесс авторизации очень простым и эффективным, так что вы сможете работать над действительно важными функциями. На диаграмме ниже показано, как мы собираемся использовать Permit для реализации RBAC в наших приложениях: Реализация модели RBAC В этом разделе мы рассмотрим шаги по реализации управления доступом на основе ролей (RBAC) с использованием разрешений. Шаг 1. Создайте разрешительную учетную запись и рабочее пространство. Поскольку мы используем разрешение для создания модели RBAC, сначала нам нужно создать учетную запись разрешения и рабочую область: Шаг 2. Создайте ресурс Теперь нам нужно создать ресурс, который является объектом, доступ к которому мы хотим контролировать в нашем приложении. Например, в приложении для создания заметок ресурсом будут «Заметки», а действиями — , и «Создать» «Чтение», «Обновить» «Удалить». Чтобы создать ресурс: Перейдите в раздел Политика. Перейдите на вкладку Ресурсы. Создайте новый ресурс, заполнив необходимые данные. В приведенном выше примере имя ресурса — «Заметки», а действия, которые пользователю разрешено выполнять — «Создать», «Чтение», «Обновить» и «Удалить». Шаг 3: Определите роли После создания ресурса нам необходимо определить роли, которые будут существовать в нашем приложении. В данном случае, поскольку приложение представляет собой приложение для обмена заметками для университета, роли будут следующими: Администратор: может создавать и читать ресурсы. Студент: умеет читать ресурсы. Шаг 4. Назначьте действия ролям После того, как мы создали обе роли, нам нужно назначить действия, которые каждая роль может выполнять в нашем редакторе политик, как показано ниже: Шаг 5. Настройка серверных API Теперь, когда ваша учетная запись Permit настроена, вы можете приступить к созданию серверных API для взаимодействия с Permit. Мы будем использовать Node.js SDK, предоставленный Permit. Вы можете найти SDK для предпочитаемого вами языка программирования в разрешительной документации. Синхронизировать пользователей и назначить роль по умолчанию Во-первых, нам нужно убедиться, что каждый пользователь, регистрирующийся в нашем приложении, синхронизирован с каталогом разрешений и ему назначена роль Студента по умолчанию. Для этого нам нужно создать серверный API, как показано ниже: Этот API делает 2 вещи: Инициализирует API разрешений. Создает нового пользователя с помощью API . createUser Назначает роль по умолчанию с помощью API . assignRole Подробнее обо всех API, предоставляемых Permit, можно прочитать в документации разрешений. Получить роль пользователя Далее нам нужно создать бэкэнд API, который получает роль пользователя из и отправляет ее обратно во фронтенд. Permit.io API, показанный ниже, получает пользователя с помощью permit.api.users.get(user_key) Этот API получает роль пользователя, с помощью которой мы можем манипулировать нашими интерфейсными компонентами, чтобы его могли видеть только люди, имеющие специальные роли. Вы также можете проверить функцию чтобы проверить, разрешено ли пользователю с определенной ролью выполнять операцию. Permit.check(), Благодаря этому мы успешно реализовали модель RBAC с использованием Permit. Теперь мы можем интегрировать внутренние маршруты с внешней платформой или библиотекой по вашему выбору для завершения настройки. Внедрение системы разрешения доступа: Чтобы завершить настройку, нам нужен компонент, который позволит пользователям запрашивать обновления ролей: Обычный пользователь без прав администратора может просмотреть элемент разрешения и запросить права администратора. Пользователь-администратор может утверждать или отклонять входящие запросы на повышение роли от других пользователей. Шаг 1. Создайте элемент разрешения Элементы разрешений являются частью «Permit Share-If», который представляет собой набор готовых встраиваемых компонентов пользовательского интерфейса, которые упрощают совместное использование доступа в приложениях. Разработанные для обеспечения полнофункционального контроля доступа, они делают делегирование управления разрешениями вашим пользователям простым и безопасным. Чтобы реализовать это, сначала нам нужно создать элемент разрешения: Перейдите на вкладку «Элементы» на панели разрешений. Нажмите «Создать элемент» в разделе «Управление пользователями». Затем нам нужно заполнить форму необходимой информацией, как показано ниже. Сделайте роль администратора владельцем рабочей области. Назначьте роль Студента разделу просмотра. Установите роль по умолчанию как Студент. Сохраните элемент и создайте новый элемент в разделе «Запрос доступа».: Затем заполните информацию для запроса доступа. Выберите элемент управления пользователями, чтобы подключить элемент запроса доступа. Нажмите «Создать», чтобы завершить создание элемента. Далее мы отредактируем элемент управления пользователями. Вернитесь к элементу управления пользователями и отредактируйте его. Выберите элемент запроса доступа в качестве компонента утверждения в управлении пользователями. Вот и все, мы создали элементы. Шаг 2. Создайте серверный API для входа пользователя Прежде чем использовать элементы, нам необходимо создать серверный API для входа пользователя в элемент разрешения, Примечание. Важно войти в систему как можно раньше, желательно сразу после регистрации. Теперь давайте посмотрим на код: Код API, обслуживающий конечную точку : /api/v1/login_permit/?userkey=user_key Шаг 3. Код внешнего интерфейса для реализации входа в систему Код внешнего интерфейса для реализации входа в систему будет выглядеть следующим образом: Вот и все, мы настроили наш код. Шаг 4. Интегрируйте Iframe во внешний интерфейс Теперь нам просто нужно перейти на панель разрешений и скопировать iframe управления пользователями и iframe запроса доступа, как показано ниже: Теперь, когда у нас есть код, нам нужно добавить в наш интерфейс, где мы хотим показывать элементы нашим пользователям, нам нужно: iframe Покажите элемент управления пользователями пользователям с ролью администратора. Покажите элемент запроса доступа пользователям с ролью студента. Благодаря этому мы успешно настроили систему утверждения доступа, в которой пользователи могут запрашивать повышение ролей, а администраторы могут утверждать или отклонять эти запросы. Демонстрация RBAC в приложении для обмена заметками Демо: Доступ администратора для загрузки виджета В этой демонстрации показано, как пользователь с ролью «Администратор» может получить доступ к виджету загрузки. https://youtu.be/xWQDI5N2TdM?embedable=true Демонстрация: ограничения ролей учащихся и запрос доступа В этой демонстрации показано, как пользователь с ролью «Студент» не может видеть виджет загрузки и может запросить обновление до роли «Администратор»: https://youtu.be/Es69s8qiEog?embedable=true Демонстрация: утверждение обновления роли В этой демонстрации показано, как привилегированные пользователи могут утверждать запросы на обновление роли: https://youtu.be/sz8TaNk9OZE?embedable=true Демо: обновленный ролевой доступ для загрузки виджета В этой демонстрации показано, как пользователь после повышения уровня «Студент» до «Администратор» получает доступ к виджету загрузки. https://youtu.be/l5YaWi88n0o?embedable=true Заключение Вот и все! Спасибо, что дочитали до этого места. В этом уроке мы рассмотрели авторизацию и поняли, почему авторизация очень важна в любом приложении. Мы также рассмотрели, как мы можем установить и настроить Permit для защиты приложения и контроля доступа пользователей в зависимости от их ролей. Эта статья — лишь верхушка айсберга авторизации и модели RBAC. Вы можете изучить ABAC и ReBAC для более детальной авторизации.
