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

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

0 голосов
/ 10 сентября 2018

Как заставить реализацию url слушать из прокси только в Mulesoft?

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

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

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

Ответы [ 2 ]

0 голосов
/ 26 октября 2018

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

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

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

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

0 голосов
/ 11 сентября 2018

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

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

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

  1. Как вы будете применять политики на двух уровнях и удваивать вызывает API Manager для синхронизации политик как сервиса реализация будет опрашивать менеджер 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 Manager, откуда Вы можете просматривать и управлять API
  • версия будет такой же основной версией API
  • flowRef отобразит его на основную ссылку потока
  • создать флаг, чтобы указать, нужно ли создавать определение в API Manager, если оно не существует

Вывод:

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