JAX-WS добавляет пространство имен в подпись токена

Я получаю доступ к стороннему веб-сервису, используя сгенерированный JAX-WS код клиента (Java). Вызов службы, которая инициирует сеанс клиента, возвращает маркер в ответе, который, в частности, содержит подпись. Маркер требуется при последующих обращениях к другим службам в целях аутентификации.

Используя SoapUI, я узнал, что WS/Endpoint требует, чтобы токен использовался как есть... это означает, что все работает нормально, когда я буквально копирую токен (который представляет собой одну большую строку) из исходного ответа на любой запрос, который мне нравится делать следующий.

Теперь я делаю то же самое в своем клиенте JAX-WS. Я получил токен (я скопировал его из ответа, полученного с помощью Fiddler) и успешно протестировал его в последующем вызове с использованием SoapUI.

Однако при последующем вызове службы с помощью клиента JAX-WS часть подписи в маркере изменяется. Это должно выглядеть так:

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>

Но (при захвате запроса с помощью Fiddler) теперь он выглядит так:

<Signature:Signature xmlns:Signature="http://www.w3.org/2000/09/xmldsig#" xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature:Signature>

По-видимому, это неприемлемо в соответствии с WS/Endpoint, поэтому теперь я хотел бы знать:

  • Почему токен маршалируется таким образом?
  • Что еще более важно, как я могу помешать моему клиенту сделать это?

Заранее спасибо!


person Kjeld    schedule 24.02.2015    source источник


Ответы (2)


Вы проверили это? Тем не менее, он должен работать. Исходная подпись использовала пространство имен по умолчанию (... xmldigsig), версия JAXB использует то же пространство имен, но явно говорит, что элемент Signature принадлежит этому пространству имен (Signature:Signature). Эффект тот же, оба xml указывают, что подпись находится в http://www.w3.org/2000/09/xmldsig# пространство имен

Вы можете настроить вывод jaxby с помощью @XMLSchema в информации о пакете, @XMLType в классе или внутри элемента. http://blog.bdoughan.com/2010/08/jaxb-namespaces.html

person Zielu    schedule 24.02.2015
comment
Служба возвращает ответ, содержащий сообщение об ошибке, в котором говорится, что токен недействителен. Я думаю, что это действительно должно быть буквально таким, каким его предоставила служба ... или, может быть, это проблема адресации WS-A, с которой, как я думал, я уже имел дело? - person Kjeld; 25.02.2015
comment
Если вы уверены, что отправляете данные правильно, вам нужно посмотреть на сгенерированный класс Signature (и корень вашего документа, если это не Signagure), поскольку выводом jaxb можно управлять с помощью аннотаций из моего ответа. - person Zielu; 25.02.2015
comment
Спасибо, часть, которую вы добавили об аннотациях, была полезной, и изменение package-info.java решило эту часть. Хотя проблема еще не решена полностью: видимо, где-то в Токене есть еще один атрибут namespace, который нужно добавить. См. также мой новый пост: ссылка - person Kjeld; 27.02.2015

С помощью @Zielu я смог решить эту проблему, изменив package-info.java (в пакете сгенерированных файлов) следующим образом:

@javax.xml.bind.annotation.XmlSchema(
      namespace = "http://namespaceofthirdparty-asingeneratedversionof package-info.java"
    , xmlns = {
          @javax.xml.bind.annotation.XmlNs(namespaceURI = "http://www.w3.org/2000/09/xmldsig#", prefix = "")
    }
    , elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED) package com.where.generated.files.are;
person Kjeld    schedule 27.02.2015