从调用JAXWS-RI .NET Web服务（WSE 3.0，WS-Security的） [英] Calling a .NET web service (WSE 3.0, WS-Security) from JAXWS-RI

问题描述

我正在写一个JAXWS-RI客户端必须调用正在使用的WS-Security .NET Web服务。该服务的WSDL不包含任何WS-Security的信息，但我必须从服务的作者的例子SOAP消息，知道我必须包括的wsse：Security头，包含X：509令牌

我一直在研究，我已经看到的例子乡亲调用此类型的Web服务从Axis和CXF（与古城墙和/或WSS4J一起）的，但没有关于使用普通JAXWS-RI本身。不过，我（不幸）的限制使用JAXWS-RI我的官立客户端。有没有人有从JAXWS-RI这样做的任何实例/文档？

我需要最终生成一个SOAP头，看起来像下面这样 - 这是一个简单的肥皂：头写服务的作者.NET客户端。 （注：我已经把'VALUE_HERE串的地方，我需要提供我自己的价值观）

 ＆LT; soapenv：信封的xmlns：IRI =HTTP：// EOIR / IRIES的xmlns：soapenv =htt​​p://schemas.xmlsoap.org/soap/envelope/的xmlns：xenc =htt​​p://www.w3.org/2001/04/xmlenc#＆GT;
  ＆LT; soapenv：头的xmlns：WSA =htt​​p://www.w3.org/2005/08/addressing＆GT;
    ＆LT; WSSE：安全的xmlns：WSSE =htt​​p://docs.oasis-open.org/wss/2004/01/oasis-200401- WSS-wssecurity-secext-1.0.xsd＆GT;
     ＆所述; xenc：EncryptedKey标识=VALUE_HERE＆GT;
       ＆LT; xenc：EncryptionMethod算法=htt​​p://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p/＆GT;
       ＆LT; D​​S：密钥信息的xmlns：DS =htt​​p://www.w3.org/2000/09/xmldsig#＆GT;
          ＆LT; WSSE：SecurityTokenReference＆GT;
             ＆LT; 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
            ＆LT; / WSSE：KeyIdentifier＆GT;
         ＆LT; / WSSE：SecurityTokenReference＆GT;
       ＆LT; / DS：密钥信息＆GT;
       ＆LT; xenc：的CipherData＆GT;
          ＆LT; xenc：CipherValue＆GT; VALUE_HERE＆LT; / xenc：CipherValue＆GT;
       ＆LT; / xenc：的CipherData＆GT;
       ＆LT; xenc：ReferenceList＆GT;
         ＆LT; xenc：DataReference URI =＃EncDataId-8/＆GT;
       ＆LT; / xenc：ReferenceList＆GT;
    ＆LT; / xenc：EncryptedKey＆GT;
  ＆LT; / WSSE：安全＆GT;
 

解决方案

这方面的工作相当长一段时间之后，我们的开发团队在这里决定了我们不能这样做。我们根本无法写一个地铁（JAXWS-RI + WSIT）客户端，将正确地调用和放大器;处理来自所使用的WS-Security的.NET WSE 3.0 Web服务的响应。我想写了我们不同的方法，但是，对于那些谁可能会试图在将来这样的事情。

要回顾一下： 1.我们的第一关：与MutualCerticates11安全（WS-Addressing的，加密，签名，安全对话（WS-信任））WSE 3.0的Web服务。我们反向工程的WS-Policy片段在WSDL来喊得如此我们的本地副本的地方，但无法获得安全对话初始握手请求由WSE所接受。

1. 接下来，他们降级到WSE 3.0 MutualCerticates10，因为有一个关于它是更好的互操作性一番数落。同样，我们无法得到安全对话握手工作。

2. 我们要求.NET团队关闭安全会话（WS-信托）层（encyption和放大器;签名要求，其中仍然存在）。同样，我们反向工程的WS-Policy文件（实际上，只是删除了BootstrapPolicy部分，与WS-信托/ SC处理）。在这一点上，我们能够发送加密，签名消息给他们，他们：收到它，并发送回一个消息。我们认为这是一个胜利，但unforunately，WSIT哽咽了规范化错误的响应消息。在这一点上，我认为我们打WSIT的局限性，因为它并没有声称自己是互操作W​​SE 3.0（仅限于WCF），所以我们聊到了WSIT球员在他们的论坛和登录的问题与他们。下面是链接。

3. 所以，我们的结论是，这是不可能的。NET队离开的加密/签名层（就目前而言 - 在WSIT团队可能会解决在某一点上的bug）。从他们身边，你不能关闭只是签名和假加密，很遗憾。

4. 我们也要求他们关闭的WS-Security设置对他们（.NET）侧完全，在这一点上，是能够发送请求和放大器;接收使用JAXWS-RI就好了他们的服务响应。然而，它们未必能够部署这种方式生产

5. 所以，现在我们正处在的地步，.NET团队必须确定他们是否会被允许运行在生产中的Web服务W / O型的WS-Security的设置。如果没有，那么我们将无法连接到他们的服务，直到他们升级到WCF。而且，事实上，这一直是我们的建议对他们一直以来 - 他们升级到WCF - ！现在，我们更熟悉的不是我们想约的原因

I'm writing a JAXWS-RI client that must call a .NET Web Service that is using WS-Security. The service's WSDL does not contain any WS-Security info, but I have an example soap message from the service's authors and know that I must include wsse:Security headers, including X:509 tokens.

I've been researching, and I've seen example of folks calling this type of web service from Axis and CXF (in conjunction with Rampart and/or WSS4J), but nothing about using plain JAXWS-RI itself. However, I'm (unfortunately) constrained to using JAXWS-RI by my gov't client. Does anyone have any examples/documentation of doing this from JAXWS-RI?

I need to ultimately generate a SOAP header that looks something like the one below - this is a sample soap:header from a .NET client written by the service's authors. (Note: I've put the 'VALUE_HERE' string in places where I need to provide my own values)

<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>

解决方案

After working on this for quite a while, our team of developers here has determined that we couldn't do this. We simply could not write a Metro(JAXWS-RI+WSIT) client that would correctly call & process a response from the .NET WSE 3.0 web service that used WS-Security. I wanted to write up our different approaches, though, for those who might try something like this in the future.

To recap: 1. Our first pass: WSE 3.0 web service with MutualCerticates11 Security (WS-Addressing, encryption, signing, secure conversation (ws-trust)). We reverse engineered a WS-Policy snippet to place in our local copy of the WSDL to hande this, but could not get the secure conversation initial handshake request to be accepted by WSE.

1. Next, they downgraded to WSE 3.0 MutualCerticates10, as there is some chatter about it being 'more interoperable'. Again, we could not get the secure conversation handshake to work.

2. We asked the .NET team to turn off the SecureConversation (WS-Trust) layer (the encyption & signature requirements where still there). Again, we reverse engineered the WS-Policy file (essentially, just removed the 'BootstrapPolicy' section that deals with WS-Trust/SC). At this point, we were able to send an encrypted, signed message to them, and they recieved it and sent a message back. We thought this was a victory, but unforunately, WSIT choked on their response message with a canonicalization error. At this point, I think we hit the limitations of WSIT, as it does not claim to be interoperable with WSE 3.0 (only WCF), so we talked to the WSIT guys on their forum and logged an issue with them. Here's that link.

3. So, we concluded that it wouldn't be possible for the .NET team to leave the encryption/signature layer on (for the moment, anyway - the WSIT team may fix the bug at some point). From their side, you can't turn off just the signature and leave encryption, unfortunately.

4. We also asked them to turn off the WS-Security settings on their (.NET) side completely, and at that point, were are able to send requests & receive responses from their service using JAXWS-RI just fine. However, they may not be able to deploy this way in production.

5. So, now we are at the point where the .NET team must determine if they will be allowed to run the web service in production w/o the WS-Security settings. If not, then we will not be able to connect to their service until they upgrade to WCF. And, in fact, that has been our recommendation to them all along - that they upgrade to WCF - and now we're more familiar than we'd like to be about the reasons why!

这篇关于从调用JAXWS-RI .NET Web服务（WSE 3.0，WS-Security的）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！