«Без паролей и боли»: как User Pool наводит порядок в тестовых учётных записях / Хабр

Привет, Хабр! На связи разработчик Куратов Кирилл из команды дирекции качества РТЛабс. Представлю вам нашу внутреннюю разработку — User Pool.

По названию понятно, что это пул пользователей, но глобально он представляет собой сервис для получения данных тестовых учётных записей. Наша команда использует User Pool во фреймворке для написания автотестов и в браузерном расширении для автоматической авторизации тестовых учётных записей в тестируемых сервисах. Например, в единой системе идентификации и аутентификации (ЕСИА), речь о которой пойдёт ниже. Также в конце будет небольшая история о том, как мы разрабатывали расширение для браузера и с какими трудностями столкнулись.

ЕСИА: сложный процесс авторизации с уникальными требованиями

Что такое ЕСИА и зачем мы к ней обращаемся
Госуслуги — один из основных государственных сервисов и должен быть надёжным. Для его тестирования существуют разные стенды, на которых обкатываются услуги команд. Это всё также надо тестировать.

ЕСИА — единая система для авторизации на Госуслугах и других государственных сервисах, посредством генерации токена. В нашем случае мы хотим получить этот токен и использовать его для внедрения в автотест во фреймворке или в расширении для браузера. ЕСИА — это не о тестах, а о единой системе идентификации, аутентификации и авторизации.

При работе с ЕСИА была интересная проблема, с которой можно столкнуться почти на любом сайте. Это защита от DDOS. При запуске тестов в ЕСИА будут одновременно идти пара десятков запросов, что логично заставит ЕСИА заблокировать на время доступ по айпи и не просто заблокировать, а заставит проходить капчу. Выбрались из этой ситуации довольно просто — внесли айпишники на которых работает User Pool в white-листы, но, к сожалению, локально запустить тесты в параллели не получится.

Также с ЕСИА была другая интересная ситуация. Если вы попробуете зайти в свою учётную запись (УЗ), вероятнее всего, придётся вводить код с телефона, и тестовые УЗ от этого не защищены. Как мы поступили в этом случае? Внесли в white-лист УЗ и добавили метод, чтобы при такой аномалии на них приходил одинаковый код. На этом все проблемы с ЕСИА закончились.

Отдельно хочу отметить, что в User Pool включена авторизация по ЕСИА. В статье она постоянно будет встречаться, ниже напишу про неё — почему для нас она так важна.

Проблемы с ЕСИА

Сложный процесс авторизации. Для получения токена в ЕСИА необходимо выполнить три шага: запросить авторизацию, подтвердить через смс или email и после этого получить токен. Из-за этого авторизация становится трудоёмким и сложным для автоматизации процессом. Каждый стенд ЕСИА, то есть тестовое окружение, имеет свои особенности, что требует адаптировать процесс авторизации под каждое.

Разные роли и параметры УЗ. Тестовые учётные записи в ЕСИА имеют разные роли — ИП, организация, физическое лицо, и параметры, например регион или сервис. Это требует гибкого подхода к управлению УЗ, чтобы каждая команда могла запрашивать учётные записи с нужными параметрами, и токен приходил с определённого стенда.

Как User Pool решает проблемы с ЕСИА

Автоматизация процесса авторизации:

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

2. Обработка защиты от DDOS и капчи:

User Pool интегрирован с белыми списками IP-адресов, что позволяет избежать блокировок со стороны ЕСИА при параллельном выполнении тестов,
когда ЕСИА требует прохождения капчи, User Pool использует заранее подготовленные коды подтверждения, что упрощает процесс авторизации.

3. Гибкость для разных ролей и параметров УЗ:

предоставляет гибкий API, который позволяет каждой команде запрашивать УЗ с нужными параметрами. Например, можно запросить УЗ с определённой ролью — ИП, организация, физическое лицо, или для конкретного сервиса,
каждая УЗ имеет набор параметров — дополнительных данных, которые учитываются при поиске. Это позволяет легко находить нужные УЗ для разных сценариев тестирования.

Для удобства и простоты понимания объединим эти данные в таблицу:

Проблема	Решение с User Pool
Разрозненные механизмы управления УЗ	Централизованное управление через API
Дублирование кода при работе с учётными данными в разных сервисах	Единая точка доступа, устраняющая необходимость дублирования
Необходимость синхронизировать изменения в разных частях системы	Единый сервис, упрощающий обновление логики работы с УЗ
Проблемы безопасности при хранении учётных данных на локальных машинах	Централизованное безопасное хранилище — Vault
Ограниченные возможности параллельного выполнения тестов	Механизм блокировки и освобождения УЗ

Почему существующие фреймворки не справились с ЕСИА

Они не предоставляют встроенных механизмов для работы с такими сложными процессами авторизации, как в ЕСИА. Для интеграции пришлось бы разрабатывать кастомные плагины и сценарии, что значительно увеличило бы сложность поддержки. Большинство из них не поддерживает автоматическую обработку капчи.

Итог: свой велосипед лучше чужого грузовика

Иногда проще построить свою лёгкую и удобную модель, чем пытаться превратить многотонный грузовик в простой горный велосипед. User Pool — это именно тот случай. Мы выбрали нелёгкий путь, но в итоге получили решение, которое идеально подходит для наших задач и не требует постоянных костылей для адаптации чужого инструмента.

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

*Отдаём предпочтение нашему сервису за преимущества*

Почему выбрали свой путь: User Pool против Amazon Cognito, Keycloak и ORY Hydra & Kratos

Мы рассмотрели несколько популярных альтернатив — Amazon Cognito, Keycloak и ORY Hydra & Kratos — и пришли к выводу, что ни одно из них не подходит для наших задач. Почему?

Общие признаки у всех фреймворков

ЕСИА — нетиповой флоу. Готовые IdP не «исполняют» многошаговый браузерный сценарий ЕСИА — редиректы, 2FA/SMS, промо-MFA, капча, особенности стендов, и не выдают или не проставляют cookie acc_t на *.gosuslugi.ru. Это требует отдельного клиента или скриптов и интеграции на уровне браузера.
Нет модели аренды тестовых УЗ. Отсутствует нативная семантика lock/TTL/release для конкурентных прогонов. Нужен внешний механизм, например Redis, и свой API оркестрации.
Нет доменной аллокации аккаунтов. Сложная выборка по атрибутам — роль ФЛ/ЮЛ/ИП, сервис, environment, регион, история использования, и правила бронирования — это бизнес-логика, которую всё равно надо реализовывать в отдельном сервисе.
Инфра и операционная стоимость. Перенос авторизации в чужую платформу или стек ломает текущие предпосылки — whitelist IP к ЕСИА, Vault, PostgreSQL, Redis, добавляет квоты или лимиты и рост TCO.
Избыточность. Большая часть функциональности прод-IAM нам не нужна, настройка или поддержка выше, чем у узкоспециализированного сервиса

Пробежимся конкретнее по фреймам

Amazon Cognito

Природа: Managed IdP в AWS (User Pools/Identity Pools, OIDC/OAuth2/SAML, Hosted UI, MFA, Lambda-триггеры). Выдаёт JWT (ID/Access/Refresh).

Ограничения для нас:

не автоматизирует ЕСИА-флоу и не проставляет acc_t на госдомен,
нет встроенного lock/TTL/release для тестовых УЗ — потребуются Lambda + внешнее хранилище,
доменная аллокация — роль/сервис/env/регион/история, придётся писать свой слой,
привязка к AWS — сети/квоты/стоимость, конфликтует с текущей инфраструктурой — PostgreSQL, Vault, Redis, whitelist к ЕСИА.

ORY Hydra & Kratos

Природа: Hydra — Authorization Server — OAuth2/OIDC, без хранения пользователей, Kratos — управление пользователями и self-service флоу. Часто вместе с Oathkeeper/Keto. Хранилище — обычно PostgreSQL.

Ограничения для нас:

многосервисная композиция: нужно стыковать несколько компонентов, описывать флоу — высокий входной порог/поддержка,
нет встроенного lock/TTL/release — снова внешний сервис оркестрации,
ЕСИА и acc_t не закрываются «из коробки» — потребуется отдельный клиент или расширение и ваша оркестрация.

Как User Pool может пригодиться в вашем проекте

Допустим, у вас есть несколько микросервисов, которым нужны учётные данные пользователей, например для логина. Кейс: в нашем приложении для тестировщиков есть функция автологина. Как это реализовать? Мы связываем наше приложение для автологина с User Pool, API которого предоставляет четыре базовые операции: Create, Delete, Update, Get.

Для автологина можно использовать методы: /api/v1/users/authUser — возвращает куку авторизации любого пользователя по параметрам.

Идеальное решение: API абстрагирует вас от подкапотных процессов, позволяя быть уверенными, что мы будем получать данные для автологина.

Стек технологий

User Pool реализован с использованием следующих технологий:

• Java + Spring — основной язык и фреймворк, поскольку автотесты в проектах пишутся на Java,

• PostgreSQL — основная база данных для хранения учётных записей и их атрибутов,

• Vault — хранилище паролей и генерация токенов для безопасного доступа,

• Feign Client (Apache Client) — удобный HTTP-клиент для работы с API,

• OpenAPI Swagger — инструмент для документирования API.

Вот как примерно выглядит всё, что используется в User Pool:

*Технологии, которые используются в User Pool*

Теперь можно рассмотреть весь процесс получения данных учётной записи. Для простоты понимания уйду от технической стороны и приведу упрощённое описание всех процессов.

Так как в нашей команде было принято решение сделать максимально защищённую систему авторизации и не возвращать пароли, в ответе используется кука. Во время запуска теста первым действием происходит запрос на авторизацию в сервисе ЕСИА и получение самой куки. Внутренний метод фреймворка посылает запрос на адрес пула /userpool/api/v1/users/auth с телом запроса:

ответ на этот запрос:

Что же происходит под капотом запроса /auth? Тело запроса разбивается на составляющие, которые определят, какая УЗ будет взята.

Вот как выглядит DTO ответа с учётной записью:

Коротко, что за поля:

id — генерируемый id-номер учётной записи,
login — в нашем случае логин это email или СНИЛС,
additionalData — ключ-значение, в котором мы храним данные по УЗ для её удобного поиска,
service, environment — это информация для внутренних команд о принадлежности УЗ.

Эти параметры отправляются через search запрос в нашу БД, и ищется подходящая учётная запись.Теперь у нас есть ID УЗ и по нему мы берём пароль из Vault.

Реализация получения пароля через Vault простая:

В коде это выглядит:

@Override
protected String getUserPassword(String oid) {
String password = vaultService.getPassword(oid).getPassword();
return encodeBase64(password); 
 }

Производим авторизацию через API ЕСИА и вытаскиваем куку с токеном. Упрощённо схема получения cookie выглядит так:

С момента вызова метода авторизации пользователя происходит несколько действий:

данные для входа отправляются POST запросом на ESIA,
в ответ приходит ссылка для перехода, по которой мы выбираем роль, остальные параметры нужны для множества других случаев и разных департаментов, для классических госуслуг это не используется,
по итогу из всех cookies вытаскиваем cookie с названием acc_t.

Весь код авторизации в ЕСИА очень большой, поэтому выложу укороченную версию:

public HttpCookie authorizeUser(ResponseUserDataDto userDto, Optional<Role> role, String gosuslugiUrl, String esiaUrl, String domain) {
    try {
        String password = new String(Base64.getDecoder().decode(userDto.getEncryptedPassword()));
        String login = userDto.getLogin().split(",")[0];
        AuthUserDto postLoginBody = new AuthUserDto(login, password);

        // === 1. Инициализация CookieStore для всего auth-процесса ===
        BasicCookieStore basicCookieStore = new BasicCookieStore();
        EsiaClient esiaClient = FeignHttpClient.createEsiaClient(esiaUrl, basicCookieStore);

        // === 2. Предварительное заполнение CookieStore ===
        // Добавляет стартовые cookies в зависимости от сервисов авторизации через (ESIA)
        basicCookieStoreFillerProviderService
                .fill(userDto.getService())
                .fill(gosuslugiUrl, basicCookieStore);

        // === 3. Отправка логина и пароля в ESIA ===
        ResponseEntity<ResponseDto> postLogin =
                esiaClient.postLoginAndPassword(postLoginBody);
        // === 4. Обработка post-login сценариев ===
        // - MFA (ENTER_MFA / FILL_MFA)
        // - MAX_QUIZ
        // - успешный redirect
        // - ошибки
        String redirectUrl =
                bypass2faOrPhoneConfirmation(userDto, postLogin, esiaClient);

        // === 5. Формирование итоговой авторизационной cookie ===
        HttpCookie httpCookie = httpCookieFactory
                        .get(
                                userDto.getService(),
                                userDto,
                                redirectUrl,
                                role,
                                gosuslugiUrl,
                                domain,
                                basicCookieStore
                        )
                        .get();

        log.info(String.valueOf(httpCookie));
        return httpCookie;

    } catch (FeignException ex) {
        throw new AuthMethodNotImplementedException(ex.getMessage());
    }
}

Учётная запись блокируется на то время, которое пришло в запросе или на 15 минут.

При завершении теста учётная запись освобождается запросом: /userpool/api/v1/users/release/{id}, где id нам известен и хранится в тесте.

Графически все взаимодействия User Pool можно представить как:

Как User Pool пригодился в расширении для браузера

Помимо фреймворка хочется отметить очень хорошую разработку для ручных тестировщиков — расширение для браузера для автологина.

Чтобы понимать, как работает на вид простое расширение, покажу, как оно выглядит за кулисами.

Суть нового расширения

Как говорилось выше, суть User Pool — это сделать процесс авторизации в аккаунт Госуслуг наиболее безопасным. Это расширение само встраивает в cookies необходимый токен для авторизации в учётную запись.

Как это происходит глазами тестировщика

После добавления расширения в браузер оно появляется в соответствующем меню.

Можно увидеть 5 полей с тем, что надо заполнить, и самое нижнее — Token. Это токен для доступа к User Pool.

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

Если токен рабочий и никаких ошибок не произошло, тестировщик увидит сообщение «Пользователь авторизован» и логин будет отображаться в поле «Recent used account».

Если вы пользовались Госуслугами, то точно знаете, что существуют роли УЗ для ИП, организации, физического лица. С учётом выбора в расширении роль тоже выбирается автоматически.

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

Подкапотная часть расширения

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

Начнём со стека, на котором было написано расширение: JavaScript + nodejs + typescript

На самом деле расширение по сравнению с User Pool довольно маленькое, но из-за неудобной документации компании Google доставило головной боли.

Начнём с простого, но важного файла:

{
     "name": "ЕСИА авторизация",
     "update_url": "https://clients2.google.com/service/update2/crx",
     "description": "Авторизация на госуслугах через пул учетных записей",
     "version": "__VERSION__",
     "manifest_version": 3,
     "icons": {
       "16": "resources/icons/16x16.png",
       "48": "resources/icons/48x48.png",
       "128": "resources/icons/128x128.png"
     },
     "permissions": [
       "debugger",
       "background",
       "cookies",
       "tabs",
       "webRequest",
       "storage",
       "sidePanel",
       "scripting",
       "notifications"
     ],
     "host_permissions": [
       "<all_urls>"
     ],
     "background": {
       "service_worker": "background.js",
       "type": "module"
     },
     "action": {
       "default_popup": "resources/index.html"
     }
 }

Manifest.json

Что такое manifest.json

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

Что внутри manifest.json

Название и описание. Расширение называется «ЕСИА авторизация», и его основная задача — автоматическая авторизация на Госуслугах через пул тестовых учётных записей.

Иконки. Расширение использует три размера иконок — 16x16, 48x48, 128x128, которые отображаются в интерфейсе браузера. Это делает расширение узнаваемым и удобным для использования.

Разрешения (permissions). Расширение запрашивает ряд разрешений для своей работы:

cookies — для работы с cookies, что необходимо для авторизации,
tabs — для взаимодействия с открытыми вкладками браузера,
webRequest — для перехвата и обработки сетевых запросов,
storage — для хранения данных, таких как токены и настройки,
scripting — для выполнения скриптов на страницах,
notifications — для показа уведомлений пользователю.

Эти разрешения позволяют расширению выполнять все необходимые действия для автоматической авторизации.

Фоновый скрипт (background). Расширение использует service worker — фоновый скрипт, который работает в фоновом режиме и обрабатывает события, такие как авторизация или обновление токенов. Тип «module» указывает на то, что скрипт использует современный синтаксис ES6.
- Попап (action). При нажатии на иконку расширения открывается попап — default_popup, который отображает интерфейс для выбора учётной записи и управления авторизацией. Интерфейс реализован в виде HTML-страницы (resources/index.html).

«Без паролей и боли»: как User Pool наводит порядок в тестовых учётных записях

ЕСИА: сложный процесс авторизации с уникальными требованиями

Как User Pool может пригодиться в вашем проекте

Как User Pool пригодился в расширении для браузера

Подкапотная часть расширения

Заключение

Глобальное значение User Pool для нас

Будущее развитие

Публикации

Информация