Как авторизовать внутреннюю связь микро-сервисов? - PullRequest
Новая
       98

Как авторизовать внутреннюю связь микро-сервисов?

0 голосов
/ 20 июня 2019

У меня есть несколько микро-сервисов. которые могут вызываться клиентом через API-шлюз, а также микро-сервисы могут связываться друг с другом.

В идеале запрос будет исходить от шлюза API от пользователя, который будет иметь все разрешения. здесь я пытаюсь назначить пользователю только требуемую роль, например, если пользователю (браузеру) нужны данные из микро-сервиса A, тогда только эта роль будет предоставлена ​​пользователю, и если внутренне микро-сервис A нуждается в данных из B (вызов покоя), то эта роль не должна быть назначена пользователю.

Требование: как ограничить / разрешить внутреннюю связь между микро-сервисами, чтобы только авторизованный микро-сервис мог звонить другим.

Параметры:

  1. Назначение всех ролей пользователю, даже для внутренней связи (передача одного и того же токена во всех сообщениях).

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

  3. Не разрешать микросервису осуществлять внутреннюю связь, а извлекать все данные из всех микросервисов и процессов на клиенте.

Какой вариант лучше использовать выше или любой другой?

Ответы [ 2 ]

1 голос
/ 21 июня 2019

Я бы выбрал вариант № 2. Для внутрисервисной связи бэкэнд-сервисы (приложения) будут действовать как клиент и сначала будут запрашивать токен (/oauth/token).Для проверки этих токенов всем сервисам потребуется механизм для проверки этих токенов (/oauth/check_token).Для этого вы можете использовать Client Credentials Grant type.Эти /oauth/** конечные точки предоставляются Spring.Чтобы сделать запрос REST от одного сервиса к другому, используйте OAuth2RestTemplate и , который не является потокобезопасным .

В каждом приложении вам необходимо определить правила защиты безопасностидля разных конечных точек.Примерно так: 

<sec:filter-security-metadata-source id="securityMetadataSource"
                                         request-matcher="ant"
                                         use-expressions="true">
        <sec:intercept-url pattern="/accounts/**" access="isFullyAuthenticated() and hasRole('PRIVATE_SERVICE')"/>
        <sec:intercept-url pattern="/members/member-details" method="GET" access="isFullyAuthenticated() and hasRole('PORTAL_USER')"/>

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

0 голосов
/ 24 июня 2019

Мы используем сочетание вариантов 1 и 2.

Если пользователь вызывает API, то если сначала шлюз вызывает службу A, а затем службу A вызывает службу B, то A передает тот же токен JWT в службу B.

В случае задания таймера в Сервисе A, которое периодически получает некоторые данные из Сервиса B, у Сервиса A также есть свой токен JWT, через который он делает вызов Сервису B.

...