Связь между серверами в микросервисах

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

Сначала позвольте мне кратко рассказать об архитектуре.

  1. Пользователь входит в систему и получает подписанный токен, который будет использоваться для вызова всех REST APIS.

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

  3. Службы должны взаимодействовать друг с другом для получения/обновления информации.

  4. Каждая служба будет иметь право проверять выпуск токена сервером аутентификации.

Проблема:-

  1. Все работает нормально, если пользователь входит в систему, и один и тот же токен используется и передается каждой службе, которая проверяется. Таким образом, службам не нужно доверять друг другу при передаче токена.

  2. Теперь проблема в том, что есть некоторые службы, которые необходимо вызывать с самого сервера без входа в систему. Допустим, вызов сервера на сервер. Как служба будет аутентифицировать и авторизовать вызов от других служб.

Я читал о Spring Microservices, но Zuul здесь тоже не спаситель, так как каждый сервер API имеет встроенную защиту Spring, а не только шлюз API.

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

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

Спасибо.


java microservices spring spring-cloud-netflix
person Art    schedule 16.06.2016    source источник
comment
Не защищайте эти службы и не разрешайте доступ всем с определенного IP-адреса. Просто напишите правильные правила безопасности.   -  person M. Deinum    schedule 16.06.2016
comment
@ M.Deinum ... эти службы должны быть защищены, поскольку они будут вызываться как внешними клиентами, так и мобильными телефонами / REST.   -  person Art    schedule 16.06.2016
comment
Как я уже упоминал, просто напишите правильные правила безопасности, если внутренний (или определенный диапазон IP-адресов) разрешает доступ, иначе необходим токен. Так что все сводится к правильным правилам безопасности, а не к попыткам обойти это.   -  person M. Deinum    schedule 16.06.2016
comment
@ M.Deinum M.Deinum, значит, вы говорите написать правило, например, если IP-адрес является локальным хостом, то просто не аутентифицировать и не авторизовать все?   -  person Art    schedule 16.06.2016
comment
@ M.Deinum, о, да ... я забыл об этом моменте в весенней безопасности. Выглядит правильно, позвольте мне попробовать это. Спасибо!!!   -  person Art    schedule 16.06.2016
comment
@ M.Deinum Я обнаружил, что могу использовать для этого IP ... но теперь, если я использую прокси, то это всегда будет локальный IP, в этом случае я могу использовать X-forwarded-for, так что вы можете сказать мне, насколько хорошо и пуля доказательством является использование X-Forwarded-For для проверки локального хоста. Если кто-то включил этот заголовок в запрос, то этот запрос будет аутентифицирован, поэтому только если X-forwarded-For содержит localhost, тогда он не будет аутентифицирован. Что ты говоришь?   -  person Art    schedule 17.06.2016
comment
Я бы рекомендовал вообще не разрешать микросервисам использовать синхронную связь (между микросервисами, нормально для пользовательского интерфейса/клиента использовать API) (вместо этого используйте обмен сообщениями и публикацию/подписку).   -  person Sean Farmar    schedule 17.06.2016
comment
@SeanFarmar Я согласен с вами, нам нужно пойти по асинхронному пути. Но для этого потребуется много изменений, и из-за других ограничений я не могу с этим согласиться, поэтому нужно использовать REST только между службами.   -  person Art    schedule 17.06.2016
comment
RaghavTandon, @M.Deinum У меня такой же сценарий. Не могли бы вы рассказать мне, как я могу реализовать правило IP?   -  person Sahil Chhabra    schedule 15.02.2018
comment
@ mav3n Можете ли вы доверять своим внутренним услугам? Если да, то нет необходимости добавлять какие-либо фильтры безопасности, иначе вам нужно передать какой-то токен, сгенерированный нижестоящей службе, который снова будет аутентифицирован и сформирует принципала аутентификации.   -  person Art    schedule 19.02.2018
comment
@RaghavTandon Спасибо за ваш ответ. Да, я делаю то же самое, передавая токен авторизации нижестоящему сервису. Выяснил, что белый список IP-адресов не будет решением этой проблемы, поскольку пользовательский интерфейс также будет находиться на том же IP-адресе, и я не хочу, чтобы он обходил аутентификацию для пользовательского интерфейса.   -  person Sahil Chhabra    schedule 20.02.2018

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

Информацию о Spring Security см. в документе spring-security-oauth2.

person cdelmas    schedule 16.06.2016
comment
сейчас я не использую OAuth. Но я думаю, что приведенные выше комментарии, в которых я могу обойти защиту для IP-адреса, могут быть полезными. - person Art; 17.06.2016

arrow_upward
1
arrow_downward

В идеале в архитектуре микросервисов мы не должны вызывать другие службы внутри службы. Вместо этого мы должны использовать подход издатель/подписчик для связи между серверами.

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

person Sahil Chhabra    schedule 20.02.2018