Я переконфигурирую существующую веб-службу SOAP для работы за шлюзом приложений Azure с брандмауэром веб-приложений.
Веб-служба SOAP написана на C # и работает в Azure как веб-роль в облачной службе Azure. В настоящее время он поддерживает как SOAP 1.1, так и SOAP 1.2.
Я настроил шлюз приложений Azure с включенным брандмауэром веб-приложений для запуска перед этой службой. WAF использует набор правил OWASP 3.0.
При отправке тестовых запросов из SoapUI создается впечатление, что WAF шлюза приложений пропускает запросы SOAP 1.1, но блокирует запросы SOAP 1.2 (возвращая ошибку 403). Я не могу найти ссылку на то, почему это может происходить в документации или что-то еще. Я знаю, что это WAF, потому что его отключение пропускает запросы SOAP 1.2.
Заголовки HTTP для (рабочего) запроса SOAP 1.1 выглядят следующим образом (URL-адреса служб и пространства имен удалены):
POST http://{serviceURL}/{service}.asmx HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: "http://{namespaceURL}/{method}"
Content-Length: 3672
Host: {serviceURL}
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
HTTP-заголовок для (не работающего) запроса SOAP 1.2 выглядит следующим образом:
POST http:/{serviceURL}/{service}.asmx HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/soap+xml;charset=UTF-8;action="http://{namespaceURL}/{method}"
Content-Length: 3652
Host: {serviceURL}
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Глядя на журналы WAF, я думаю , что проблема заключается в изменении Content-Type, которое основано на моем (не всестороннем) понимании SOAP 1.2, является правильным.
Любые мысли приветствуются. Похоже, что SOAP остается достаточно широко используемым, чтобы шлюз приложений Azure / WAF поддерживал его.