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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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