Вызов веб-службы .NET (WSE 3.0, WS-Security) из JAXWS-RI

Question

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

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

Мне нужно в конечном итоге создать заголовок 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> 

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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 из файла).

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

Удачи вам!

Answer 3

Я все еще работаю над некоторыми проблемами, пытаясь решить эту проблему, но я хотел уточнить некоторые детали подхода, на котором я остановился. Первое, что я понял, это то, что мне пришлось перейти с JAXWS-RI 2.1 на Metro 2.0. Ранее мы использовали JAXWSRI-2.1 в этом проекте, но нам никогда не приходилось сталкиваться с какой-либо WS-Security. Во всяком случае, я понял, что мне нужно обновиться, поэтому я сделал это, чтобы воспользоваться Metro 2.0 и банками 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-политики для использования

<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 значение true, если это тестовый сертификат.

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