Единый вход в архитектуру Microservice

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

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

Я могу думать о нескольких подходах:

Добавить службу и приложение удостоверения. Любая служба, которая защищала ресурсы, будет обращаться к службе удостоверений, чтобы убедиться, что учетные данные, которые она имеет, действительны. Если они не будут перенаправлены пользователю на аутентификацию.
Используйте веб-стандарт, такой как OpenID, и каждый сервис обрабатывает его собственные идентификаторы. Это означает, что пользователь должен будет самостоятельно разрешать каждую услугу/приложение, но после этого он будет SSO.

Я буду рад услышать другие идеи. Если конкретный PaaS (такой как Heroku) имеет запатентованное решение, которое также было бы приемлемым.

Ответ 1

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

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

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

Наша архитектура развертывания была распространена через виртуальное частное облако AWS (VPC) и наши собственные центры данных компании. Служба проверки подлинности OAuth 2.0 была расположена в центре данных компании, а все наши приложения были развернуты в AWS VPC.

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

Ответ 2

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

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

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