Предыстория:
Я пытаюсь использовать WSO2 ESB в корпоративной среде, чтобы обеспечить доступ с проверкой подлинности к базовым бэкэнд-провайдерам REST API, расположенным либо на предприятии, либо в Интернете.
Моя цель - выборочно предоставить доступ, например. к поставщику REST API P1 только к клиенту REST C1 и к поставщику REST API P2 только к клиенту REST C2.
Использование WSO2 ESB с «‹api›», как описано в http://wso2.com/library/articles/2012/10/implementing-restful-services-wso2-esb/, кажется, требует переопределения каждого ресурса, который может быть очень большим и подверженным ошибкам для сложных API (например, vmware vcloud Director REST API https://www.vmware.com/support/vcd/doc/rest-api-doc-1.5-html/landing-user_operations.html)
Использование WSO2 ESB «‹proxy›», как описано в https://docs.wso2.org/display/ESB481/Using+REST+with+a+Proxy+Service#UsingRESTwithaProxyService-RESTClientandRESTService («Клиент REST и служба REST») требует, чтобы URI открытые для HTTP-клиентов, будут изменены в соответствии с к исходному поддерживаемому uri. Типичные URI прокси-сервера будут иметь следующую форму с префиксом services и определенным портом http://:8280/services/CustomerServiceProxy/customers/123.
Хотя изменение открытых URI — это нормально, когда клиент может контролироваться (обычно это собственный пользовательский REST API). Это проблематично, когда REST API является отраслевым стандартом, а клиент представляет собой SDK или готовое приложение, которое находится вне контроля пользователей WSO2 (например, AWS S3 API или vmware vcloud Director REST API).
Кроме того, некоторые пользовательские клиенты/пакеты SDK могут проверять SSL-сертификаты на стороне сервера по открытому ключу, встроенному в пакет SDK/клиент.
Обычное решение для сохранения HTTP REST API как есть и добавления некоторой аутентификации поверх него состоит в том, чтобы предоставить API через HTTP-прокси (возможно, аутентификацию клиентов через HTTP-прокси-аутентификацию), т. е. клиент отправляет запрос CONNECT перед отправкой своего исходного запрос. Это сохраняет полные URI, а также сертификаты SSL.
Вопрос:
Есть ли способ заставить WSO2 ESB играть роль прокси-сервера HTTP (S) для передачи входящих запросов REST API, сохраняя исходные URI и SSL-сертификаты сервера?
Я думаю о новом синтаксисе «http-proxy›», который я еще не заметил. т.е. он будет слушать http://:3128/ и отвечать на запросы CONNECT. Затем посредничество будет иметь возможность принимать или не принимать CONNECT в зависимости от входных данных запроса CONNECT (прокси-аутентификация, запрошенный хост) и других заголовков HTTP-транспорта). После того, как запрос CONNECT будет предоставлен, может быть даже возможно действовать с последующими отдельными проксированными запросами.
Лучшие спецификации, описывающие поведение CONNECT, выглядят следующим образом: http://tools.ietf.org/html/draft-luotonen-web-proxy-tunneling-01 (проект 1999 г., который кажется принятым) и http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#page-29 предложенный стандарт.
Для URI HTTPS могут быть ограниченные возможности в посредничестве WSO2: HTTP-запрос шифруется SSL, и только домен может быть известен, если в запросе указан SNI (индикация имени сервера). По крайней мере, это позволило бы предоставлять/запрещать некоторые имена хостов набору клиентов в зависимости от аутентификации прокси.
