Мне трудно выбрать подходящую / безопасную стратегию аутентификации для микросервисной архитектуры. Единственный пост SO, который я нашел по этой теме, это: Единый вход в микросервисной архитектуре.
Моя идея здесь состоит в том, чтобы иметь в каждой службе (например, аутентификация, обмен сообщениями, уведомление, профиль и т. Д.) Уникальную ссылку на каждого пользователя (вполне логично, тогда его user_id) и возможность получить текущего пользователя, idесли он вошел в систему.
Из моих исследований я вижу две возможные стратегии:
1. Общая архитектура
В этой стратегии приложение аутентификации является одним из сервисов среди других. Но каждый сервис должен иметь возможность сделать преобразование session_id=>, user_idпоэтому он должен быть очень простым. Вот почему я подумал о Redis, что бы хранить ключ: значение session_id:user_id.
2. Архитектура брандмауэра
В этой стратегии хранилище сеансов на самом деле не имеет значения, так как оно обрабатывается только приложением для аутентификации. Затем они user_idмогут быть перенаправлены в другие службы. Я думал о Rails + Devise (+ Redis или mem-cached, или о хранилище файлов cookie и т. Д.), Но есть масса возможностей. Единственное, что имеет значение, это то, что Service X никогда не понадобится аутентифицировать пользователя.
Как эти два решения сравниваются с точки зрения:
- безопасность
- прочность
- масштабируемость
- простота использования
Или, может быть, вы предложите другое решение, которое я здесь не упомянул?
Мне больше нравится решение №1, но я не нашел особой реализации по умолчанию, которая гарантировала бы мне, что я иду в правильном направлении.
Я надеюсь, что мой вопрос не закрывается. Я действительно не знаю, где еще спросить это.
заранее спасибо
источник
Ответы:
Исходя из того, что я понимаю, хорошим способом решения является использование протокола OAuth 2 (вы можете найти немного больше информации об этом на http://oauth.net/2/ )
Когда ваш пользователь войдет в ваше приложение, он получит токен, и с этим токеном они смогут отправить его другим службам, чтобы идентифицировать их в запросе.
Пример цепного микросервисного проектирования
Ресурсы:
источник
Краткий ответ: используйте аутентификацию на основе токенов Oauth2.0, которую можно использовать в любых типах приложений, таких как веб-приложение или мобильное приложение. Последовательность шагов, необходимых для веб-приложения, будет заключаться в следующем:
На схеме ниже показаны компоненты, которые могут потребоваться. Такая архитектура, разделяющая сеть и данные API, обеспечит хорошую масштабируемость, устойчивость и стабильность.
источник
Шаблон API-шлюза должен использоваться для реализации этого с использованием OpenID Connect. Пользователь будет аутентифицирован IDP и получит токен JWT с сервера авторизации. Теперь система шлюза API может сохранять этот токен в базе данных Redis и устанавливать cookie в браузере. API-шлюз будет использовать куки-файл для проверки запроса пользователя и отправит токен на микросервисы.
API Gateway выступает в качестве единой точки входа для всех типов клиентских приложений, таких как общедоступное клиентское приложение java-скрипта, традиционное веб-приложение, собственное мобильное приложение и сторонние клиентские приложения в архитектуре Microservice.
Вы можете найти более подробную информацию об этом на http://proficientblog.com/microservices-security/
источник
вы можете использовать idenitty server 4 для аутентификации и авторизации
вы должны использовать архитектуру межсетевого экрана, следовательно, у вас есть больший контроль над безопасностью , надежностью, масштабируемостью и простотой использования
источник