SSO и каталог сервисов для подрядчиков
Проект собрал две вещи, которые пользователям нужны вместе: единый вход в корпоративные сервисы и каталог, где понятно, куда идти, как получить доступ и что делать подрядчику после подключения.
- Роль
- Разработчик и технический консультант в проектной команде
- Срок
- 2 месяца на MVP SSO, 3 недели на каталог сервисов
- Стек
- Keycloak, Active Directory, PHP/Symfony, Vue.js
- Фокус
- Единый вход, подключение подрядчиков, доступ к сервисам
Разрозненный доступ
Сотрудники и подрядчики жили в наборе разрозненных сервисов: отдельные ссылки, логины, пароли и инструкции. Потерянный доступ быстро становился тикетом поддержки, а подключение внешних пользователей зависело от ручной переписки.
Граница первого релиза
В первый релиз нельзя было положить все сценарии доступов. Нужны были единая точка входа, интеграция с текущей идентификацией и такой сценарий подрядчика, который можно развивать после подключения первых сервисов.
Keycloak и AD
Keycloak стал Identity Provider, Active Directory осталась источником идентификации на первом этапе. Так команда не писала собственный слой авторизации и не ломала уже работающий контур пользователей.
Каталог сервисов
Каталог сервисов вышел за три недели, пока финализировалась SSO-часть. Он закрыл простую, но болезненную проблему: где найти нужный сервис, какие есть правила доступа и что нажимать дальше.
Подход
Кабинет подрядчика
Коробочные платформы были избыточны для первого объема. Кабинет сделали на PHP/Symfony и Vue.js, чтобы не тащить лишнюю платформенную сложность и держать интерфейс ближе к реальному подключению подрядчика.
MVP SSO
За два месяца команда подняла инфраструктуру разработки, согласовала структуру SSO, настроила Keycloak, подключила идентификацию через Active Directory и включила SSO к первому корпоративному сервису.
Операционные изменения
После запуска стало проще объяснять путь подрядчика, меньше вопросов уходило в поддержку из-за паролей, а каталог сервисов снял часть навигационных вопросов у сотрудников.
Дальнейшая работа
Кабинет подрядчика можно было развивать от MVP уже через фактическое использование: какие сервисы нужны чаще, где пользователи спотыкаются и какие права действительно приходится выдавать.