Как перенести существующее устаревшее веб-приложение для использования OAuth2

10

В настоящее время у меня есть 15-летнее устаревшее монолитное веб-приложение с почти 1 миллионом пользователей, использующее собственную систему авторизации и аутентификации: JAAS, имена пользователей и pwds хранятся в БД с базовым хешированием паролей, некоторые личные вопросы проверки 2FA (с разными алгоритмы хеширования и т. д.).

Я буду дорабатывать приложение в течение следующих 12-18 месяцев, в основном сосредоточившись на пользовательском интерфейсе, но также постепенно обновляя базовые компоненты (обновление до Spring, Spring Security и т. Д.). В рамках этого проекта мы решили заняться обновлением пользовательского интерфейса для каждого модуля отдельно; сделать каждый модуль доступным после его завершения; прекрасная возможность разбить монолит на отдельные веб-приложения (все поддерживают одинаковый дизайн UX).

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

Я застрял, пытаясь понять, как интегрировать это. Должен ли я создать свой собственный сервер OAuth2? Это поражает меня как ужасная идея. Но как мне:

  1. перенести все мои учетные записи пользователей и процесс авторизации на сторонний сервер OAuth2
  2. настроить внешний вид, чтобы он соответствовал остальной части моего приложения (не уверен, насколько легко / вероятно это будет)
  3. предотвратить типичное всплывающее окно «Приложению XYZ требуется разрешение на доступ к вашей учетной записи ...» при подключении через сторонний сервер? (например: Google OpenID, Facebook и т. д.).

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

Эрик Б.
источник
Интересно, будет ли достаточно единого входа? OAuth не кажется мне, какая система вам нужна здесь. Взгляните на CAS
Laiv

Ответы:

2

Раскрытие информации : я инженер в Auth0 .

Это зависит от одного основного момента ... вам нужно решить, если:

  1. вы хотите потратить значительное количество времени (и косвенно потратить деньги) на создание и / или обслуживание своего собственного провайдера идентификации и сервера авторизации
  2. или вы предпочитаете напрямую тратить деньги и использовать стороннего поставщика аутентификации, такого как Auth0.

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

Однако, прежде чем перейти к этому, независимо от вашего решения, для аутентификации вы должны сосредоточиться на OpenID Connect вместо OAuth2. Последнее будет более подходящим, если вы планируете также иметь в своем составе API, а не просто разделять монолит на отдельные веб-приложения.


Как перенести существующих пользователей в систему на основе Auth0?

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

Если вы предпочитаете продолжать использовать базу данных, см. Раздел «Аутентификация пользователей с помощью имени пользователя и пароля с использованием настраиваемой базы данных».

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

(Документы ссылаются на MySQL только в качестве примера, другие движки баз данных поддерживаются)

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

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

Вы также можете создать всех своих пользователей в Auth0 через API управления, если вы предпочитаете, чтобы все они сразу начали использовать наш алгоритм хэширования паролей. У этого есть побочный эффект требования, чтобы пользователи сбросили свой пароль.

Как продолжать использовать пользовательскую двухэтапную аутентификацию (вопросы проверки)?

Конвейер аутентификации, предоставляемый Auth0, полностью настраивается с помощью правил . Это означает, что даже если вам не нужно было реализовывать какие-либо связанные с протоколом вещи, вы все равно можете точно настроить мелкие детали того, как происходит аутентификация в вашем приложении.

Это включает в себя возможность дальнейшего использования существующих вопросов проверки в качестве способа выполнения двухэтапного процесса аутентификации, когда пользователь предоставляет исходный пароль, проверенный Auth0, а затем вы запрашиваете у них дополнительную информацию из пользовательского правила. (правила - это просто Javascript, поэтому возможности безграничны)

Однако вы также можете отказаться от вопросов проверки и использовать Auth0 Guardian для повышения безопасности процесса проверки подлинности.

Как настроить внешний вид интерфейса аутентификации?

С Auth0 вы можете мгновенно получить чистый интерфейс аутентификации, используя стандартные страницы входа в систему или виджеты аутентификации, такие как Lock . Все они поддерживают некоторую степень настройки, и вы всегда можете решить сделать свой собственный пользовательский интерфейс самостоятельно и вместо этого использовать библиотеки Auth0 более низкого уровня ( Auth0.js ), которые не ограничивают пользовательский интерфейс.

Для получения дополнительной информации о настройке:

Как предотвратить явное согласие страниц?

Вы можете использовать Auth0 как в качестве провайдера идентификации для аутентификации, так и в качестве сервера авторизации OAuth2 (в настоящее время доступен только в регионе США) для ваших API.

Как поставщик идентификационных данных вам не нужно беспокоиться о страницах согласия, пользователь аутентифицируется с помощью своих учетных данных, управляемых Auth0, а затем перенаправляется в ваше приложение - и все.

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


В заключение, это кажется очень интересным и сложным проектом, который вы получили, так что удачи независимо от вашего окончательного решения.

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

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

Если у вас есть дополнительные вопросы, дайте мне знать, если вы думаете, что я могу быть полезен.

Жоао Анжело
источник
Спасибо за все детали. Я помню, как смотрел на Auth0, но из того, что я могу сказать, Auth0 только для облака; это верно? Из соображений безопасности и конфиденциальности я ограничен просмотром только тех решений, которые я могу разместить в своем собственном центре обработки данных / персональном облаке. Предоставляет ли Auth0 такую ​​возможность?
Эрик Б.
Да, Auth0 очень гибок в плане развертывания / хостинга. В настоящее время решение для закрытого облака известно как Auth0 Appliance, и вы можете развернуть его либо в выделенной области облака Auth0, либо в своем облаке, либо в своем собственном центре обработки данных . Проверьте документы Appliance для получения дополнительной информации. Если вам нужна более подробная информация, дайте мне знать, я могу попытаться помочь вам напрямую или указать нужных людей.
Жоао Анжело