Active Directory – одна из самых популярных служб каталогов, её использует большинство наших заказчиков. Так что необходимость интегрироваться с ней появляется практически в каждом проекте. Чтобы командам не приходилось каждый раз решать эту задачу заново, наши разработчики создали сервис, который теперь можно в готовом виде встраивать в другие продукты. Делимся опытом.
У любого продукта есть пользователи, и их информацией надо как-то управлять - создавать учётные записи, сохранять пароли, добавлять пользователей в группы и т.д. Пользовательские данные хранятся в Active Directory, так что разработчикам новых продуктов нужно выстроить связи с этой службой, прописать все необходимые процессы, позаботиться о безопасности.
Эту часть работы мы сейчас и автоматизировали в рамках отдельного микросервиса AReS – от Account Registration Service. Он умеет заводить в AD новых пользователей, отправлять им письма с регистрационной информацией, напоминать о необходимости придумать пароль. Это законченный компонент, и его можно копировать практически в любой продукт.
Архитектура процесса
Когда пользователь регистрируется в системе, его данные поступают в RabbitMQ, откуда их подхватывает AReS. В пакете вся информация, которая нужна для создания учётной записи:
- имя пользователя,
- электронный адрес,
- группы, в которых он участвует,
- рассылки, которые он получает.
Эти данные AReS передаёт в Active Directory, а точнее – микросервису Active Directory Management Service. Информация сохраняется в базе, после чего пользователю остаётся создать пароль.
Одним из требований к AReS было не пересылать пользователям пароли, даже временные. Так что вместо этого сервис отправляет письмо со ссылкой, которая ведёт на страницу для создания пароля. Логика настроена таким образом, что у пользователя есть две недели, чтобы придумать код доступа. За это время ему дважды придёт напоминание – через неделю и 13 дней после попытки регистрации. Если по окончании этого периода пароль так и не создан, учётная запись в AD помечается как неактивная.
За отправку писем отвечает модуль MailService. Он же хранит и макеты писем, чтобы все уведомления приходили в аккуратном виде, оформленные по корпоративному стилю.
В итоге мы имеем законченный процесс: пользователь отправляет свои данные, они сохраняются в Active Directory, доступ к системам защищается паролем, который невозможно перехватить.
Преимущества
Самое главное, AReS готов к использованию в любых продуктах. Как мы говорили в начале, такова была изначальная задача – избавить команды от необходимости заново писать один и тот же модуль. Дизайн, содержание и периодичность писем, бизнес-логику участвующих сервисов можно легко менять. Значит, меньше рутинной работы, меньше вероятности, что в код попадёт ошибка, которую потом придётся отлавливать. И больше времени на более интересные задачи.
Второй важный плюс – AReS получает данные через Rabbit, поэтому не нужно выстраивать прямую коммуникацию между ним и продуктом, который мы подключаем к AD. Такая архитектура позволяет построить событийную модель и быстро конструировать разнообразные сложные сценарии: автоматическое создание групп пользователей, развёртывание политик, контроль доступа к информационным ресурсам.
И снова скажем про безопасность паролей – при таком подходе их знают только пользователи.
Как мы планируем развивать модуль
AReS уже работает в боевом режиме в одном из наших продуктов, в ближайшее время мы подключим его ещё к одной системе. Далее мы планируем интегрировать его с нашим Центром уведомлений, чтобы он обеспечивал рассылку вместо MailService.
Центр уведомлений – это наш специальный продукт для управления коммуникациями всех корпоративных сервисов. Он замыкает в себе контроль всех уведомлений и рассылок, способ их доставки и прочие тонкости, которые зашиты в логику каждой отдельной системы. Так что, если компания использует Центр уведомлений, необходимость в дополнительном модуле в виде MailService отпадает.
Мы также хотим расширить возможности для работы с самой AD. Она позволяет управлять не только учётными записями пользователей, но и их рабочими станциями. Можно настраивать возможность для групп сотрудников использовать только специфические компьютеры – например, чтобы никто не мог авторизоваться на ноутбуке гендиректора. То же самое с кассами, терминалами, другими устройствами, где нужно авторизоваться через AD. Наш модуль поможет встроить правила работы с ними в логику продуктов, чтобы администраторам не приходилось настраивать её дополнительно.