Как разработать самописную ролевую модель и единую точку входа для сервисов на микросервисной архитектуре

Единая точка входа сразу для нескольких цифровых сервисов одной компании. Удобно, не правда ли? Не нужно запоминать логин и пароль от каждого отдельного цифрового решения, постоянно где-то фиксировать эту информацию. Достаточно зарегистрироваться один раз и все, вы имеете доступ ко всем платформам компании. 

Тогда возникает вопрос, а что делать с безопасностью данных, как их защитить и выполнить соблюдение законодательства. Ответ оказался простым, ну или не очень, решать только вам. 

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

Начнем с азов

Что такое вообще роль - набор полномочий, который необходим пользователю или группе пользователей для выполнения определенных рабочих задач. Например, один 

сотрудник имеет одну роль, которая включает в себя разные доступы. Отметим, что в зависимости от принадлежности пользователя к организации, доступы можно отредактировать при необходимости. Если общий набор доступов к определенной роли не закрывает потребности для выполнения задач. 

Главный тут момент, что полномочия расширяются с каждой новой ролью присвоенной сотруднику.

Так где собака зарыта или на что следует обратить внимание при создании ролевой модели:

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

Гибкость и масштабируемость: Ролевая модель это не статичная сущность, она должна быть гибкой и масштабируемой, чтобы можно было адаптировать ее к изменяющимся потребностям и условиям. Бизнес процессы в компании с течением времени изменяются по разным причинам, внешние/внутренние - не важно, ролевая модель должна иметь возможность изменения/добавления и удаления текущих ролей.

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

От слов к делу 

Перейдем к рассмотрению практического примера:

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

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

Эволюция архитектуры авторизации:

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 был обусловлен наличием квалифицированных разработчиков в штате, что позволило сократить сроки разработки и обеспечить высокое качество решения.

В заключение, выбор платформы и архитектуры зависит от конкретных задач и требований проекта. Мы стремимся использовать наиболее подходящие инструменты для создания эффективных, масштабируемых и удобных в использовании веб-приложений.