Есть ли такая вещь, как прокси-сервер SOAP, или мне придется свернуть свой собственный?

Question

Отказ от ответственности : Я пробовал поискать в Google что-то, что будет делать то, что я хочу, но не повезло. Я надеюсь, что кто-то здесь сможет протянуть руку.

Фон

У меня есть библиотека классов .NET, которая обращается к защищенному веб-сервису с помощью библиотеки WSE 2.0. Веб-служба предоставляет интерфейс для центральной базы данных (на самом деле это часть сети обмена данными, охватывающей несколько клиентов), а библиотека классов предоставляет простую оболочку для вызовов веб-службы, чтобы сделать ее доступной из унаследованного приложения VB6. Устаревшее приложение использует библиотеку классов для извлечения и публикации информации в веб-службе. В настоящее время приложение и библиотека библиотек классов установлены на стороне клиента на нескольких рабочих станциях.

Проблема

Суть в том, что веб-сервис, к которому мы обращаемся, использует HTTPS, и для доступа к нему необходимо предоставить действительный сертификат клиента X509. Поскольку все наши компоненты находятся на клиентском компьютере, это привело к проблемам развертывания. Например, нам необходимо загрузить и установить сертификаты для каждого пользователя на каждом клиентском компьютере, по одному для каждого пользователя, которому может потребоваться доступ к веб-службе через наше приложение. Более того, сам веб-сервер должен быть доступен через VPN (в частности, OpenVPN), что означает, что VPN-клиент должен быть установлен и настроен на каждом клиентском компьютере. Это большая проблема (у некоторых наших клиентов десятки рабочих станций).

Предлагаемое решение

Предлагаемое решение - перенести всю эту логику на центральный сервер на сайте клиента. В этом сценарии наше унаследованное приложение будет связываться с локальным сервером, который затем отключится и перенаправит запросы в реальный веб-сервис. Кроме того, все сертификаты X509 будут установлены на сервере, а не на каждом отдельном клиентском компьютере, в рамках усилий по упрощению и централизации развертывания.

Пока что у нас есть три варианта:

• Найдите готовый прокси-сервер SOAP, который может принимать входящие запросы SOAP на основе HTTP, изменять заголовок Host и связанные с маршрутизацией части сообщения SOAP (чтобы они указывали на настоящий веб-сервер), открывать SSL-соединение с реальным веб-сервером, представление правильного клиентского сертификата серверу (на основе сопоставления имени пользователя и сертификата), пересылка измененного запроса, чтение ответа, преобразование его обратно в открытый текст и отправка его обратно клиенту .
• Напишите прокси-сервер вручную, который сделает все, что я только что упомянул.
• Придумайте совершенно другой и, надеюсь, лучший способ решения этой проблемы.

Обоснование

Логическое обоснование попытки найти и / или написать прокси-сервер SOAP состоит в том, что нашу существующую библиотеку оболочки .NET вообще не нужно будет изменять. Мы просто указали бы на прокси-сервер вместо реальной конечной точки веб-службы, используя простое HTTP-соединение вместо HTTPS. Прокси-сервер обработает запрос, изменит его так, чтобы реальный веб-сервис принял его (например, изменил заголовок SOAPAction, чтобы он был правильным), обработал рукопожатие SSL / сертификата и отправил необработанные данные ответа назад к клиенту.

Тем не менее, в лучшем случае это звучит как ужасный хак для меня. Итак, какие наши варианты здесь?

• Могу ли я прикусить пулю и написать свой собственный прокси-сервер с поддержкой HTTP / SSL / SOAP / X509, чтобы сделать все это?
• Или ... есть готовое решение с достаточно расширяемым API, чтобы я мог легко заставить его делать то, что я хочу
• Или ... я должен использовать совершенно другой подход?

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

Обратите внимание, что мы не контролируем веб-сервер, на котором размещен веб-сервис.

РЕДАКТИРОВАТЬ : Для пояснения, я уже внедрил (довольно дрянной) прокси-сервер в C #, который отвечает требованиям, но что-то мне кажется в корне неверным по поводу всего этого подхода к проблеме. Так что, в конечном счете, я ищу либо подтверждение того, что я на правильном пути, либо полезный совет, говорящий мне, что я иду по этому пути совершенно неправильно, и любые советы, как сделать это лучше (если есть такой, который Я подозреваю, что есть).

Answer 1

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

Верблюд использует очень выразительный DSL для определения маршрутов между конечной точкой. В вашем случае вы хотите настроить сервер, который виден всем клиентским машинам на вашем клиентском сайте, и на любые полученные запросы вы хотите направить «из этой конечной точки» в вашу защищенную конечную точку через https.

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

public class WebServiceProxy extends RouteBuilder
{
    public void configure()
    {
       from("jetty:http://0.0.0.0:8080/myServicePath")
                  .to("https://mysecureserver/myServicePath");
    }
}

Добавьте это в контекст верблюда, и все будет хорошо.

CamelContext context = new DefaultCamelContext();
context.addRoute(new WebServiceProxy());
context.start();

Этот маршрут создаст веб-сервер с использованием jetty, привязанного к 8080, на всех локальных интерфейсах. Любые запросы, отправленные на / myServicePath, будут перенаправлены непосредственно на ваш веб-сервис, определенный uri https://mysecureserver/myServicePath. Вы определяете конечные точки, используя простой uris, а dsl и верблюд заботятся о подъеме тяжестей.

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

Я бы прочитал документы для верблюдов для компонента http для более подробной информации, также проверил бы модульные тесты для проекта, так как они полны примеров и лучших практик.

НТН.

К вашему сведению: чтобы компонент http использовал ваше хранилище ключей, вам необходимо установить следующие свойства

System.setProperty("javax.net.ssl.trustStore", "path/to/keystore");
System.setProperty("javax.net.ssl.trustStorePassword", "keystore-password");

Answer 2

Вы должны заглянуть в WCF, который поддерживает протокол WS-Addressing. Я полагаю, что я видел статьи (я думаю, в MSDN) о написании маршрутизаторов с использованием WCF.

Вам также следует как можно скорее избавиться от WSE 2.0. Он очень сильно устарел (его заменили на WSE 3.0, который также устарел). Все его функции были заменены WCF.

Answer 3

Вы также можете сделать это с Microsoft ISA Server , коммерческим прокси-сервером / кэшем. Это сделает много вещей, которые вам нужны из коробки. Для всего, что невозможно из коробки, вы можете написать расширение на сервер, чтобы сделать это.

ISA Server не является бесплатным.

ISA теперь переименовывается в «Microsoft Forefront Threat Management Gateway».

Это гораздо больше, чем веб-прокси-сервер - он имеет поддержку многих протоколов и много функций. Может быть, больше, чем вам нужно.

Answer 4

Я считаю, что ESB (Enterprise Service Bus) может быть жизнеспособным и надежным решением вашей проблемы. Существует ESB с открытым исходным кодом под названием Mule , который я никогда не использовал. Я действительно возился с ALSB (AquaLogic Service Bus) некоторое время назад, но это будет дорого для того, что вы описываете. Во всяком случае, вещь, на которую вы бы хотели обратить особое внимание, это маршрутизация. Я не уверен, что это будет простой plug-n-play, но это действительно другой вариант.

Answer 5

Ваша модель безопасности не имеет смысла для меня. Какова цель использования HTTPS? Обычно это аутентификация клиентов. В таком случае, зачем серверу хранить сертификаты клиентов? Именно клиенты должны хранить сертификат X509 сервера.

Зачем вам нужен VPN? Если вам нужно аутентифицировать клиентов, есть лучшие способы сделать это. Вы можете включить взаимную аутентификацию в SSL или использовать XML-Security и, возможно, WS-Security для защиты сервиса на уровне SOAP. Даже если вы используете SSL для аутентификации клиентов, вам все равно не следует хранить все сертификаты клиентов на сервере, а использовать PKI и проверять сертификаты клиентов на доверенный корень.

Наконец, специально для предложенного вами решения на основе прокси я не понимаю, зачем вам нужно что-то специфичное для SOAP. Разве вам не нужен веб-сервер, который может перенаправить любой HTTP-запрос на удаленный HTTPS-сервер? Я не знаю, как это сделать, но я бы исследовал подобные Apache и IIS ...

Answer 6

В Codeplex имеется инструмент виртуализации сервисов от Microsoft, называемый Managed Service Engine, который предназначен для отделения клиента от реализации веб-сервиса. Это может заполнить счет или дать вам возможность начать. Я не очень тщательно его изучил, просто просмотрел статью в MSDN, и ваше описание напомнило мне об этом.

• http://www.codeplex.com/servicesengine
• http://msdn.microsoft.com/en-us/magazine/dd727511.aspx