Единая точка входа сразу для нескольких цифровых сервисов одной компании. Удобно, не правда ли? Не нужно запоминать логин и пароль от каждого отдельного цифрового решения, постоянно где-то фиксировать эту информацию. Достаточно зарегистрироваться один раз и все, вы имеете доступ ко всем платформам компании.
Тогда возникает вопрос, а что делать с безопасностью данных, как их защитить и выполнить соблюдение законодательства. Ответ оказался простым, ну или не очень, решать только вам.
В этой статье мы расскажем про самописную ролевую модель, которую можно внедрить в цифровые сервисы. Она позволит компании настроить права доступа для пользователей и обеспечить сохранность своих данных и своих пользователей.
Начнем с азов
Что такое вообще роль - набор полномочий, который необходим пользователю или группе пользователей для выполнения определенных рабочих задач. Например, один
сотрудник имеет одну роль, которая включает в себя разные доступы. Отметим, что в зависимости от принадлежности пользователя к организации, доступы можно отредактировать при необходимости. Если общий набор доступов к определенной роли не закрывает потребности для выполнения задач.
Главный тут момент, что полномочия расширяются с каждой новой ролью присвоенной сотруднику.
Так где собака зарыта или на что следует обратить внимание при создании ролевой модели:
Определение ролей и ответственностей: Необходимо четко определить роли и ответственности каждого участника в системе. Каждая роль должна иметь ясное описание своих обязанностей, полномочий и взаимодействия с другими ролями. Отметим, что хорошо справляются матрицы доступа.
Гибкость и масштабируемость: Ролевая модель это не статичная сущность, она должна быть гибкой и масштабируемой, чтобы можно было адаптировать ее к изменяющимся потребностям и условиям. Бизнес процессы в компании с течением времени изменяются по разным причинам, внешние/внутренние - не важно, ролевая модель должна иметь возможность изменения/добавления и удаления текущих ролей.
Управление конфликтами и решение спорных вопросов. В идеале, ролевая модель должна быть непротиворечивой и опираться на матрицу конфликтов, где указан запрет возможных сочетаний ролей. В противном случае нужна система логирования, ввод приоритетности и прочее.
От слов к делу
Перейдем к рассмотрению практического примера:
Для обеспечения гибкого и прозрачного управления доступом, все роли и соответствующие им права были централизованы в едином сервисе авторизации. Этот сервис стал центром управления, где осуществляется добавление, редактирование и удаление ролей, а также назначение ролей пользователям.
Соответственно, все роли, а точнее матрица ролей по каждому из сервисов вынесена в один централизованный сервис авторизации. Именно там добавляются новые роли, редактируются старые, удаляются. Также именно там происходит привязка пользователей и ролей.
Эволюция архитектуры авторизации:
1. Первоначальная реализация:
-
Каждый сервис хранил в своей локальной базе данных информацию о доступных действиях для каждой роли.
-
При попытке пользователя выполнить какое-либо действие(собрать отчет, открыть раздел и т.п.), происходила проверка соответствия роли в сессии и прав доступа, хранящихся в локальной базе данных.
Принцип работы:
• Единая авторизация: Пользователь авторизуется в едином сервисе авторизации, обеспечивая сквозной доступ ко всем подключенным сервисам.
• Переход между сервисами: После успешной авторизации пользователь может переходить между сервисами через меню или по прямой ссылке.
Настройка ролевой модели:
• Централизованное управление: Настройка ролевой модели (доступ к сервисам для каждой роли) осуществляется в единой административной панели.
• Гибкость: Система поддерживает любое количество ролей в зависимости от потребностей бизнеса с возможностью индивидуальной настройки прав доступа для каждой роли в каждом сервисе.
• Различные уровни доступа: Авторизованным пользователям на различных сервисах могут быть предоставлены доступы в зависимости от того, откуда он пришел, и какие у него роли.
Процесс авторизации:
1. Авторизация на сервисе: Пользователь проходит двухфакторную аутентификацию.
2. Получение ролей: Сервис отправляет HTTPS-запрос к API сервиса авторизации для получения набора доступов согласно его текущей роли.
3. Хранение доступов: Полученный набор доступов согласно роли сохраняется в сессии пользователя.
4. Проверка прав доступа: На стороне приложения (конечного сервиса) для каждого функционального блока используется механизм Gate для проверки наличия соответствующего доступа в сессии пользователя.
• Доступ разрешен: Если доступ присутствует в сессии, пользователю предоставляется доступ к блоку.
• Доступ запрещен: Если доступ отсутствует в сессии, пользователю доступ к блоку не предоставляется.
Изменение прав доступа:
• Сброс сессии: При изменении прав доступа пользователя или организации, к которой он относится, происходит принудительная разавторизация пользователя во всех сервисах.
• Повторная авторизация: Пользователю необходимо пройти повторную авторизацию для получения актуального набора доступов согласно роли пользователя.
• Индивидуальные настройки для организаций: Система позволяет настраивать индивидуальные права доступа для ролей в рамках каждой организации. Это позволяет предоставлять различным организациям разные уровни доступа к одному и тому же сервису для одинаковых ролей.
Отметим, что HTTPS-запрос к сервису авторизации выполняется только один раз – при авторизации пользователя в сервисе. Далее информация о ролях и правах доступа хранится в сессии пользователя.
Предложенная архитектура обеспечивает эффективное и гибкое управление доступом в микросервисной среде, позволяя централизованно настраивать ролевую модель, учитывать индивидуальные потребности организаций и упростить разработку приложений.
2. Подведем итоги, как выглядит текущая реализация: централизованное управление.
-
Вместо хранения информации о разрешениях в базах данных, каждый сервис самостоятельно определяет Gate (механизм контроля доступа к действиям). Сервис анализирует набор прав, полученных пользователем при авторизации, и предоставляет доступ к функционалу только в том случае, если у пользователя имеются соответствующие разрешения.
-
Права доступа хранятся в сессии пользователя и аннулируются при ее завершении. Любые изменения в ролях пользователя или его организации приводят к принудительной деавторизации и необходимости повторной авторизации для получения актуальных прав доступа.
В результате, была создана единая централизованная система, хранящая всю информацию о правах доступа для каждого сервиса, обеспечивающая гибкое, безопасное и удобное управление ролями в масштабе всей системы.
Добавим немного технических деталей:
Для каждого сервиса создается отдельная ролевая модель, в рамках которой можно настроить разделы и роли. Данный модуль позволяет добавлять сервисы, разделы и группы ролей. В каждом разделе можно указать роли на латинице и кириллице. Латинское наименование используется для проверки внутри систем. Роли объединяются в группы для разделения пользователей.
Есть история изменений. Любой менеджер, который может изменять ролевую модель или разделы, при внесении изменений оставляет свой идентификатор. Все изменения фиксируются в истории. Можно откатиться к предыдущим версиям через интерфейс.
Технически это работает так: есть базовая модель пользователя, ролей и секций. Каждая секция относится к определенному сервису. Доступ к сервисам разделяется на секции. В одном сервисе может быть одна или несколько секций, в зависимости от его размера. Но на них логика не заточена, они созданы для более удобного управления ролевой моделью. Хотя на некоторых сервисах есть доступы, привязанные к конкретным секциям.
Есть модель доступов, которая привязана к конкретной секции. Также есть модель "Ролевые доступы по умолчанию" — базовый набор, который используется для всех организаций, если не переопределен.
Есть модель организации, связанная с сетевыми обменами. Любое изменение пользователя, организации или логина происходит через брокер очередей Rabbit MQ для доставки изменений в режиме реального времени. Есть внутренний обмен для изменения пользователей или организаций и открытый обмен для получения доступов после авторизации пользователя, он происходит по HTTPS.
Решение на PHP под разные фреймворки.
В основе наших проектов лежит гибридный подход к выбору технологий, который позволяет создавать решения различного уровня сложности. Отметим, что в основном мы используем CMS: 1С-Битрикс. Почти все сервисы, что разработаны нашей компанией написаны на нём.
Функциональный уровень который заимствуем из Битрикса зависит от проекта, например, в разработке интернет-магазина, мы берем больше всего от стандартного Битрикса (пользователи, корзина, каталог, обмен с 1С (довольно прилично допиленный, но на стороне 1С) и т.п.), а при разработке личного кабинета контрагента для промышленной компании Битрикс был задействован по минимуму(метода и классы ядра).
Соответственно, в небольших проектах единая точка входа может быть реализована на нем. Однако, для больших проектов Битрикс не рассматриваем как отдельный сервис для единой точки из-за избыточности встроенных модулей.
Например когда всего два сервиса, единой точкой входа может выступать ЛК, единственная особенность что он должен совмещать в себе функциональность сервиса и единой точки входа. Однако, если проект начнет обрастать блоками функционала, от бизнеса начнут поступать еще задачи, то тогда нужно разделить единую точку входа и ЛК, реализован это можно на Laravel.
Почему именно Laravel, а не Symfony или что-то еще проще (Lumen или Slim).
Lumen/Slim: Можно рассматривать на старте, но с ростом функциональных требований (авторизация, управление ролями, привязка пользователей к организациям, работа с БД) станет менее подходящими. Реализация сложной ролевой модели на этих фреймворках потребовала бы нестандартных решений.
Symfony: Выбор Laravel был обусловлен наличием квалифицированных разработчиков в штате, что позволило сократить сроки разработки и обеспечить высокое качество решения.
В заключение, выбор платформы и архитектуры зависит от конкретных задач и требований проекта. Мы стремимся использовать наиболее подходящие инструменты для создания эффективных, масштабируемых и удобных в использовании веб-приложений.
