Вызов веб-службы.NET (WSE 3.0, WS-Security) из JAXWS-RI
Я пишу клиент 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 ответа
Поработав над этим некоторое время, наша команда разработчиков пришла к выводу, что мы не можем этого сделать. Мы просто не могли написать клиента Metro(JAXWS-RI+WSIT), который бы правильно вызывал и обрабатывал ответ от веб-службы.NET WSE 3.0, которая использовала WS-Security. Я хотел написать наши разные подходы для тех, кто может попробовать что-то подобное в будущем.
Напомним: 1. Наш первый проход: веб-сервис WSE 3.0 с MutualCerticates11 Security (WS-адресация, шифрование, подпись, безопасный разговор (ws-trust)). Мы обработали фрагмент кода WS-Policy, чтобы поместить его в нашу локальную копию WSDL, чтобы исправить это, но не смогли получить начальный запрос рукопожатия безопасного разговора, который будет принят WSE.
Затем они понизились до WSE 3.0 MutualCerticates10, поскольку существует некоторая болтовня о том, что он "более совместим". Снова, мы не могли заставить безопасное рукопожатие разговора работать.
Мы попросили команду.NET отключить уровень SecureConversation (WS-Trust) (требования к шифрованию и подписи там, где они еще есть). Опять же, мы обратили внимание на файл WS-Policy (по сути, просто удалили раздел "BootstrapPolicy", касающийся WS-Trust/SC). В этот момент мы смогли отправить им зашифрованное подписанное сообщение, и они получили его и отправили сообщение обратно. Мы думали, что это победа, но, к сожалению, WSIT подавился ответным сообщением с ошибкой канонизации. На данный момент, я думаю, мы достигли ограничений WSIT, так как он не претендует на совместимость с WSE 3.0 (только WCF), поэтому мы поговорили с парнями из WSIT на их форуме и зафиксировали с ними проблему. Вот эта ссылка.
Итак, мы пришли к выводу, что команде.NET не удастся оставить слой шифрования / подписи включенным (на данный момент, во всяком случае, команда WSIT может исправить ошибку в какой-то момент). К сожалению, вы не можете отключить только подпись и оставить шифрование.
Мы также попросили их полностью отключить настройки WS-Security на своей стороне (.NET), и в этот момент они могли отправлять запросы и получать ответы от своих служб с использованием JAXWS-RI. Однако они могут быть не в состоянии развернуть этот способ в производстве.
Итак, теперь мы находимся в точке, где команда.NET должна определить, будет ли им разрешено запускать веб-службу в рабочей среде без параметров WS-Security. Если нет, то мы не сможем подключиться к их сервису, пока они не обновятся до WCF. И, на самом деле, это была наша рекомендация для них с самого начала - чтобы они обновились до WCF - и теперь мы более знакомы, чем хотели бы знать причины этого!
Попробуйте настроить свой порт с
com.sun.xml.ws.api.security.CallbackHandlerFeature
Это использует пользовательскую реализацию
javax.security.auth.callback.CallbackHandler
который принимает
java.security.PrivateKey
а также
java.security.cert.X509Certificate
что вы загружаете из ресурса на вашем classpath. Я только что написал об этом здесь: http://upthescala.blogspot.com/2010/03/essential-sources-for-jax-ws-x509.html.
См. Com.sun.xml.ws.commons.EC2 (в исходной загрузке, указанной в записи блога, упомянутой выше), где приведен пример настройки порта (включая загрузку закрытого ключа и сертификатов X.509 из файла).
Я бы выложил больше кода, но у меня нет моей коробки разработчика, поэтому я не могу по-настоящему тестировать.
Удачи!
Я все еще работаю над некоторыми проблемами, пытаясь решить эту проблему, но я хотел бы обновить некоторые детали подхода, на котором я остановился. Первое, что я понял, это то, что мне пришлось перейти с 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
В ответах на это один из ответчиков предложил использовать 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 значение true, если это тестовый сертификат.
Итак, в настоящее время я работаю с ними, чтобы выяснить, почему цепочка доверия сертификата не может быть проверена - мне неясно, является ли эта конкретная проблема моей или их проблемой. Мы ценим любые предложения!