从JAXWS-RI调用.NET Web服务（WSE 3.0，WS-Security）

时间：2010-03-02 20:58:20

标签： java .net jax-ws ws-security java-metro-framework

我正在编写一个JAXWS-RI客户端，它必须调用使用WS-Security的.NET Web服务。服务的WSDL不包含任何WS-Security信息，但是我有来自服务作者的示例soap消息，并且知道我必须包含wsse：Security头，包括X：509令牌。

我一直在研究，我已经看过人们从Axis和CXF（与Rampart和/或WSS4J一起）调用这种类型的Web服务的例子，但没有关于使用普通JAXWS-RI本身。但是，我（不幸）被我的gov't客户端限制使用JAXWS-RI。有没有人有任何从JAXWS-RI这样做的例子/文档？

我需要最终生成一个类似下面的SOAP标头 - 这是来自服务作者编写的.NET客户端的示例soap：标头。 （注意：我已将'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 个答案:

答案 0 :(得分：1)

尝试使用

配置端口 
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证书）

我会发布更多代码，但我没有自己的开发盒，所以我无法真正测试。

祝你好运！

答案 1 :(得分：1)

经过一段时间的努力，我们的开发团队已经确定我们无法做到这一点。我们根本无法编写一个可正确调用＆amp;的Metro（JAXWS-RI + WSIT）客户端。处理来自使用WS-Security的.NET WSE 3.0 Web服务的响应。不过，我想为那些可能会在未来尝试类似事情的人写出我们不同的方法。

回顾一下： 1.我们的第一个传递：具有MutualCerticates11安全性的WSE 3.0 Web服务（WS-Addressing，加密，签名，安全对话（ws-trust））。我们将WS-Policy片段反向设计为放置在我们的WSDL本地副本中，但是无法让WSE接受安全对话初始握手请求。

  1. 接下来，他们降级为WSE 3.0 MutualCerticates10，因为有一些关于它“更具互操作性”的喋喋不休。同样，我们无法使安全对话握手工作。

  2. 我们要求.NET团队关闭SecureConversation（WS-Trust）层（仍然存在加密和签名要求）。我们再次反向设计了WS-Policy文件（实质上，只是删除了处理WS-Trust / SC的'BootstrapPolicy'部分）。此时，我们能够向他们发送加密的签名消息，然后他们收到了消息并发回了消息。我们认为这是一次胜利，但不幸的是，WSIT因为规范化错误而对其响应消息感到窒息。在这一点上，我认为我们已经达到了WSIT的局限性，因为它并没有声称可以与WSE 3.0（只有WCF）互操作，所以我们在他们的论坛上与WSIT人员交谈并记录了他们的问题。这是link。

  3. 因此，我们得出结论，.NET团队不可能保留加密/签名层（目前，无论如何，WSIT团队可能会在某个时候修复错误）。从他们的角度来看，不幸的是，你无法关闭签名并留下加密。

  4. 我们还要求他们完全关闭他们（.NET）端的WS-Security设置，此时，他们能够发送请求＆amp;使用JAXWS-RI接收来自其服务的响应就好了。但是，他们可能无法在生产中部署这种方式。

  5. 因此，现在我们正处于.NET团队必须确定是否允许他们在WS-Security设置中运行生产中的Web服务的时刻。如果没有，那么在升级到WCF之前我们将无法连接到他们的服务。而且，事实上，这一直是我们向他们推荐的 - 他们升级到WCF - 现在我们比我们更熟悉了解原因！

答案 2 :(得分：0)

我仍然在努力解决这个问题，但我想更新一些我已经解决过的方法的细节。我意识到的第一件事是我必须从使用JAXWS-RI 2.1升级到Metro 2.0。我们之前在这个项目中使用过JAXWSRI-2.1，但我们以前从未处理过任何WS-Security。无论如何，我意识到我需要升级，所以我这样做是为了利用Metro 2.0和它附带的WSIT jar。然后，我仍然对如何生成我需要的WS-Security标头以及如何从服务的WSDL文件中获取WS-Policy信息感到困惑。我曾尝试使用LES2建议的API设置Call​​backHandlerFeature，但这并没有为我生成标题。所以，我在java.net的Metro / JAXB板上发了一个问题：

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

在对此的回复中，一位回答者建议使用NetBeans编写虚拟Web服务并设置安全设置，即使.NET服务正在使用。一旦我这样做，NetBeans在我可以使用的wsit-.xml文件中生成了一个WS-Policy部分。我将WS-Policy部分插入到.NET服务的WSDL的本地副本中，并使用它来创建我放在WEB-INF / classes目录中的wsit-client.xml文件。

一旦我这样做，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：服务器不可用，请稍后再试---＆gt; System.ApplicationException：WSE841：处理传出故障响应时发生错误。 ---＆GT; System.Web.Services.Protocols.SoapHeaderException：Microsoft.Web.Services3.Security.SecurityFault：安全令牌无法通过身份验证或授权---＆gt; System.Security.SecurityException：WSE3003：无法验证证书的信任链。请检查证书是否已在“受信任的人员证书”存储中正确安装。或者您可能希望将allowTestRoot配置部分设置为  如果这是测试证书，则为true。

所以，我正在与他们合作，弄清楚为什么证书的信任链无法验证 - 我不清楚这个问题是在我的最终还是他们的。任何建议将不胜感激！

相关问题
最新问题