Отказоустойчивый сервер аутентификации

Наш заказчик - крупная международная металлургическая и горнодобывающая компания. В компании множество внутренних ресурсов и сервисов, обеспечивающих работу в компании. Например, корпоративный портал на базе Microsoft SharePoint, корпоративное мобильное приложение, SAP и многое другое.

В каждой корпоративной системе свой способ входа:

• По учётной записи Active Directory (AD)
• По мобильному телефону
• С помощью пропуска (через RFID метку)
• По СНИЛС
• И др.

Во время работы пользователя эти системы часто обмениваются данными друг с другом. И системе, в которую входят по номеру телефона, надо уметь «прозрачно» обрабатывать запросы от системы, в которую сотрудник зашёл по СНИЛСу. То есть нужен единый сервис аутентификации, которому будут доверять все внутренние системы и который будет знать про всех сотрудников заказчика.

С каждым годом внутренних сервисов в компании становится всё больше (появились системы, которые «пускают» по RFID или СНИЛС, хотя пару лет назад такого не было, а в каких-то «легаси» системах вообще свои внутренние пользователи и т.д.), и их нужно как-то объединять.

Дополнительной проблемой стала география – нынешний сервер аутентификации хостится на единственном сервере в Москве. Соответственно, любые перебои связи или падение сервера лишают сотрудников возможности работать, они просто не могут залогиниться в нужный сервис. А у клиента множество подразделений по всей России.

Перед нами поставили задачу по решению данной проблемы. И мы увидели здесь два варианта:

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

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

У нас уже был опыт реализации модулей аутентификации для отдельных приложений, где для этого использовался open source продукт Identity Server. Поэтому новый сервер аутентификации мы решили разрабатывать на базе этого же продукта. В первую очередь потому, что он поддерживает современные протоколы аутентификации – OAuth 2.0 и Open ID Connect, а также разработан на .Net Core. Кроме того, он обладает расширяемой архитектурой.

Кроме базовых возможностей сервера аутентификации (собственно, аутентификации пользователей), сервис должен уметь работать с разными источниками информации о пользователях, а также поддерживать двухфакторную аутентификацию (СМС, email, различные программные аутентификаторы и т.д.).

Реализовать все эти возможности позволяет расширяемая архитектура Identity Server. На первом этапе в подключении всех источников пользователей нет необходимости, но она потребуется в скором будущем. При этом сервер аутентификации довольно критичный ресурс и вносить в него изменения хотелось бы как можно реже. Поэтому мы решили реализовать работу с источниками пользователей и дополнительными факторами аутентификации через плагины.

Теперь о серверной архитектуре. У заказчика множество предприятий по всей России. Поэтому довольно очевидно использование отдельных экземпляров серверов аутентификации в разных регионах, которые будут объединены в «ферму» - иметь общую базу данных (вернее одинаковые её экземпляры, поддерживающие актуальность данных с помощью репликации на уровне Microsoft SQL Server).

Таким образом, пользователь, который начал процесс аутентификации, например, на московском сервере, сможет без проблем отправить подтверждающий код из СМС уральскому серверу, если московский вдруг «упал».

При этом клиентские приложения, которые будут работать с нашим сервером, будут снабжены «умными» модулями аутентификации – они будут уметь определять какой сервер для них ближайший, динамически отслеживать активность серверов и оперативно переключаться на другой сервер, а также «узнавать» о появлении нового сервера в ферме, даже если на момент разработки клиентского приложения он ещё не был введён в эксплуатацию.

Мы разработали такие модули для основных технологий, на которых создаются приложения у заказчика - .Net, .Net Core, Java, SWIFT, PHP. Разработчикам приложений останется только подключить модуль к своему решению и сервер аутентификации заработает в приложении.