Авторизация и аутентификация через WSO2: достойная замена ADFS

В больших компаниях, как правило, обширная внутренняя инфраструктура: это внутренние порталы, хранилища данных, различные сервисы и т. д. В рамках экосистемы продуктов (а у нас таких большинство) удобнее всего обеспечивать единый вход (Single Sign-On, SSO) в систему. Single Sign-On — это метод аутентификации, который позволяет войти в несколько сервисов, используя один набор учетных данных. Раньше за этот функционал отвечал ADFS. Раньше за этот функционал отвечал ADFS. 

Почему стоит отказаться от ADFS?

Перейти на другой сервис мы решили по нескольким причинам:

• Версия ADFS, которая у нас была, работает на устаревшем и уже не очень безопасном протоколе SAML. Поддержка нового протокола OpenID Connect возможна только на новой версии, а из этого как раз вытекает вторая причина.
• Вторая причина - проприетарность технологии. ADFS является продуктом Microsoft и в нынешних условиях, когда большинство российских технологических компаний находится под санкциями, обновить его до новой версии невозможно.

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

• Попытаться обновить ADFS до последней версии
• Curity
• Auth0
• Keycloak
• WSO2

Почему выбрали WSO2?

WSO2 и Keycloak – это продукты, которые позволяют реализовать Single Sign-On и управлять доступами. С Keycloak мы знакомы не понаслышке, ведь часть наших сервисов переведена на этот сервис, но другая часть разрабатывалась для заказчика, в чьей инфраструктуре уже был WSO2 как стандарт, что склонило чашу весов в сторону этой технологии.

Какие еще плюсы у WSO2:

• WSO2 – это open source решение, а значит, тут полностью исключается проблема проприетарности.
• Переход помог бы решить часть имеющихся проблем. В частности - избавиться от дублирования учеток, так как у сотрудников есть одна учетная запись для внутренних ресурсов, а вторая для внешних.
• WSO2 поддерживает современный механизм авторизации OpenID Connect, что положительно скажется на безопасности.
• Широкие возможность кастомизации.
• Это современная технология мирового уровня, которую развивает сообщество.

Бесшовный переход

Мы четко понимали, что не должно возникнуть такого момента, что мы переключим свои более 100 сервисов одномоментно, и все резко станет по-новому. ИТ-экосистема должна развиваться эволюционно, и переход должен быть плавным.

Требовалась последовательная работа:

На старте у нас было 100 сервисов, подключенных к текущему identity provider (у нас это ADFS).

1. Мы не могли совершить резкий переход, так как это бы вызвало массу проблем. Мы отработали технологию, при которой какой-то период времени авторизация ADFS и WSO2 смогут существовать параллельно – настроили федерацию между WSO2 и ADFS, а потом настроили перенаправление из текущего identity provider в новый. 
   
   Федеративная аутентификация применяется, когда, например, сотрудникам двух разных компаний нужно иметь доступ к общим сервисам. Она позволит сделать одну организацию главной, хранить там все учетные данные, а остальные участники процессов смогут обращаться к ней. В нашем случае при таком решении авторизация приложения происходит сразу в двух системах.
2. Протестировали переключение на тестовом окружении. После проверки качества перешли к переключению в продакшн.
3. Последовательно в каждом приложении мы переключали авторизацию со старого identity provider на новый. И благодаря тому, что все приложения ходили через старого в новый, то это позволяло сохранять SSO.
4. При переводе всех сервисов и приложений старый identity provider отключали.
5. Чтобы сохранить опыт, к которому привыкли пользователи, мы кастомизировали форму входа на WSO2.
6. По завершении перехода мы держали на контроле все параметры на уровне техподдержки, чтобы убедиться, что все отработано точно, как и задумано.  

Важно отработать технологию так, чтобы пользователи, которые работают в системе, не заметили перехода. Для этого использовали Sidecar-контейнер – паттерн для расширения и улучшения функциональности основного приложения без внесения в него изменений.

Какие специалисты были задействованы

• Архитектор для планирования и работы с командами при переключении приложений и сервисов.
• DevOps-инженер для работы с инфраструктурой
• Техподдержка для мониторинга процесса входа и оперативного решения ошибок
• Команды, которые поддерживают сервисы, тимлиды и руководители проектов для внесения и реализации работ в текущие планы
• При этом отдельно выделенной для этого рабочей группы не было. Нужна политическая воля, квалификация и внесение нужных задач в регулярную работу команд :)

Почему стоит довериться нам в этой задаче

• Мы обладаем необходимым опытом и командой специалистов
• Опыт эксплуатации и реализации приложений и сервисов с использованием ADFS более 10 лет
• Сертифицированные специалисты по Microsoft
• Мы реализовали порядка 100 приложений и сервисов c использованием WSO2, Keycloak
• Провели успешную миграцию более 50 приложений, обеспечивающих критически важные бизнес-процессы в компании

 Мы готовы совместно с вашими специалистами:

• Провести аудит текущих приложений и их схем авторизации/аутентификации
• Выбрать оптимальный с учетом вашей инфраструктуры и задач продукт для реализации SSO
• Осуществить развертывание и конфигурирование продукта SSO
• Применив нашу методологию, разработать четкий план миграции и поставить задачи вашим продуктовым командам
• Взять на себя управление проектом для сопровождения команд и получения запланированного конкретного результат на каждом этапе миграции