2.2 Взаимодействие с бэкендом
Взаимодействие Hiring микрофронтенда c бэкенд микросервисами (рисунок 3), как и в случае микрофронтенда Host Application, будет осуществляться по REST API с использованием спецификации JSON: API [4]. Использование JSON: API позволит указывать в запросах связи, использовать нормализацию, тем самым избегая дублирования данных, запрашивать не все поля ресурса, а также использовать готовые решения для сортировки и фильтрации.
Рисунок 3 – Связь Hiring микрофронтенда с бэкенд-микросервисами
OpenResty выступает качестве обратного прокси-сервера между клиентом и сервером бэкенд-микросервиса Public Gateway Microservice, выступающего в качестве API Gateway. В требующих авторизации запросах в заголовок запроса “Authorization”:” Bearer” размещается Access токен, валидируемый и проставляемый непосредственно перед проксированием посредством использования директив LUA в конфигурации сервера. Поскольку авторизация реализована в Host-Application, там же реализовано хранение и refresh Access токена. Токен хранится в приватной переменной класса, осуществляющего авторизацию, тем самым уменьшая риск CSRF и XSS уязвимостей. HTTP заголовки безопасности, такие как X-Frame-Options, X-Content-Type-Options и X-XSS-Protection, также проставляются в конфигурационном файле сервера с помощью использования LUA-директив. Сервер настроен для сжатия загружаемых файлов с помощью утилиты gzip.
2.3 Интеграция с Access Control и pip Service
В ходе разработки Hiring также будет произведена необходимая согласно NFR-5 работа с конфигурационными файлами двух бэкенд-микросервисов: Access Control и PIP Service.
Access Control реализует выдачу прав доступа пользовательским ролям на выполнение CRUD-операций, а также выполняет принятие решения о доступе. Это готовое корпоративное Attribute-Based Access Control решение [11], частично основанное на XACML стандарте, состоящее из бэкенд-микросервиса, реализующего PAP и PDP, а также Java-библиотеки, с помощью которой реализован PEP, обращающийся к PDP по REST API. В ходе выполнения ВКР будет произведена работа с конфигурационным JSON-файлом, в котором для всех необходимых объектов и их view будут созданы политики для новой пользовательской роли “HR-Hiring” и правила для этих политик (см. подробнее в подпункте 2.3.1 “Конфигурация прав доступа в Access Control”).
PIP Service микросервис реализует выдачу расширенных прав доступа. В ходе выполнения ВКР будет произведена работа с конфигурационным JSON-файлом микросервиса (см. подробнее в подпункте 2.3.1 “Конфигурация расширенных прав доступа в Pip Service").
Опишем пронумерованные на рисунке 4 процессы, которые будут достигнуты путем осуществления интеграции Hiring с Access Control и PIP Service:
Рисунок 4 – Интеграция с Access Control и PIP Service
Пользователь, совершающий запрос, уже аутентифицирован и авторизован.
Hiring Microfrontend выполняет запрос к Hiring Microservice, в заголовке запроса “Authentication: Bearer” передается выданный пользователю Access токен,
Hiring Microservice перехватывает запрос на доступ к ресурсу с помощью PEP, реализованного с помощью использования Java-библиотеки. PEP делает запрос решения к PDP, передавая ему следующие атрибуты: название микросервиса, из которого осуществляется запрос, название выполняемой операции, доменное имя пользователя, которое получает из payload Access токена, и название ресурса, к которомy будет осуществляться доступ,
PDP запрашивает у PAP политики доступа,
При необходимости получения расширенных прав доступа PDP аутентифицируется с помощью Identity Provider для получения M2M токена и дальнейшего обращения к PIP Service,
PDP обращается к PIP Service для получения дополнительной информации, например, при наличии у правила определенной политики условия,
PDP передает PEP ответ на запрос на доступ,
Hiring Microservice возвращает Hiring Microfrontend запрашиваемые данные в случае полученного разрешения в запросе на доступ.