Mulesoft: URL-адрес принудительной реализации для прослушивания только прокси-сервера (или) URL-адрес безопасной реализации

Как заставить URL-адрес реализации прослушивать прокси только в Mulesoft?

Прямо сейчас прокси можно защитить с помощью client_id, client_secret и т. д. Однако URL-адрес реализации не является безопасным. Случайно, если кто-нибудь знает URL-адрес реализации, это потенциально рискованное дело.

Есть ли способ заставить URL-адрес реализации слушать только прокси.

(или) Можем ли мы добавить политики к URL-адресу реализации.


mule mule-component mule-esb mule-cluster
person Seshadri VS    schedule 09.09.2018    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Документация Mulesoft setting-up- api-proxy утверждает, что прокси-приложение — это не что иное, как приложение-мул, которое издевается над договорным поведением фактической реализации службы и выполняет служебные вызовы фактического API для выполнения запросов. Поэтому вместо HTTP рекомендуется использовать HTTPS для повышения безопасности и целостности данных. Поскольку Mulesoft предлагает использовать протокол HTTPS для соединения между прокси-сервером mule и реализацией службы, поэтому, используя протокол HTTPS, одним из вариантов может быть попытка внедрить двухсторонний SSL между вашим прокси-сервером и реализацией, что поможет вам принять запросы только от законных клиентов.

Проверьте тему enable-two-way-ssl-in-mule для получения дополнительной информации о реализации

Второй вариант — включить политики для фактической реализации службы, т. е. включить api-auto-discovery в вашем сервисе. Хотя вы можете это сделать, но это будет накладным из-за следующих причин:

  1. Поскольку вы применяете политики на двух уровнях и удваиваете вызовы диспетчера API для синхронизации политик, поскольку реализация службы будет опрашивать диспетчера API каждый фиксированный интервал времени для проверки/выборки политик.
  2. Чтобы включить приложение политики в реализации службы, служба должна работать в среде выполнения api-gateway runtime или mule 3.8, поскольку более старые версии Mule не поддерживают политики.

Реализация может быть выполнена с помощью приведенного ниже фрагмента XML в API xml.

<api-platform-gw:api apiName="app-${env}" version="${api.version}" flowRef="api-main" create="true" apikitRef="api-config" doc:name="API Autodiscovery" />
  • apiName будет определением API, созданным в диспетчере API, откуда вы сможете просматривать API и управлять им.
  • версия будет такой же основной версией API
  • flowRef сопоставит его с основной ссылкой на поток.
  • флаг создания, указывающий, нужно ли создавать определение в диспетчере API, если оно не существует

Вывод:

  1. Применить двусторонний SSL для принудительной проверки подлинности на основе сертификата клиент-сервер
  2. Добавьте автоматическое обнаружение в реализацию службы, чтобы применить политики и на уровне реализации.
person Navpreet Singh    schedule 11.09.2018

arrow_upward
0
arrow_downward

Документация Mulesoft предлагает добавить VPC. Когда мы тестировали, http работал в VPC, но не https.

Так как https был обязательным требованием и мы не могли сделать это через VPC, мы исправили это другим способом.

Мы добавили собственный заголовок в прокси-код и проверяем этот заголовок в реализации.

Это исправление вышло

person Seshadri VS    schedule 25.10.2018
comment
Между CloudHUb VPC и HTTPS нет несовместимости. Чего вы не можете сделать, так это реализовать двустороннюю аутентификацию SSL через балансировщик нагрузки CloudHub, однако для этого есть альтернативы. - person aled; 22.11.2018