Interoperability issue with .NET WCF service and Java client while using transaction flow and

[glassfishrobot]

Hi everyone, I have a problem invoking WCF .NET 3.5 WSHttpBinding web service method, where the binding TransactionFlow and the security bu using 509 Certificate with anonymous client is enabled but the transaction is not mandatory (only support), from a Metro 2.2.1u1 standalone client. If the TransactionFlow is disabled on the .NET web service, everything works just fine. Also, works by enabling TransactionFlow and disabling the security with 509 Certificates.

It doesn't with with both features enabled.

This is the error reported:

com.sun.xml.wss.impl.PolicyViolationException: com.sun.xml.wss.XWSSecurityException:

Encryption Policy verification error: Looking for an Encryption Element in Security header, but found
com.sun.xml.wss.impl.policy.mls.SignaturePolicy

at com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.verifyPolicy(MessagePolicyVerifier.java:151)

I don't have an application server so I'm trying to disable transactional support by passing the TransactionalFeature to the client as follow:

TransactionalFeature feature = new TransactionalFeature(false);
feature .setFlowType(TransactionFlowType.NEVER);
feature .setVersion(Version.WSAT10);
.
IService port = (IService)service.getPort(new QName(URL, BINDING), IService.class, feature);
.
I think that the problem could be the protection order (EncryptBeforeSign instead of SignBeforeEncrypt) or an issue with empty SOAP header fields because the WSDL, when transaction flow is enabled, includes this elements:

<sp:EncryptedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
sp:Body/
<sp:Header Name="CoordinationContext" Namespace="http://schemas.xmlsoap.org/ws/2004/10/wscoor"/>
<sp:Header Name="CoordinationContext" Namespace="http://docs.oasis-open.org/ws-tx/wscoor/2006/06"/>
<sp:Header Name="OleTxTransaction" Namespace="http://schemas.microsoft.com/ws/2006/02/tx/oletx"/>
<sp:Header Name="IssuedTokens" Namespace="http://schemas.xmlsoap.org/ws/2005/02/trust"/>
</sp:EncryptedParts>
.
that are not present when the transaction flow is disabled. In fact, there is no sp:EncryptedParts element.

Could anyone help me with this problem?
Does anybody know how to programmatically change the client protection order?

Affected Versions

[2.2.1]

[glassfishrobot]

Reported by jucardi

[glassfishrobot]

snajper said:
Hi Arjav, would you please look into this one?

[glassfishrobot]

@arjav-desai said:
We don't support WS-AT from a standalone client. The client must be a JavaEE client. However, we do add WS-AT related headers if the WSDL has advertisement for the same i.e. http://metro.java.net/guide/user-guide.html#using_wsat-enable_client. I think, we can try to not add those headers, if there a way to know its a standalone client. For the time being, you might want to disable WS-AT on service side.

Are you using 509 cert to secure WS-AT related messages or just the business SOAP message. Cause .NET has requirement of having two-way SSL mandatory for WS-AT i.e. http://msdn.microsoft.com/en-us/library/ms733943(v=vs.110).aspx.

[glassfishrobot]

jucardi said:
Hi Arjav, Martin.

Thank you for your quick response.

Let me try to elaborate a bit more. We are disabling WS-AT on the Java side. Check the following lines:

TransactionalFeature feature = new TransactionalFeature(false);
feature .setFlowType(TransactionFlowType.NEVER);
feature .setVersion(Version.WSAT10);

Now, that works just fine without using any security on the channel, however, if we enable security using 509 certificates, an error occurs when trying to decrypt the message because a message signature is found rather than the message (at least that's what it seems by looking at the exception description). It may be that the XML elemens arrive in an different order than expected by the metro libraries.

We are unable to disable WS-AT on the .NET service side.

[glassfishrobot]

@arjav-desai said:
What I meant by "We don't support WS-AT from a standalone client." is that you should not use TransactionalFeature on JSE client as well since the behavior will not guaranteed.

Is there a reproducer available that we can look at? If you can share your code that would be best, if not having .NET side of info would be the second best thing for us to start with.

[glassfishrobot]

jucardi said:
Arjav, I'm preparing a .NET service dummy and a Java client which will reproduce this issue so you can look at a simpler and cleaner source code than the one we are working on. I'll be posting it during the day.

Thanks again for your quick response.

[glassfishrobot]

jucardi said:
Hi Arjav, Martin.

I´m attaching a zip file with the .NET service and the Java client which are producing the error.

IMPORTANT:

1. The following metro files need to be copied in the path \DummyTest\JAVA\DummyClient\lib\metro

• webservices-tools.jar
• webservices-rl.jar
• webservices-extra-api.jar
• webservices-extra.jar
• webservices-api.jar

I had to remove them so the zip file I'm attaching would be smaller than 10Mbs.

2. If you open the file \DummyTest\dotNET\Dummy.Service\Program.cs
   There is a constant at the begining of the Program class called TRANSACTION_FLOW.
   It's a boolean variable, just switch the value to true or false depending on the test you
   would like to perform. With that costant being false, the JAVA client works perfectly.
   With the constant being true, the error mentioned in this issue is thrown.

Thank you!

[glassfishrobot]

File: DummyTest.zip
Attached By: jucardi

[glassfishrobot]

@arjav-desai said:
As I mentioned before, we don't support WSAT with standalone client. I looked at the .NET wsdl and don't see any WSAT related advertisement in WSDL so that leads me to believe there should not be a way on client side to add WSAT header while sending the business request. Can you please post the SOAP message going from java client to service in both cases i.e. when WSAT is enable and its not enabled?

Also, can you please clarify:

1. When do you see the error message when both security and WSAT are enabled on .NET side? Do you see when your Java client invokes the .NET service and .NET starts processing that business message?
2. Where do you see it i.e. .NET side or Java client side?

[glassfishrobot]

jucardi said:
Hi Arjav, I hope you had a Merry Christmas and a Happy new year, I apologize it took this long to answer, we were on vacation.

As I also mentioned before. We are not trying to use WSAT in the Java client, but we want the Java client to be able to connect to a server which supports WSAT whether it will be able to operate transactionally or not.

Once again, there are no problems connecting to the .NET server which supports WSAT if the server security is disabled. Also it is possible to connect to the .NET server if WSAT is disabled and the security is enabled. The problem lies in activating both WSAT and security on the server.

To clarify your questions:

1. Yes, it is possible to see this on the .NET service
2. On the .NET side we are able to see that a client is attempting to connect, the channel opens but after that, the exception on the Java side is thrown.

I'll post the requested SOAP messages soon. Did you try to use the sample I attached here? I just want to make sure it worked for you.

[glassfishrobot]

@arjav-desai said:
Hi jucardi,

Sorry for the delay in response but even I was on vacation until new year and got occupied with few other issues on return. Holidays were good and hope you had a nice vacation too!

I guess, I need to confirm my understanding as you are modifying the value on Java side as well as you mentioned about changing constant in Program.cs

I think in your case (or the case you want) Program.cs will always has TRANSCTION_FLOW true since .NET service has WSAT enabled and you mentioned that can't be changed, right? So basically, .NET always has security and WSAT enabled. Now, if you used 509 security on java client side and disable WSAT on that client using TransactinalFeature, we are seeing the error as mentioned in the bug, right?

Also, while filing your mentioned, "If the TransactionFlow is disabled on the .NET web service, everything works just fine. Also, works by enabling TransactionFlow and disabling the security with 509 Certificates." In the second case i.e. when you enabled TransactionFlow did you disable security on client side or service. Also, when you said, it worked, did you have TransactionFeature on client set to make WSAT false, right?

Best,
Arjav

[glassfishrobot]

jucardi said:
Hi Arjav,

Don't worry about the delay, I hope you had a good time in your holidays.

QUOTE: I think in your case (or the case you want) Program.cs will always has TRANSCTION_FLOW true since .NET service has WSAT enabled and you mentioned that can't be changed, right? So basically, .NET always has security and WSAT enabled.

• Correct, in our case, our ideal scenario would be to maintain TRANSACTION_FLOW = true, so the .NET service will always have WSAT enabled.

QUOTE: Now, if you used 509 security on java client side and disable WSAT on that client using TransactinalFeature, we are seeing the error as mentioned in the bug, right?

• Exactly, the WSAT is always disabled on the Java client. If we enable the 509 secutiry with WSAT enabled on the .NET service, the error is thrown, if we disable 509 security and keep WSAT enabled only on the .NET side, the client works perfectly.

QUOTE: In the second case i.e. when you enabled TransactionFlow did you disable security on client side or service.

• 509 disabled on both sides. The security settings must match both sides, otherwise the handshake fails.

QUOTE: Also, when you said, it worked, did you have TransactionFeature on client set to make WSAT false, right?

• Correct.

Thank you for your support.

Regards,
Jucardi

[glassfishrobot]

This issue was imported from java.net JIRA WSIT-1660