В этой статье объясняется, как UltraESB может быть использован в качестве шлюза безопасности HTTP / S или SOAP для поддержки внутренних развернутых служб организации в SOA. С точки зрения безопасности UltraESB позволяет выполнять SSL-завершение, проверку / завершение WS-Security, проверку подлинности HTTP Basic / Digest, проверку SSL-сертификата клиента и т. Д. Кроме того, он предоставляет возможности проверки и преобразования и поддерживает безопасную обработку XML, которая защищает инфраструктуру от атак на основе XML.
обзор
UltraESB — это высокопроизводительный ESB, который использует Java NIO и поддержку операционной системы для Zero-Copy [1], когда это возможно, для обеспечения максимальной производительности и простоты использования. В настоящее время поддерживается транспорт, такой как HTTP / S, JMS, SFTP, FTP / S, электронная почта (POP3, IMAP, SMTP), файлы, TCP, MLLP / S с сообщениями SOAP, XML, Text, Binary, Hessian, Map, HL7 и т. Д. он предоставляет простую в использовании, но мощную платформу для построения платформы сервис-ориентированной архитектуры (SOA) для организации. Он доступен для неограниченного и постоянного использования бесплатно, с исходным кодом, доступным для партнеров. Конфигурирование UltraESB осуществляется с помощью файла конфигурации Spring и посредничества через Java, Spring или любые языки сценариев JSR 233, такие как Javascript, Groovy, Ruby и т. Д., Без необходимости изучения какого-либо нового языка конфигурации DSL или XML.Когда для передачи используются фрагменты Java или языки сценариев, исходный код может быть указан внутри или снаружи в конфигурации и динамически компилируется в байт-код во время выполнения. Таким образом, при развертывании сервисов в UltraESB нет ничего, что можно компилировать или связывать и т. Д. — все просто указано как конфигурация!
Прокси-сервисы и зачем они нужны
Прокси-служба определяет конечную точку, предоставляемую через ESB [«P»], которая принимает сообщения от внешних или внутренних клиентов и направляет эти запросы между одной или несколькими реализациями внутренней службы.
Использование Proxy, предоставляемого на ESB, вместо прямого предоставления реализаций службы имеет много преимуществ.
-
Например, прокси-служба может препятствовать привязке любого клиента или приложения к URL-адресам отдельных конечных точек службы, изначально предоставляемым реализацией службы. Это позволяет переносить реализации сервиса независимо на обновленные версии или URL-адреса и т. Д., Не нарушая работу производственных пользователей. Это также позволяет использовать несколько реализаций служб в группе «Балансировка нагрузки» или «Отказ при отказе», а также отключать отдельные конечные точки в автономном режиме для целей обслуживания, продолжая обслуживать пользователей с другими экземплярами.
-
Предоставление каждой услуги через ESB позволяет легко и последовательно выполнять защиту и проверки. Конечная точка прокси-службы может использоваться для выполнения базовой HTTP-проверки подлинности или дайджест-проверки подлинности, завершения SSL, двухстороннего применения SSL и необязательной проверки DN сертификата клиента или проверки или завершения WS-Security. Кроме того, сообщения могут проверяться на соответствие схеме или преобразовываться с использованием XSLT или других средств перед отправкой в реализации службы. Перенос этих аспектов в ESB упрощает реализацию внутренних сервисов, экономя время и усилия на тестирование, а также облегчает обслуживание через конфигурацию — без каких-либо изменений, необходимых для реализации сервисов в дальнейшем. Например, можно написать реализацию службы SOAP на PHP, но использовать возможности ES-WS-Security.
Незащищенные прокси-сервисы
Незащищенный прокси-сервер может обычно размещаться через HTTP как REST, SOAP, XML или любой другой тип — например, Hessian и т. Д. Определение такого прокси-сервера является тривиальным и состоит из определения, подобного следующему (см. Примеры № 101, 201 и т. Д. Для подробнее)
<u:proxy id="soap-proxy">
<u:transport id="http-8280"/>
<u:target>
<u:inDestination>
<u:address>http://localhost:9000/service/SimpleStockQuoteService</u:address>
</u:inDestination>
<u:outDestination>
<u:address type="response"/>
</u:outDestination>
</u:target>
</u:proxy>
Конфигурация UltraESB — это конфигурация Spring с пользовательскими расширениями для определений сервисов Proxy. Каждая прокси-служба идентифицируется идентификатором, который сопоставляет прокси-сервер с шаблоном URL-адреса, таким как «/ service / <proxy-id>». Конечно, контекстный путь по умолчанию или желаемое имя службы настраиваются. Транспортный идентификатор относится к одному или нескольким определениям прослушивателя транспорта, которые являются стандартными компонентами Spring, подобными следующему определению.
<bean id="http-8280" class="org.adroitlogic.ultraesb.transport.http.HttpNIOListener">
<constructor-arg ref="fileCache"/>
<property name="port" value="8280"/>
</bean>
Используемый порт, время ожидания сокета по умолчанию или интерфейс, используемый для приема подключений в системе с несколькими IP-адресами и т. Д., А также многие дополнительные параметры полностью настраиваются и по умолчанию настроены на готовые к работе параметры для простоты.
Конечные точки — Round Robin, Failover, Random, Weighted и т. Д.
«Цель» прокси-службы определяет место назначения для сообщений. В приведенном выше примере входящие сообщения направляются в конечную точку SimpleStockQuoteService, а полученные ответы отправляются обратно первоначальному клиенту — т.е. inDestination и outDestination. Получатель может определить одну конечную точку или несколько конечных точек как циклически распределенные, взвешенные, случайные или отказоустойчивые группы с балансировкой нагрузки (дополнительные примеры см. В примере № 601).
Обнаружение тайм-аутов, сбоев и непредвиденных ошибок и отключение конечных точек
Хотя некоторые ESB ограничивают переключение при сбое только при сбое попытки подключения на сетевом уровне, UltraESB дополнительно позволяет проверять ответные сообщения — например, на транспортных заголовках или в теле ответа. Таким образом, можно удалить конечные точки с ошибками или тайм-аутом, а также конечную точку, которая возвращает недействительные / неожиданные ответы от группы. Временные сбои приводят конечные точки к повторным попыткам, а превышение предела повторных попыток или критический отказ (такой как непринятие соединений) приводит к приостановке конечной точки. Конечные точки приостановки или тайм-аута периодически проверяются на повторное появление или действительную работу в соответствии с заданными по умолчанию или указанными параметрами конфигурации.
Сообщения могут отправляться на конечные точки другим транспортом, чем тот, который получил сообщение. Таким образом, возможны HTTP / S в JMS, SFTP в файлы, HL7 / MLLP в SOAP, электронная почта в JMS или любой другой транспорт в любой другой формат передачи или сообщения, но это выходит за рамки данной статьи.
Посредничество сообщений с последовательностями — включая поддержку JTA
Сообщения, полученные через прокси-службу, и ответы, полученные от внутреннего ответа, могут быть опосредованы множеством способов с использованием нескольких подходов. UltraESB не определяет новый DSL или язык на основе XML для своих пользователей, но вместо этого позволяет им взаимодействовать с языком, к которому они уже привыкли. API-интерфейс UltraESB в основном ограничен двумя классами и, возможно, опосредован фрагментами кода Java, классами Java, компонентами Spring или любым языком сценариев JSR 233 (например, Groovy, Javascript, Ruby и т. Д.), Скриптлетами или файлами. (См. Ниже примеры определений последовательностей). API позволяет легко инициировать, фиксировать или выполнять откат транзакций JTA, так что любое посредничество, использующее ресурсы, осведомленные о JTA, автоматически привязывается к транзакциям (см. Пример № 105 о том, как JTA использовался с HTTP и JDBC).Он также поддерживает приостановку и возобновление транзакций — и, таким образом, сообщение может быть отправлено удаленной службе, а транзакция приостановлена до получения ответа для принятия решения о принятии или откате.
1. Базовая HTTP и дайджест-аутентификация
HTTP-аутентификация определяется на уровне транспортного прослушивателя, и в UltraESB можно иметь несколько экземпляров прослушивателя через несколько портов. Для использования обычной проверки подлинности или дайджест-проверки подлинности используется конфигурация, подобная следующей, где запросы фильтруются. Обратите внимание, что поставщик учетных данных для проверки подлинности является стандартным определением Spring Security и, таким образом, позволяет использовать информацию проверки подлинности для базы данных, хранилища в памяти, настраиваемого поставщика или любого другого поставщика, поддерживающего безопасность Spring.
<bean id="http-8280" class="org.adroitlogic.ultraesb.transport.http.HttpNIOListener">
<constructor-arg ref="fileCache"/>
<property name="port" value="8280"/>
<property name="requestFilters">
<list>
<bean class="org.adroitlogic.ultraesb.transport.http.auth.BasicAuthenticationFilter">
<property name="realmName" value="adroitlogic"/>
</bean>
</list>
</property>
</bean>
<s:authentication-provider>
<s:password-encoder hash="md5"/>
<s:user-service>
<s:user name="asankha" password="abac6d7582d9ab52c629f7490fd3eb2f" authorities="ROLE_ADMIN, ROLE_USER"/>
</s:user-service>
</s:authentication-provider>
В этом примере мы используем провайдера аутентификации в памяти с хешированными паролями. Однако при использовании дайджест-аутентификации исходный пароль должен быть доступен для ESB (см. Пример # 103), хотя он может быть задан как зашифрованная строка с использованием Jasypt [2].
2. Защита сервисов с помощью WS-Security
Защищенный прокси-сервер WS-Security может быть легко доступен через UltraESB, не тратя много времени на изучение и написание WS-Policy и других конфигураций. Чтобы использовать WS-Security с UltraESB, обычно требуется определение bean-компонента WSSecurityManager для конфигурации, как показано ниже.
<bean id="wssecMgr" class="org.adroitlogic.soapbox.WSSecurityManager">
<constructor-arg value="samples/conf/keys/ws-sec-keystore.jks"/>
<constructor-arg value="password"/>
<constructor-arg>
<map>
<entry key="alice" value="password"/>
<entry key="bob" value="password"/>
</map>
</constructor-arg>
</bean>
WSSecurityManager определяет хранилище ключей идентификации и доверия, а также пароли для доступа к учетным данным. Любые пароли, хранящиеся в конфигурации UltraESB, могут быть легко зашифрованы с помощью Jasypt согласно статье [2]. Пример # 204 показывает типичный сценарий завершения WS-Security с использованием меток времени, подписей и шифрования с аутентификацией UsernameToken, для которой полная конфигурация выглядит следующим образом:
<u:proxy id="ws-sec-proxy">
<u:transport id="http-8280">
<u:property name="wsdlURL" value="file:samples/resources/SimpleStockQuoteService.wsdl"/>
</u:transport>
<u:target>
<u:inSequence>
<u:java><![CDATA[
try {
WSSecurityManager wssecMgr = Mediation.getWSSecurityManager();
wssecMgr.verifyUsernameTokenAuthentication(msg);
wssecMgr.verifyTimestampedEncryptedAndSignedMessage(msg, true);
} catch (Exception e) {
Mediation.setPayloadToSOAP11Fault(msg, null, "Security validation failed", null);
Mediation.sendResponse(msg, 500);
}
]]></u:java>
</u:inSequence>
<u:inDestination>
<u:address>http://localhost:9000/service/SimpleStockQuoteService</u:address>
</u:inDestination>
<u:outSequence>
<u:java><![CDATA[
Mediation.getWSSecurityManager().timestampSignAndEncryptMessage(msg, "bob", "alice");
]]></u:java>
</u:outSequence>
<u:outDestination>
<u:address type="response"/>
</u:outDestination>
</u:target>
</u:proxy>
При защите сообщения с помощью WS-Security можно указать личность подписавшего (например, «bob») и идентификатор шифрования (например, «alice»). API обеспечивает чрезвычайно простую настройку, хотя и приводит к полному определению WS-Security. Различные сложные аспекты безопасности, такие как алгоритмы и размеры ключей и т. Д., Можно легко настроить с помощью API [3].
Образец № 204 дополнительно показывает, как незащищенные запросы, например запросы, исходящие из организации, могут быть обогащены организационными или партнерскими стандартами WS-Security при отправке. Конечно, API упрощают использование только подмножества функций WS-Security — например, только меток времени и подписей без шифрования (например, когда запросы выполняются через SSL по соображениям производительности)
3. SSL-терминация и двухсторонняя SSL-аутентификация клиентов.
Транспортный список UltraESB SSL позволяет указывать хранилища ключей идентификации и доверия, что позволяет правильно использовать SSL между клиентами и прокси-службой.
<bean id="https-8443" class="org.adroitlogic.ultraesb.transport.http.HttpsNIOListener">
<constructor-arg ref="fileCache"/>
<property name="sslVerifyClient" value="optional"/>
<property name="identityStorePath" value="conf/keys/identity.jks"/>
<property name="identityKeyPassword" value="password"/>
<property name="identityStorePassword" value="password"/>
<property name="trustStorePath" value="conf/keys/identity.jks"/>
<property name="trustStorePassword" value="password"/>
<property name="port" value="8443"/>
</bean>
Свойство «sslVerifyClient» будет указывать, требуется ли аутентификация клиента (т. Е. Двухсторонний SSL), необязательная или не используется. Для целей тестирования свойство nonProductionNoRemoteCertValidation отключает удаленную проверку сертификата, хотя его не следует использовать в производственных системах. При отправке запросов через SSL к удаленным службам транспортный отправитель UltraESB допускает аналогичную спецификацию свойств для конфигурации, включая способ проверки имени хоста. В целях тестирования вся проверка может быть снова полностью отключена.
Используя настраиваемое хранилище доверенных сертификатов, в котором хранятся сертификаты CA, которым доверяет организация, и собственные сертификаты CA, легко обеспечить доступ к сервисам только законным пользователям или деловым партнерам. Необязательно, свойства сертификата клиента (например, DN доступно как msg.getMessageProperty («ultra.https.client_dn»)) могут использоваться во время передачи, чтобы принимать решения об уровнях безопасности или приоритетах и т.д. во время передачи.
Начало работы с UltraESB
Полный дистрибутив UltraESB имеет размер ~ 25 МБ и включает в себя готовые к запуску образцы, макетные сервисы и клиентские инструменты для тестирования всех функций, описанных выше, в течение нескольких минут. ToolBox [4] позволяет отправлять запросы без использования SSL / 2-way SSL, а также использовать предварительно определенные запросы WS-Security для тестирования или нагрузочного тестирования.
Узнайте больше о UltraESB на http://adroitlogic.org
Тест производительности
Недавно AdroitLogic опубликовал результаты 4-го раунда тестирования производительности ESB и публично предоставил все ресурсы, чтобы позволить конечным пользователям легко сравнивать UltraESB с другими вариантами — на локальном оборудовании или на Amazon EC2 [5]. Производительность WS-Security, в частности, является исключительной с более чем 3X TPS по сравнению с альтернативами, использующими стандартные реализации на основе WSS4J.
Рекомендации
[5]
http://adroitlogic.org/samples-articles-and-tutorials/15-tutorials/48-esb-performance.html