incubator-stonehenge-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Dewey <Ben.De...@26ny.com>
Subject RE: Interoperability Failure: SslContextToken & WS-Policy
Date Thu, 21 May 2009 14:39:29 GMT
Ming,

There is one WSDL for the .NET OPS.  It is located at http://localhost:8000/tradeorderprocessor?wsdl.
 That wsdl should contain a binding for WSHttpBinding_OrderProcessorService which used by
the service port of http://localhost:8000/tradeorderprocessor/msec


<wsdl:port name="WSHttpBinding_OrderProcessorService" binding="tns:WSHttpBinding_OrderProcessorService">
  <soap12:address location="http://stonehenge:8000/tradeorderprocessor/msec" /> 
 <wsa10:EndpointReference>
 <wsa10:Address>http://stonehenge:8000/tradeorderprocessor/msec</wsa10:Address>

 <Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
 <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
 <X509Data>
<X509Certificate>MIIB8DCCAVmgAwIBAgIQ1ELWkagtIaZA+rGlQ0DB/DANBgkqhkiG9w0BAQQFADASMRAwDgYDVQQDEwdPUFMuQ29tMB4XDTA4MDUyMTA0NDUwMVoXDTM5MTIzMTIzNTk1OVowEjEQMA4GA1UEAxMHT1BTLkNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxwk9moHNb3pwAFdolsVrNRCypa9MAH9NOblGJRW6av93sC5oubfjbzfIgURycVgOYoI/6G3AZijENC//tR8CiNuwfc338j4gGJCYQMKF80f0v+wsOChbWA/jSMmW0XeZ2mtn28kUzZwBN+auK+iUurYmUfZlNCIzLrM49KKqLRMCAwEAAaNHMEUwQwYDVR0BBDwwOoAQGGhusN6c4j/7WSnvieRMbKEUMBIxEDAOBgNVBAMTB09QUy5Db22CENRC1pGoLSGmQPqxpUNAwfwwDQYJKoZIhvcNAQEEBQADgYEAZ8xVxioCvG8t8iCx5Xy7JgUyGVnTgxVhP3+uMGSca0u1wqnfoPethXkykPkCP5ZEYSS5SoBLdCKhn1HqICdTBkR2m0ebo50CoXT1lAy+5MELdzlR8SH9KV6nokwCPAW3RURk1huaDi3FO1oFDVm6146rAByZrG/PjDe3w+MUaHg=</X509Certificate>

  </X509Data>
  </KeyInfo>
  </Identity>
  </wsa10:EndpointReference>
  </wsdl:port>


Is there a way to specify a wsdl that is different from http://localhost:8000/tradeorderprocessor/msec?wsdl.


-----Original Message-----
From: Ming Jin [mailto:skyairmj@gmail.com] 
Sent: Thursday, May 21, 2009 10:24 AM
To: stonehenge-dev@incubator.apache.org
Subject: Re: Interoperability Failure: SslContextToken & WS-Policy

we tried the http://localhost:8000/TradeOrderProcessor/msec, as

OrderProcessor processor = new OrderProcessor(new URL("
http://localhost:8000/tradeorderprocessor/msec<http://localhost:8000/tradeorderprocessor>"),
new QName("http://tempuri.org/",
"OrderProcessor"));

but we got another error:

java.io.IOException: Server returned HTTP response code: 400 for URL:
http://stocktrader:8000/tradeorderprocessor/msec
java.io.IOException: Server returned HTTP response code: 400 for URL:
http://stocktrader:8000/tradeorderprocessor/msec?wsdl

that's why let us still keep the basicHttpBinding URL. :(

We'll try the customBinding tomorrow.



On Thu, May 21, 2009 at 10:16 PM, Ben Dewey <Ben.Dewey@26ny.com> wrote:

> Ming,
>
> Two things,
>
> 1.  Can you verify that you're using the
> http://localhost:8000/TradeOrderProcessor/msec endpoint address when
> calling wsHttp?  It seems like the code is still setup for the basicBinding
> endpoint.
>
> 2.  Were you able to get the customBinding for .NET working.  PHP and WSAS
> are using the customBinding OPS_SEC.  the endpoint is
> http://localhost:8000/tradeorderprocessor/sec (without the m). This might
> be a better option, There has been talks of removing the wsHttpBinding and
> replacing it with the customBinding throughout.
>
> -Ben
>
> -----Original Message-----
> From: Ming Jin [mailto:skyairmj@gmail.com]
> Sent: Thursday, May 21, 2009 10:07 AM
> To: stonehenge-dev@incubator.apache.org
> Cc: Kent Brown; Harold Carr; ted@tedneward.com; Ye Zheng;
> mli@thoughtworks.com; Ming Jin; yai@thoughtworks.com;
> ynjia@thoughtworks.com; Song Zhang
> Subject: Interoperability Failure: SslContextToken & WS-Policy
>
> Hi, we're configuring stonehenge to use Java WSIT client to connect the
> .NET
> orderprocessor service via wsHttpBinding.
>
> We followed the installation document under the .net directory from
> stonehenge m1 branch, and we got order processor service running via both
> basicHttpBinding and wsHttpBinding.
>
> At first, we tried the interoperability via basicHttpBinding, the result
> was
> perfect.
>
> Then we wanted to configure it to via wsHttpBinding, but we encountered the
> following problem:
> --------------
> May 21, 2009 8:21:21 PM com.sun.xml.ws.security.impl.policy.Constants
> log_invalid_assertion
> WARNING: SP0100: Policy assertion
>
> Assertion[com.sun.xml.ws.policy.sourcemodel.DefaultPolicyAssertionCreator$DefaultPolicyAssertion]
> {
>    assertion data {
>        namespace = 'http://schemas.microsoft.com/ws/2005/07/securitypolicy
> '
>        prefix = 'mssp'
>        local name = 'SslContextToken'
>        value = 'null'
>        optional = 'false'
>        ignorable = 'false'
>        attributes {
>            name = '
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy:IncludeToken', value
> =
> '
>
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient
> '
>        }
>    }
>    no parameters
>    nested policy {
>        namespace version = 'v1_5'
>        id = 'null'
>        name = 'null'
>        vocabulary {
>            1. entry = '
>
> http://schemas.microsoft.com/ws/2005/07/securitypolicy:RequireClientCertificate
> '
>            2. entry = '
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy:RequireDerivedKeys'
>        }
>        assertion set {
>
>
> Assertion[com.sun.xml.ws.policy.sourcemodel.DefaultPolicyAssertionCreator$DefaultPolicyAssertion]
> {
>                assertion data {
>                    namespace = '
> http://schemas.microsoft.com/ws/2005/07/securitypolicy'
>                    prefix = 'mssp'
>                    local name = 'RequireClientCertificate'
>                    value = 'null'
>                    optional = 'false'
>                    ignorable = 'false'
>                    no attributes
>                }
>                no parameters
>                no nested policy
>            }
>
>
> Assertion[com.sun.xml.ws.policy.sourcemodel.DefaultPolicyAssertionCreator$DefaultPolicyAssertion]
> {
>                assertion data {
>                    namespace = '
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy'
>                    prefix = 'sp'
>                    local name = 'RequireDerivedKeys'
>                    value = 'null'
>                    optional = 'false'
>                    ignorable = 'false'
>                    no attributes
>                }
>                no parameters
>                no nested policy
>            }
>        }
>    }
> } is not supported under Token assertion.
> Exception in thread "main" java.lang.NullPointerException
>    at
>
> com.sun.xml.ws.security.impl.policy.PolicyUtil.isSecurityPolicyNS(PolicyUtil.java:70)
>    at
>
> com.sun.xml.ws.security.impl.policy.PolicyUtil.isIssuedToken(PolicyUtil.java:644)
>    at
>
> com.sun.xml.ws.security.impl.policyconv.SCTokenWrapper.addToken(SCTokenWrapper.java:222)
>    at
>
> com.sun.xml.ws.security.impl.policyconv.SCTokenWrapper.getTokens(SCTokenWrapper.java:205)
>    at
>
> com.sun.xml.ws.security.impl.policyconv.SCTokenWrapper.getIssuedTokens(SCTokenWrapper.java:169)
>    at
>
> com.sun.xml.wss.jaxws.impl.SecurityTubeBase.getIssuedTokenPoliciesFromBootstrapPolicy(SecurityTubeBase.java:458)
>    at
>
> com.sun.xml.wss.jaxws.impl.SecurityTubeBase.constructPolicyHolder(SecurityTubeBase.java:1332)
>    at
>
> com.sun.xml.wss.jaxws.impl.SecurityClientTube.addIncomingProtocolPolicy(SecurityClientTube.java:599)
>    at
>
> com.sun.xml.wss.jaxws.impl.SecurityTubeBase.buildProtocolPolicy(SecurityTubeBase.java:1258)
>    at
>
> com.sun.xml.wss.jaxws.impl.SecurityTubeBase.collectPolicies(SecurityTubeBase.java:752)
>    at
>
> com.sun.xml.wss.jaxws.impl.SecurityTubeBase.<init>(SecurityTubeBase.java:284)
>    at
>
> com.sun.xml.wss.jaxws.impl.SecurityClientTube.<init>(SecurityClientTube.java:131)
>    at
>
> com.sun.xml.wss.provider.wsit.SecurityTubeAppender.appendTube(SecurityTubeAppender.java:189)
>    at
>
> com.sun.xml.ws.assembler.TubelineAssemblerFactoryImpl$WsitTubelineAssembler.createClient(TubelineAssemblerFactoryImpl.java:79)
>    at
>
> com.sun.xml.ws.client.WSServiceDelegate.createPipeline(WSServiceDelegate.java:446)
>    at
>
> com.sun.xml.ws.client.WSServiceDelegate.createEndpointIFBaseProxy(WSServiceDelegate.java:639)
>    at
> com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:342)
>    at
> com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:324)
>    at
> com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:306)
>    at javax.xml.ws.Service.getPort(Service.java:92)
>    at
>
> org.tempuri.OrderProcessor.getWSHttpBindingOrderProcessorService(OrderProcessor.java:78)
>    at
>
> org.wso2.stocktrader.services.TradeOrderServiceClient.SubmitOrderTrasactedQueue(Unknown
> Source)
>    at org.wso2.stocktrader.services.TradeOrderServiceClient.main(Unknown
> Source)
>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>    at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>    at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>    at java.lang.reflect.Method.invoke(Method.java:597)
>    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
>
> Process finished with exit code 1
> --------------
>
> After some digging by google, we found this article with the solution:
> Interoperability Gotcha: SslContextToken Negotiation & WS-Policy (
>
> http://proxy88.com/index.php?hl=f5&q=uggc%3A%2F%2Fjrofreivprf20.oybtfcbg.pbz%2F2008%2F10%2Fvagrebcrenovyvgl-tbgpun-ffypbagrkggbxra.ugzy
> )
>
> There the author provided a solution, we can turn the X.509 negotiation off
> by updating wshttpbinding configuration like bellow
> <security>
>   <message clientCredentialType="None" negotiateServiceCredential="false"
> />
> </security>
>
> So, we updated the relevant configuration in
> Trade.BusinessServiceConsole.exe.config as bellow:
>
> <binding name="OpsClient_WsHttpBinding_MSec" closeTimeout="00:01:00"
> openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
> bypassProxyOnLocal="false" transactionFlow="false"
> hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="524288"
> maxReceivedMessageSize="65536" messageEncoding="Text" textEncoding="utf-8"
> useDefaultWebProxy="true" allowCookies="false">
>          <readerQuotas maxDepth="32" maxStringContentLength="8192"
> maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384"
> />
>          <reliableSession ordered="true" inactivityTimeout="00:10:00"
> enabled="false" />
>          <security mode="Message">
>            <!--<transport clientCredentialType="Windows"
> proxyCredentialType="None" realm="" />--><!--here we comment it out-->
>            <!--<message clientCredentialType="Certificate"
> negotiateServiceCredential="true" algorithmSuite="Default"
> establishSecurityContext="true" />--><!--here we comment it out-->
>            <message clientCredentialType="None"
> negotiateServiceCredential="false"/>
>          </security>
>        </binding>
>
> However, the error message as former still occured.
>
> Here is our java client code:
>
>        OrderProcessor processor = new OrderProcessor(new URL("
> http://localhost:8000/tradeorderprocessor"), new QName("
> http://tempuri.org/",
> "OrderProcessor"));
>        //OrderProcessor class is generated by wsimport from
> http://localhost:8000/tradeorderprocessor?wsdl
>        OrderProcessorService service =
> processor.getWSHttpBindingOrderProcessorService();
>        SubmitOrder param = new SubmitOrder();
>        param.setOrder(order);
>        service.submitOrder(param);
>
> We've imported the certificate of CN OPS.Com into the keystore.jks for the
> glassfish, and imported the certificate of alias 's1as' from glassfish into
> mmc.
>
> We tried to find some examples about using WSIT to inter-operate the java
> client and .net service provider via wsHttpBinding, but there are so few
> materials or examples.
>
> Does anyone have any suggestion? Where can we find the examples that
> represent the interoperability via wsHttpBinding?
>
>
>
> ----
> Ming Jin
>
> Consultant
> Thoughtworks, Inc
>



-- 
Ming Jin

Consultant
Thoughtworks, Inc
Mobile: +86 135-2125-6300
Email: skyairmj@gmail.com
MSN: skyairmj@hotmail.com
Blog:  http://blogjava.net/mingj
Mime
View raw message