Вызов веб-службы .NET (WSE 3.0, WS-Security) из JAXWS-RI - PullRequest
0 голосов
/ 02 марта 2010

Я пишу клиент JAXWS-RI, который должен вызывать веб-службу .NET, использующую WS-Security. WSDL службы не содержит никакой информации WS-Security, но у меня есть примерное мыльное сообщение от авторов службы, и я знаю, что я должен включить заголовки wsse: Security, включая токены X: 509.

Я занимался исследованиями и видел примеры людей, вызывающих этот тип веб-службы от Axis и CXF (в сочетании с Rampart и / или WSS4J), но ничего об использовании простого JAXWS-RI. Однако я (к сожалению) ограничен использованием JAXWS-RI моим клиентом gov't. У кого-нибудь есть какие-нибудь примеры / документация по этому поводу от JAXWS-RI?

Мне нужно в конечном итоге сгенерировать заголовок SOAP, который будет выглядеть примерно так, как показано ниже - это пример заголовка soap: из клиента .NET, написанного авторами сервиса. (Примечание: я поместил строку 'VALUE_HERE' в те места, где мне нужно указать свои собственные значения)

<soapenv:Envelope xmlns:iri="http://EOIR/IRIES" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
  <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401- wss-wssecurity-secext-1.0.xsd">
     <xenc:EncryptedKey Id="VALUE_HERE">
       <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
       <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
          <wsse:SecurityTokenReference>
             <wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
             VALUE_HERE
            </wsse:KeyIdentifier>
         </wsse:SecurityTokenReference>
       </ds:KeyInfo>
       <xenc:CipherData>
          <xenc:CipherValue>VALUE_HERE</xenc:CipherValue>
       </xenc:CipherData>
       <xenc:ReferenceList>
         <xenc:DataReference URI="#EncDataId-8"/>
       </xenc:ReferenceList>
    </xenc:EncryptedKey>
  </wsse:Security>

Ответы [ 3 ]

1 голос
/ 19 мая 2010

После долгой работы над этим наша команда разработчиков решила, что мы не можем этого сделать. Мы просто не могли написать клиента Metro (JAXWS-RI + WSIT), который бы правильно вызывал и обрабатывал ответ от веб-службы .NET WSE 3.0, использующей WS-Security. Я хотел написать наши разные подходы для тех, кто может попробовать что-то подобное в будущем.

Подведем итог: 1. Наш первый проход: веб-сервис WSE 3.0 с MutualCerticates11 Security (WS-адресация, шифрование, подпись, безопасный разговор (ws-trust)). Мы обработали фрагмент кода WS-Policy, чтобы поместить его в нашу локальную копию WSDL, чтобы исправить это, но не смогли получить исходный запрос рукопожатия безопасного разговора, который будет принят WSE.

  1. Затем они понизились до WSE 3.0 MutualCerticates10, поскольку существует некоторая болтовня о том, что он «более совместим». Опять же, мы не смогли заставить работать безопасное рукопожатие.

  2. Мы попросили команду .NET отключить уровень SecureConversation (WS-Trust) (требования к шифрованию и подписи там, где они еще есть). Опять же, мы обратили внимание на файл WS-Policy (по сути, просто удалили раздел «BootstrapPolicy», который касается WS-Trust / SC). В этот момент мы смогли отправить им зашифрованное подписанное сообщение, и они получили его и отправили сообщение обратно. Мы думали, что это победа, но, к сожалению, WSIT подавился ответным сообщением с ошибкой канонизации. На данный момент, я думаю, мы достигли ограничений WSIT, так как он не претендует на совместимость с WSE 3.0 (только WCF), поэтому мы поговорили с парнями из WSIT на их форуме и зафиксировали с ними проблему. Вот эта ссылка .

  3. Итак, мы пришли к выводу, что команде .NET не удастся оставить слой шифрования / подписи включенным (на данный момент, во всяком случае, команда WSIT может исправить ошибку в какой-то момент). К сожалению, вы не можете отключить только подпись и оставить шифрование.

  4. Мы также попросили их полностью отключить настройки WS-Security на своей стороне (.NET), и в этот момент они могли отправлять запросы и получать ответы от своих служб с использованием JAXWS-RI. , Тем не менее, они могут быть не в состоянии развернуть этот способ в производстве.

  5. Итак, теперь мы находимся в точке, где команда .NET должна определить, будет ли им разрешено запускать веб-службу в рабочей среде без параметров WS-Security. Если нет, то мы не сможем подключиться к их сервису, пока они не обновятся до WCF. И, на самом деле, это была наша рекомендация для них все время - чтобы они обновились до WCF - и теперь мы более знакомы, чем хотели бы знать причины этого!

1 голос
/ 03 марта 2010

Попробуйте настроить свой порт с

com.sun.xml.ws.api.security.CallbackHandlerFeature

Использует пользовательскую реализацию

javax.security.auth.callback.CallbackHandler

, который принимает

java.security.PrivateKey

и

java.security.cert.X509Certificate

, который вы загружаете из ресурса на вашем пути к классам. Я только что написал об этом здесь: http://upthescala.blogspot.com/2010/03/essential-sources-for-jax-ws-x509.html.

См. Com.sun.xml.ws.commons.EC2 (в загрузке исходного кода, указанной в записи блога, указанной выше) для примера настройки порта (включая загрузку секретного ключа и сертификатов X.509 из файла) .

Я бы выложил больше кода, но у меня нет моей коробки для разработки, поэтому я не могу по-настоящему протестировать.

Удачи!

0 голосов
/ 23 марта 2010

Я все еще работаю над некоторыми проблемами, пытаясь решить эту проблему, но я хотел бы обновить некоторые детали подхода, на котором я остановился. Первое, что я понял, это то, что мне пришлось перейти с JAXWS-RI 2.1 на Metro 2.0. Ранее мы использовали JAXWSRI-2.1 в этом проекте, но нам никогда раньше не приходилось иметь дело с WS-Security. Во всяком случае, я понял, что мне нужно обновить, поэтому я сделал это, чтобы воспользоваться преимуществами Metro 2.0 и jar WSIT, которые были включены в него. Затем я все еще не понимал, как именно сгенерировать заголовки WS-Security, в которых я нуждался без информации WS-Policy из файла WSDL службы. Я пытался установить CallbackHandlerFeature, используя API, предложенные LES2, но это не создавало заголовки для меня. Итак, я разместил вопрос на доске Metro / JAXB на java.net здесь:

http://forums.java.net/jive/message.jspa?messageID=392451#392451

В ответах на это один из респондентов предложил использовать NetBeans для создания фиктивного веб-сервиса и настроить параметры безопасности, которые, как мне кажется, использовались сервисом .NET. После этого NetBeans сгенерировал раздел WS-Policy в файле wsit-.xml, который я мог использовать. Я подключил этот раздел WS-Policy к своей локальной копии WSDL службы .NET, а также использовал его для создания файла wsit-client.xml, который я поместил в свой каталог WEB-INF / classes.

Как только я это сделал, Metro / WSIT начал добавлять заголовки WS-Security, чтобы запросить у меня. Затем я столкнулся с некоторыми проблемами, потому что Metro использовал другую версию WS-Addressing, чем требовала служба .NET (они используют MemberSubmissionAddressing). Итак, я настроил настройки WS-Policy для использования

<wsap:UsingAddressing                   xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" />

Теперь я нахожусь в точке, где мой SOAP-запрос выглядит следующим образом:

<S:Envelope xmlns:S="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://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:exc14n="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<S:Header>
<To xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing" wsu:Id="_5003">https://10.49.38.78/2009/12/CaseDetailsService.asmx</To>
<Action xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing" wsu:Id="_5004">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</Action>
<ReplyTo xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing" wsu:Id="_5002">
    <Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</Address>
</ReplyTo>
<MessageID xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing" wsu:Id="_5005">uuid:89a0dfdf-014c-4be7-a677-ab1b4d30cdb5</MessageID>
<wsse:Security S:mustUnderstand="1">
  <wsu:Timestamp xmlns:ns10="http://www.w3.org/2003/05/soap-envelope" 
       xmlns:ns11="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" xmlns:ns12="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" wsu:Id="_3">
       <wsu:Created>2010-03-22T19:48:04Z</wsu:Created>
       <wsu:Expires>2010-03-22T19:53:04Z</wsu:Expires> 
    </wsu:Timestamp>
    <wsse:BinarySecurityToken xmlns:ns10="http://www.w3.org/2003/05/soap-envelope" 
    xmlns:ns11="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" 
    xmlns:ns12="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" 
    wsu:Id="uuid_e861f15d-dd66-4b05-b101-c9fed7feda38" 
    EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">DATA_HERE
</wsse:BinarySecurityToken>
<xenc:EncryptedKey xmlns:ns10="http://www.w3.org/2003/05/soap-envelope" xmlns:ns11="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" xmlns:ns12="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" Id="_5007">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
<ds:KeyInfo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="KeyInfoType">
<wsse:SecurityTokenReference>
<ds:X509Data>
<ds:X509IssuerSerial>
<ds:X509IssuerName>CN=server</ds:X509IssuerName>
<ds:X509SerialNumber>-24583240032357195994117623470001087391</ds:X509SerialNumber>
</ds:X509IssuerSerial>
</ds:X509Data>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue></xenc:CipherValue>
</xenc:CipherData>
<xenc:ReferenceList>
<xenc:DataReference URI="#_5008"/>
</xenc:ReferenceList>
</xenc:EncryptedKey>
<ds:Signature xmlns:ns10="http://www.w3.org/2003/05/soap-envelope" 
xmlns:ns11="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" xmlns:ns12="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" Id="_1">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<exc14n:InclusiveNamespaces PrefixList="wsse S"/>
</ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_5002">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<exc14n:InclusiveNamespaces PrefixList="S"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>vtf9n+OcI1nT0exavD4/ZQy6jm8=</ds:DigestValue></ds:Reference>
<ds:Reference URI="#_5003">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><exc14n:InclusiveNamespaces PrefixList="S"/></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>
</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="#_5004"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<exc14n:InclusiveNamespaces PrefixList="S"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue></ds:DigestValue>
</ds:Reference>
<ds:Reference URI="#_5005"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><exc14n:InclusiveNamespaces PrefixList="S"/></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>hn2umVvzokVW6dgXUzXcG00vfq8=</ds:DigestValue>
</ds:Reference><ds:Reference URI="#_5006"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><exc14n:InclusiveNamespaces PrefixList="S"/>
</ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>MIH/94A7R2iHn/und3ElJLRTWKY=</ds:DigestValue>
</ds:Reference><ds:Reference URI="#_3"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<exc14n:InclusiveNamespaces PrefixList="wsu wsse S"/></ds:Transform></ds:Transforms>
<ds:DigestMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>olcbTjCNnXuZ5eVR1glEWRJxQpw=</ds:DigestValue>
</ds:Reference></ds:SignedInfo><ds:SignatureValue>
</ds:SignatureValue><ds:KeyInfo>
<wsse:SecurityTokenReference><wsse:Reference ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" URI="#uuid_e861f15d-dd66-4b05-b101-c9fed7feda38"/>
</wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature>
</wsse:Security>
</S:Header>

И, хотя это не совсем соответствует образцу, предоставленному мне командой .NET, я думаю, что это правильно. Тем не менее, я все еще получаю сообщение об ошибке при вызове службы .NET. Это сообщение об ошибке, которое возвращается в SOAPFault от них:

System.Web.Services.Protocols.SoapHeaderException: сервер недоступен, пожалуйста, попробуйте позже ---> System.ApplicationException: WSE841: Произошла ошибка при обработке исходящего сообщения об ошибке. ---> System.Web.Services.Protocols.SoapHeaderException: Microsoft.Web.Services3.Security.SecurityFault: не удалось аутентифицировать или авторизовать токен безопасности ---> System.Security.SecurityException: WSE3003: цепочка доверия сертификата может не проверяться Проверьте, правильно ли установлен сертификат в хранилище сертификатов доверенных лиц. Или вы можете настроить раздел конфигурации allowTestRoot на истина, если это тестовый сертификат.

Итак, в настоящее время я работаю с ними, чтобы выяснить, почему цепочка доверия сертификата не может быть проверена - мне неясно, является ли эта конкретная проблема моей или их. Любые предложения будут оценены!

...