WSO2 ESB: получение значения Local Entry типа "Inline XML" внутри прокси-сервиса и работа с ним как с XML

Задача

Есть Local Entry типа "Inline XML", содержащая некоторый XML. Необходимо в прокси-сервисе извлечь эту XML и обработать ее, например, извлечь значение определенного узла с помощью XPath.

Решение

Для начала получаем значение Local Entry (пусть она называется 'localEntryName') как XML в свойство (пусть будет "localEntryXml"):

<property action="set" expression="get-property('localEntryName')" name="localEntryXml" scope="default" type="OM"/>

Здесь важно, что тип свойства указан "OM".

Теперь с этим свойством можно оперировать, например, выполнять на основе него фильтрацию:

<filter xpath="count($localEntryXml/*[text()='qwerty'])">
     <!-- -->
</filter>

WSO2 ESB: особенность использования FORCE_ERROR_ON_SOAP_FAULT=true

Если установить свойство FORCE_ERROR_ON_SOAP_FAULT в true:

<property action="set" name="FORCE_ERROR_ON_SOAP_FAULT"
scope="default" type="STRING" value="true"/>

то полученный от конечного сервиса SOAP Fault приведет к вызову faultSequence. Проблема такого подхода в том, что тело ответа от сервиса в таком случае будет недоступно (по крайней мере при логировании с уровнем full в лог пишется Envelope запроса, а не ответа).

WSO2 ESB: некорректное поведение throttle-медиатора при fault`ах конечного сервиса

Проблема:

В прокси-сервисе WSO2 ESB 4.5.1 нужно ограничить число параллельных вызовов конечного веб-сервиса. Для этого использован throttle-медиатор (используется именно медиатор, а не policy сервиса по той причине, что необходимо контролировать поведение при превышении лимита, что при использовании policy невозможно):

<?xml version="1.0" encoding="UTF-8"?>
<proxy name="MyThrottlingProxy" ... >
<target>
<inSequence>
<throttle id="wsthrottle">
<policy>
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:throttle="http://www.wso2.org/products/wso2commons/throttle">
<throttle:ThrottleAssertion>
<throttle:MaximumConcurrentAccess>1</throttle:MaximumConcurrentAccess>
</throttle:ThrottleAssertion>
</wsp:Policy>
</policy>
<onAccept>
<!-- ... -->
<send/>
</onAccept>
<onReject>
<!-- ... -->
<drop/>
</onReject>
</throttle>
</inSequence>
<outSequence>
<throttle id="wsthrottle"/>
<!-- ... -->
</outSequence>
<faultSequence>
<throttle id="wsthrottle"/>
<!-- ... -->
</faultSequence>
</target>
<!-- ... -->
</proxy>

(в данном случае число параллельных вызовов ограничено одним).

Здесь throttle-медиаторы с одинаковыми id размещены во всех трех последовательностях: in, out и fault. При выполнении медиатора в inSequence счетчик параллельно выполняющихся запросов инкрементируется и сравнивается с установленным ограничением. Если порог не превышен - запрос на конечный сервис отправляется, если превышен - сообщение отбрасывается. Выполнение throttle-медиатора в outSequence/faultSequence должно декрементировать счечик, т.к. запрос уже выполнился. Однако не тут то было. При выполнении faultSequence декремента не происходит, что приводит к тому, что упавший с ошибкой запрос с точки зрения throttle-медиатора становится бесконечно выполняющимся, что моментально парализует прокси-сервис, т.к. установлено ограничение всего в 1 параллельный запрос.

Чтобы разобраться в проблеме, пришлось включить логирование для throttle-медиатора добавлением в log4j.properties шины строчки:

log4j.logger.org.apache.synapse.mediators.throttle.ThrottleMediator=DEBUG

, а также посмотреть таки в исходники медиатора: http://www.docjar.com/html/api/org/apache/synapse/mediators/throttle/ThrottleMediator.java.html. Выяснилось, что декремент происходит, только если медиатор выполняется в последовательности обработки ответа, коей faultSequence почему-то не считается. Чтобы скорректировать поведение throttle-медиатора в faultSequence, пришлось перед ним добавить установку свойства RESPONSE в true:

<faultSequence>
<property name="RESPONSE" value="true"/>
<throttle id="wsthrottle"/>
<!-- ... -->
</faultSequence>

WSO2 ESB: вызов конечного сервиса, требующего HTTP Basic авторизацию

Тут все просто, перед <send/> делаем:

<property expression="fn:concat('Basic ', base64Encode('username:password'))" name="Authorization" scope="transport"></property> 

WSO2 ESB 4.5.1: установка имени очереди для JMS-транспорта прокси-сервиса

По-умолчанию, JMS-транспорт прокси-сервиса слушает очередь, имя которой совпадает с именем самого сервиса. Чтобы указать имя очереди явно, нужно задать параметр  сервиса "transport.jms.Destination":

<proxy xmlns="http://ws.apache.org/ns/synapse"
    name="myProxy" transports="jms">
    ...
<parameter name="transport.jms.Destination">myQueue</parameter>
</proxy>

WSO2ESB 4.5.1: настройка связки с Apache ActiveMQ 5.7.0

1) Скопировать из дистрибутива Apache ActiveMQ  5.7.0 следующие jar-ники в /repository/components/extensions шины:

• activemq-core-5.7.0.jar
• geronimo-j2ee-management_1.1_spec-1.0.1.jar
• slf4j-api-1.6.6.jar

2) Раскомментировать в axis2.xml настройки receiver`а и sender`а (предполагается, что ActiveMQ стоит на локальной машине и слушает порт по-умолчанию, 61616):

<transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener">
<parameter name="default" locked="false">
<parameter name="java.naming.factory.initial" locked="false">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
<parameter name="java.naming.provider.url" locked="false">tcp://localhost:61616</parameter>
<parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">QueueConnectionFactory</parameter>
<parameter name="transport.jms.ConnectionFactoryType" locked="false">queue</parameter>
</parameter>
</transportReceiver>
...
<transportSender name="jms" class="org.apache.axis2.transport.jms.JMSSender"/>

3) Всё, после перезапуска шины можно использовать JMS. Например, для конечных точек:

<endpoint>
<address encoding="UTF-8" statistics="disable"
trace="disable" uri="jms:/myQueue?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory&amp;java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&amp;java.naming.provider.url=tcp://localhost:61616&amp;transport.jms.DestinationType=queue"/>
</endpoint>

WSO2 ESB: java.io.IOException: line too long при развертывании Carbon Application

Проблема:

При старте WSO2 ESB 4.5.1 после развертывания Carbon Application валится исключение:

[2012-11-23 18:31:16,255] ERROR {org.wso2.carbon.server.extensions.DropinsBundle
Deployer} -  Error occured while deploying bundles in the dropins directory
java.io.IOException: line too long
        at java.util.jar.Attributes.read(Attributes.java:379)
        at java.util.jar.Manifest.read(Manifest.java:199)
        at java.util.jar.Manifest.<init>(Manifest.java:69)
        at java.util.jar.JarFile.getManifestFromReference(JarFile.java:179)
        at java.util.jar.JarFile.getManifest(JarFile.java:165)
        at org.wso2.carbon.server.extensions.DropinsBundleDeployer.getNewBundleI
nfoLines(DropinsBundleDeployer.java:95)
        at org.wso2.carbon.server.extensions.DropinsBundleDeployer.perform(Dropi
nsBundleDeployer.java:61)
        at org.wso2.carbon.server.Main.invokeExtensions(Main.java:128)
        at org.wso2.carbon.server.Main.main(Main.java:74)

Причина:

В одном из jar-ников директории  repository/components/dropins/ слишком длинная строка в файле манифеста META-INF/MANIFEST.MF, скорее всего, это строка Export-Package в случае, если в jar-нике много экспортируемых пакетов. Нужно разбить эту строку на несколько с помощью перевода строки и пробела (если в начале строки манифеста стоит пробел, она считается продолжением предыдущей строки), например:

Export-Package: my.package1, my.package2,my.package3
 my.package4, my.package5, my.package6, my.package7
 my.package8

WSO2ESB: доступ к параметру прокси-сервиса из пользовательского медиатора

Чтобы прочитать какой-либо параметр прокси-сервиса из кода пользовательского медиатора, нужно:

public boolean mediate(MessageContext context) {
org.apache.axis2.context.MessageContext axis2MsgContext;
axis2MsgContext = ((Axis2MessageContext)context).getAxis2MessageContext();
axis2MsgContext.getAxisService().getParameter("paramName");
...
}

WSO2 ESB: доступ к транспортному заголовку из медиатора

Доступ к транспортным заголовкам из медиатора осуществляется немного нетривиально:

public boolean mediate(MessageContext context)
{
org.apache.axis2.context.MessageContext axis2MsgContext;
axis2MsgContext = ((Axis2MessageContext)context).getAxis2MessageContext();
Map transportHeaders = (Map)axis2MsgContext.getProperty(org.apache.axis2.context.MessageContext.TRANSPORT_HEADERS);
System.out.println("FILE_NAME header is:\n\n"+(String)transportHeaders.get("FILE_NAME")+"\n\n");
}

В итоге выведенное в консоли значение будет совпадать с получаемым с помощью лог-медиатора:

<log level="custom">
<property name="FILE_NAME" expression="synapse:get-property('transport','FILE_NAME')"/>
</log>

WSO2 BAM 2.0.x: бинд порта для Thrift SSL на внешний сетевой интерфейс

WSO2 BAM 4.0.x биндит порт 7611 (по-умолчанию для Thrift) как на 127.0.0.1, так и на внешний сетевой интерфейс, а вот 7711 (по-умолчанию для Thrift SSL) - почему-то только на внешний. Поэтому при настройке отсылки событий на BAM использовать localhost нельзя, только внешний IP.

WSO2ESB и endpoint из реестра WSO2GREG

При добавлении WSDL в реестр WSO2GREG он создает в ветке реестра "/_system/governance/trunk/endpoints/..." ресурс, соответствующий конечной точке данной WSDL. 

При добавлении прокси-сервиса на WSO2ESB есть опция выбора конечной точки из реестра. Поэтому и появилась идея - почему бы не выбрать там конечную точку, волшебным образом созданную при импорте WSDL в реестр? Оказалось как бы не так: прокси сервис создается, однако при попытке отправить на него запроса возвращается лишь HTTP-загловок "202 Accepted", в логах - тишина, до конечного сервиса запрос также не доходит. При создании faultSequence с логированием, можно лишь увидеть, что возникающая ошибка имеет код 0 и текст "Configuration is not in proper format":

Synapse ERROR_CODE : 0 ERROR_MESSAGE : Configuration is not in proper format.

Оказывается дело в следующем: конечная точка, создаваемая в реестре при добавлении WSDL содержит лишь URL, тогда как ESB ожидает увидеть в реестре полноценную xml-конфигурацию конечной точки.

Так что единственный вариант использовать реестр для хранения конечных точек WSO2ESB - это вручную загружать туда xml-ки с их конфигурациями.

Источник: http://wso2.org/forum/thread/11705 

Error processing POST request: Transport level information does not match with SOAP Message namespace URI

WSO2ESB (а точнее, лежащий в её основе Apache Axis2) при поступлении входящего сообщения пытается определить используемую сообщением версию протокола SOAP (1.1 или 1.2). Делает он это 2 способами:

1. На основании пространства имен SOAP envelope, которое равно "http://schemas.xmlsoap.org/soap/envelope/" для вресии 1.1 и "http://www.w3.org/2003/05/soap-envelope" для 1.2
2. На основании HTTP-заголовка в случае, если нижележащим протоколом является HTTP. Для SOAP 1.1 должен присутствовать заголовок SOAPAction, для 1.2 может присутствовать параметр SOAPAction внутри заголовка Content-type.

В случае, если полученные в результате этих двух проверок протоколы не совпадают, генерируется ошибка "Transport level information does not match with SOAP Message namespace URI".

Похожая проверка выполняется для ответов, получаемых от внешних сервисов. Выполняется сопоставление пространства имен SOAP-конверта и HTTP-заголовка Content-Type. Для пространства имен SOAP 1.1 ожидается Content-Type "text/xml", для SOAP 1.2 - "application/soap+xml". В случае несовпадения также генерируется ошибка "Transport level information does not match with SOAP Message namespace URI".

WSO2ESB: localhost в ссылках на WSDL сервисов и в конечных точках внутри WSDL

Проблема:
В списке сервисов, развернутых на WSO2ESB, ссылка на WSDL содержит вместо ip-адреса или сетевого имени хоста просто "localhost". HTTP и HTTPS - конечные точки внутри WSDL также содержат вместо хоста "localhost".

Решение:
Хост, используемый при формировании ссылки на WSDL, а также хост-порт, используемые в ссылках на конечные точки внутри WSDL, настраиваются в файле repository/conf/axis2.xml следующим образом:

    <transportReceiver name="http" class="org.apache.synapse.transport.nhttp.HttpCoreNIOListener">
      ...

        <parameter name="bind-address" locked="false">192.168.0.101</parameter>
        <parameter name="WSDLEPRPrefix" locked="false">http://192.168.0.101:8280</parameter>
      ...
    </transportReceiver>
    <transportReceiver name="https" class="org.apache.synapse.transport.nhttp.HttpCoreNIOSSLListener">
      ...

<parameter name="bind-address" locked="false">192.168.0.101</parameter>
<parameter name="WSDLEPRPrefix" locked="false">https://192.168.0.101:8243</parameter>
      ...
    </transportReceiver>

Публикация данных с WSO2ESB 4.0.0 на WSO2BAM 1.3.0 и производительность ESB

По результатам тестирования приходится сделать неутешительный вывод - установка модулей публикации данных с ESB на BAM (http://barbitoff.blogspot.com/2011/08/wso2esb-400-wso2bam.html) приводит к падению пиковой производительности шины более чем в 50 раз и её нестабильности уже при 20 запросах в секунду (без модулей шина в моём случае выдерживает около 500 запросов без превышения временем обработки запроса порога в 1 сек). Причем наблюдается это даже в случае, если модули установлены, но публикация выключена в их настройках. Модули вызывают неэффективное использование памяти и возникновение исключений "ERROR - NativeWorkerPool Uncaught exception java.lang.OutOfMemoryError: unable to create new native thread", после чего сервер становится неработоспособным до перезагрузки.
Всё описанное выше актуально для Windows, в Linux зафиксировано лишь падение производительности медиации в 7-8 раз.

WSO2: настройка узлов кластера интеграционных шин на использование единого LDAP хранилища пользователей

Для того, чтобы не заниматься управлением пользователями на всех экземплярах WSO2ESB в кластере (впрочем, это относится не обязательно к кластеру, и вообще даже не только к ESB, а и к другим продуктам WSO2), удобно использовать единое хранилище пользователей. Вариантов здесь несколько: можно использовать JDBC-коннектор к единой БД, а можно - встроенный в Carbon LDAP-сервер.
Пусть всеми узлами будет использоваться LDAP-сервер узла-менеджера кластер-группы, слушающий порт 10386 (напомню, порт этот можно настроить в repository/conf/carbon.xml  в теге <LDAPServerPort>).
Тогда на всех остальных экземплярах шины необходимо зайти в  repository/conf/embedded-ldap.xml и установить:

<EmbeddedLDAP>
     <Property name="enable">false</Property>
     ....
</EmbeddedLDAP>

, чтобы они не стартовали свой LDAP, т.к. он больше нужен не будет. Затем идем в  repository/conf/user-mgt.xml и устанавливаем URL LDAP-сервера (в моем случае узел ESB, играющий роль менеджера кластер-группы, а теперь и менеджера пользователей, расположен на том же хосте, что и остальные узлы, т.е. на localhost) :

<UserStoreManager class="org.wso2.carbon.user.core.ldap.ApacheDSUserStoreManager">
     <Property name="ReadOnly">false</Property>
     <Property name="ConnectionURL">ldap://localhost:10386</Property>
</UserStoreManager>

Впрочем, <Property name="ReadOnly"> будет логичнее установить в true, чтобы вносить изменения мог только центральный узел, однако при попытке это сделать WSO2 вылетает с исключением, что, дескать, этот UserStoreManager должен быть Read/Write (возникает правда вопрос, зачем тогда в его настройках есть свойство ReadOnly?). Поэтому, если нужно, чтобы хранилище пользователей было только для чтения, меняем атрибут "class" тега UserStoreManager с org.wso2.carbon.user.core.ldap.ApacheDSUserStoreManager на org.wso2.carbon.user.core.ldap.LDAPUserStoreManager.

Очевидный минус подхода с использованием в качестве хранилища пользователей встроенного LDAP одного из экземпляров шины - необходимость запускать экземпляры в строго определенном порядке, и, более того, к моменту запуска slave-экземпляров LDAP-сервер на master-экземпляре должен успеть запуститься. Это условие затрудняет написание скриптов автоматизации запуска шин.

Замена favicon.ico в WSO2 Carbon

Файл favicon.ico находится тут:

repository\components\plugins\org.wso2.carbon.ui-3.2.0.jar\web\admin\images\

WSO2: настройка title страниц консоли администрирования и замена copyright в подножии

Title страниц задается в файле:

repository/components/plugins/org.wso2.carbon.ui-3.2.0.jar/web/admin/layout/template.jsp

подножие:

 repository/components/plugins/org.wso2.carbon.ui-3.2.0.jar/web/admin/layout/footer.jsp

При использовании русских символов нужно не забыть перекодировать файлы в UTF-8.

Особенности русификации продукции WSO2

По идее, русификация WSO2 - дело достаточно тривиальное. Необходимо извлечь из jar-ников директории repository/components/plugins/ все файлы Resources.properties, перевести их (вместо русских символов необходимо использовать т.н. "Unicode-последовательности") и закатать обратно. Однако не всё оказывается так просто, об особенностях этого процесса я и напишу ниже.

1) Русификация домашней страницы административной консоли (а также других страниц, на которых содержится запрашиваемые по AJAX данные)

Properties-файл для локализации домашней страницы консоли администрирования WSO2 (таблички, отображающей суммарную статусную информацию по серверу) расположен тут:

repository/components/plugins/org.wso2.carbon.server.admin.ui-3.2.0.jar/org/wso2/carbon/server/admin/ui/i18n/Resources.properties

Однако при попытке перевести расположенные там строчки, заменив их Unicode-последовательностями ('\u...'), соответствующими русскому переводу, в админке вместо русских букв появляются знаки вопроса (в отличие от других Resources.properties-файлов, локализация которых не вызывает каких бы то ни было проблем).
Дело в том, что эта табличка запрашивается с помощью AJAX со страницы

/carbon/server-admin/system_status_ajaxprocessor.jsp, которая неверно выставляет кодировку ответа (вернее она вообще не устанавливает никакой кодировки явно, и по умолчанию получается latin-1).  Для того, чтобы исправить дело, необходимо в repository/components/plugins/org.wso2.carbon.server.admin-3.2.0.jar/web/server-admin/system_status_ajaxprocessor.jsp явно задать кодировку ответа utf-8, добавив строчку: response.setHeader("Content-Type", "text/html;charset=UTF-8"); или установить тип содержимого с помощью атрибута  "contentType" директивы "page" <%@ page contentType="text/html;charset=UTF-8" %>

Аналогичные манипуляции необходимы также на всех других jsp-страницах, на которых кодировка не установлена корректно и к которым запрос ведется по AJAX.
ИМХО самый простой вариант, чтобы не осуществлять полное тестирование продукта для выявления всех страниц с побитой кодировкой - извлечь из jar-ников repository/components/plugins все файлы по регулярному выражению '/.*ajaxprocessor\.jsp$/', и произвести с ними вышеуказанные манипалуции (во многих из них менять ничего будет не надо, т.к. кодировка там уже задана). При этом важно пропускать файлы, используемые для генерации ява-скрипта или стилей, т.к. после установки типа содержимого "text/html" они перестанут восприниматься браузером!


2) Проблема с квадратиками вместо символов на странице "Статистика медиации", "Features", и, возможно, других в WSO2 ESB 4.0.0 в Mozilla Firefox

Если статистика отсутствует, то в табличках на странице "Статистика медиации" отображаются соответствующие надписи, причем курсивом. Мозилла нарисовать курсив указанным в стилях страницы шрифтом не может, поэтому на странице отображаются квадратики. Выход - либо менять шрифты, либо отображать курсив не курсивом. И то, и другое можно сделать в файле org.wso2.esb.styles-4.0.0.jar\web\admin\css\main.css.

3) Опасные для использования символы при переводе. Переводя ресурсы, необходимо заменять символы, которые могут разрушить html-разметку ("<", ">") или сделать некорректным JavaScript-код (двойные и одинарные кавычки), на соответствующие им кодовые последовательности. Также нельзя использовать переводы строки ("\n"), т.к. они будут разрушать строки в JavaScript (ведь в JS нельзя переходить на новую строку в пределах константной строки).

Пример SOAP-запроса на Security Token Service WSO2 Identity Server

Ниже представлен пример SOAP-запроса, отправляемого на Security Token Service для получения Security Token. Запрос имеет следующие параметры:

1. Субъект, запрашивающий токен, аутентифицируется парой логин / пароль: admin/admin
2. Сервис, для работы с которым запрашивается токен: https://192.168.50.102:3443/services/echo/
3. Тип запрашиваемого токена: SAMLV2.0
4. Тип ключа: симметричный
5. Размер ключа: 256
6. Пользовательская часть комбинированного ключа представлена base64-закодированным значением "g5WVRpUl7bKno8LYFC9JUGLpe1NZpkZ/"
7. Алгоритм калькуляции ключа: PSHA1
8. Ответ на запрос возвращается обратно (т.е. в ReplyTo указан "anonymous").

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
   <soapenv:Header>
  <wsse:Security>
   <wsu:Timestamp wsu:Id="Timestamp-17449452" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
     <wsu:Created>2011-10-05T05:03:40.568Z</wsu:Created> 
   </wsu:Timestamp>
  <wsse:UsernameToken>
   <wsse:Username>admin</wsse:Username>
   <wsse:Password Type="wsse:PasswordText">admin</wsse:Password>
  </wsse:UsernameToken>
   </wsse:Security>
<wsa:MessageID>
uuid:6B29FC40-CA47-1067-B31D-00DD010662DF
</wsa:MessageID>

<wsa:To/>
 <wsa:ReplyTo>
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
 </wsa:ReplyTo>
<wsa:Action>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action>
 
   </soapenv:Header>
   <soapenv:Body>
<wst:RequestSecurityToken xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
    <wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
    <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
        <wsa:EndpointReference xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
            <wsa:Address>https://192.168.50.102:3443/services/echo/</wsa:Address>
        </wsa:EndpointReference>
    </wsp:AppliesTo>

    <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</wst:TokenType>
    <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</wst:KeyType>
    <wst:KeySize>256</wst:KeySize>
    <wst:Entropy>
        <wst:BinarySecret Type="http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce">
            g5WVRpUl7bKno8LYFC9JUGLpe1NZpkZ/
        </wst:BinarySecret>
    </wst:Entropy>
    <wst:ComputedKeyAlgorithm>http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1</wst:ComputedKeyAlgorithm>
</wst:RequestSecurityToken>

 </soapenv:Body>
</soapenv:Envelope>

org.apache.rahas.TrustException: Unsupported WS-Trust version {org.apache.rahas.STSMessageReceiver}

Проблема:

При попытке отправить SOAP-запроса на Security Token Service Apache Rahas (в моем случае, как части WSO2 Identity Server) ответ не приходит, а в логах сервера появляется ошибка:

ERROR {org.apache.rahas.STSMessageReceiver} -  org.apache.rahas.TrustException: Unsupported WS-Trust version {org.apache.rahas.STSMessageReceiver}

Причина:
Видимо, в качестве пространства имен wst указан url "http://docs.oasis-open.org/ws-sx/ws-trust/200802" или другой, вместо необходимого "http://docs.oasis-open.org/ws-sx/ws-trust/200512".

Решение:
Установить пространство имен корректно:

 xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"