WSP0075: Policy assertion "TransportBinding" was evaluated as "UNKNOWN". Why?

Question

I am a client to a SOAP service I do not control (implemented in .NET). The service provides a WSDL. I use Apache CXF to generate the java client from the WSDL (specifically, I am using the cxf-codegen-plugin for Maven, which uses wsdl2java under the hood).

However, when I instantiate the generated service class, the following warnings are logged:

Sep 04, 2014 5:18:00 PM [com.sun.xml.internal.ws.policy.EffectiveAlternativeSelector]  selectAlternatives
WARNING: WSP0075: Policy assertion "{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}TransportBinding" was evaluated as "UNKNOWN".
Sep 04, 2014 5:18:00 PM [com.sun.xml.internal.ws.policy.EffectiveAlternativeSelector]  selectAlternatives
WARNING: WSP0019: Suboptimal policy alternative selected on the client side with fitness "UNKNOWN".

However the client works correctly--I don't have any problem using the service. However, I am puzzled by these errors.

The error is about this security policy in the WSDL, which I think it says it cannot understand:

<wsp:Policy wsu:Id="soap11_policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
  <wsp:ExactlyOne>
    <wsp:All>
      <sp:TransportBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
        <wsp:Policy>
          <sp:TransportToken>
            <wsp:Policy>
              <sp:HttpsToken RequireClientCertificate="false"/>
            </wsp:Policy>
          </sp:TransportToken>
          <sp:AlgorithmSuite>
            <wsp:Policy>
              <sp:Basic256/>
            </wsp:Policy>
          </sp:AlgorithmSuite>
          <sp:Layout>
            <wsp:Policy>
              <sp:Strict/>
            </wsp:Policy>
          </sp:Layout>
        </wsp:Policy>
      </sp:TransportBinding>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

However as far as I can tell this is a perfectly ordinary policy with nothing unusual about it. Surely it should be understood? How can I fix this warning?

For the record, here is how wsdl2java is being invoked (excerpt from pom.xml).

The -exsh true arg and cxf-rt-bindings-soap dependency are because the WSDL uses some implicit soap headers in its arguments, and I need this so they are included properly in the generated service class methods.

I added the cxf-rt-ws-security and cxf-rt-ws-policy dependencies to try and fix this warning, thinking that maybe the security and policy information were not included. However, this did not fix anything (didn't break anything either, though).

<plugin>
  <groupId>org.apache.cxf</groupId>
  <artifactId>cxf-codegen-plugin</artifactId>
  <version>3.0.1</version>
  <executions>
    <execution>
      <id>rh-soap-client-ssi</id>
      <phase>generate-sources</phase>
      <configuration>
        <sourceRoot>${project.build.directory}/generated/cxf</sourceRoot>
        <wsdlOptions>
          <wsdlOption>
            <wsdl>https://example.org/ssi?wsdl</wsdl>
            <extraargs>
              <extraarg>-verbose</extraarg>
              <extraarg>-client</extraarg>
              <extraarg>-mark-generated</extraarg>
              <extraarg>-exsh</extraarg>
              <extraarg>true</extraarg>
              <extraarg>-autoNameResolution</extraarg>
            </extraargs>
          </wsdlOption>
        </wsdlOptions>
      </configuration>
      <goals>
        <goal>wsdl2java</goal>
      </goals>
    </execution>
  </executions>
  <dependencies>
    <dependency>
      <groupId>org.apache.cxf</groupId>
      <artifactId>cxf-rt-bindings-soap</artifactId>
      <version>3.0.1</version>
    </dependency>
    <dependency>
      <groupId>org.apache.cxf</groupId>
      <artifactId>cxf-rt-ws-security</artifactId>
      <version>3.0.1</version>
    </dependency>
    <dependency>
      <groupId>org.apache.cxf</groupId>
      <artifactId>cxf-rt-ws-policy</artifactId>
      <version>3.0.1</version>
    </dependency>
  </dependencies>
</plugin>

Gentlemanatarms

Answer 1

Through guesswork and looking at artifacts in maven central, I was able to hit upon a solution.

It turns out that in order to actually understand and evaluate the policy in this wsdl, a missing runtime dependency must be provided. For me it was org.apache.cxf/cxf-rt-frontend-jaxws. I could not find this documented anywhere. This pulls in a number of other cxf dependencies and I don't know if a more minimal set of them is ok.

Once I include this dependency, I no longer get a warning when I instantiate the client object. (Also, instantiation takes much longer!)

However, when I try to use the service I get an exception:

javax.xml.ws.soap.SOAPFaultException: None of the policy alternatives can be satisfied.
    at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:159)
    ...

This is most likely for the reason that Willie Wheeler's answer pointed out: the policy requires 256 bit encryption on the transport, but this service's SSL is using 128 bit encryption. However, using a wsdl with Base128 instead does not resolve this exception and I did not investigate further.

So it's quite possible that everyone who uses this service probably gets this warning or something like it, and it's impossible to use this service if the security policy is actually checked. I guess I will be living with the warning instead.

Gentlemanatarms

So, how did you end calling the service in order to get the warning instead of the exception? I am getting the message that None of the policy alternatives can be satisfied (I already have cxf-rt-frontend-jaxws dependency in my pom.xml) – Doglike

@Doglike The warning was when I did not include cxf-rt-frontend-jaxws, so that's what I do now. – Gentlemanatarms

@FrancisAvila Thanks, I am getting that warning now, however I have all CXF dependencies. But I hope I would make the service work. – Doglike

@Doglike My service works with the warning, so apparently the server side of the service I am using does not enforce its security policy either. – Gentlemanatarms

Answer 2

I can reproduce this issue with the Express-1 label service:

2014-09-10 22:15:29.601  WARN 6564 --- [           main] c.s.x.i.w.w.EffectiveAlternativeSelector : WSP0075: Policy assertion "{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}TransportBinding" was evaluated as "UNKNOWN".                                              
2014-09-10 22:15:29.602  WARN 6564 --- [           main] c.s.x.i.w.w.EffectiveAlternativeSelector : WSP0019: Suboptimal policy alternative selected on the client side with fitness "UNKNOWN".                                                                                  

I believe the problem is that the policy you inline above requires Basic256 message encryption, but the service's SSL encryption is weaker.

For example, check out this WSDL:

https://service.express1.com/Services/EwsLabelService.svc?wsdl

At the very top you will see a policy identical to the one you give. But then if you look at the site's SSL cert, it is using AES_128_CBC, which is only 128-bit encryption.

See http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf, sections 7.1, 8.1 and 8.3 for information about TransportBinding policies and algorithm suites. I believe that the warning is saying is that the policy requires 256-bit encryption, but because the service doesn't support it, the client is choosing a weaker encryption algorithm in its place.

As this is a problem on the service side, probably the best way to fix it is to notify the party responsible for the service of the issue.

Michamichael

Hm. You might try self-signing a 256-bit cert and seeing what happens. Or make sure that the 128-bit encryption you're using falls under the "Basic" classification. What is the specific 128-bit encryption alg you're using? Try using that as the alg suite policy. See section 7.1 of the spec I posted for the alg abbreviations. – Michamichael

I think you are on to something--my endpoint also has 128-bit encryption on its SSL. However when I override the WSDL to use Basic128 or remove AlgorithmSuite nothing changes. Only if I remove the entire TransportBinding section does the warning go away. Also if this were the problem I would expect UNSUPPORTED, not UNKNOWN. Could it be that somehow the policy evaluator doesn't know about the transport, so any TransportBinding section would cause an UNKNOWN warning? This again makes me think I'm missing some runtime dependency. – Gentlemanatarms

Which encryption alg are you using? (Not just the bit length, but the alg.) Is it AES or something else? – Michamichael

AES_128_CBC, same as you. But theoretically removing AlgorithmSuite from the policy should remove the warning, right? – Gentlemanatarms

Can you try "Basic128Rsa15" instead of "Basic128"? This allows SHA-1 digest and RSA 1.5 asymmetric key exchange. "Basic128" is like that, but wants RSA OAEP. – Michamichael

Found the solution: it was a missing runtime dependency. Thanks for your help though! – Gentlemanatarms

Answer 3

Finally found the correct solution:

You're missing a dependency that provides an implementation of PolicyAssertionValidator to validate a policy of the name {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}TransportBinding.

The correct dependency to use is org.glassfish.metro:wssx-impl. This library provides a class called SecurityPolicyValidator that can validate said policy. The library will work automatically just by putting it on your classpath.

This solution should work with both the JAX-WS stack and Apache CXF.

Unsparing

Answer 4

I found that these errors are being logged BEFORE the SOAP request is even sent.

The warnings did not appear in Java 6. They do appear in Java 7 and Java 8. My hunch is that these warnings are related to the legacy jaxrpc.jar in my source code.

My "hack" work-around was to download a copy of the WSDL file and modify the policy section. Then point the main class in my web-service to this modified WSDL file.

//Modified tags in my main class. Change the wsdlLocation to point to a file in my source code (instead of a URL)
@WebServiceClient(name = "Service1", targetNamespace = "https://example.org/", wsdlLocation = "WebService.wsdl")
public class Service1
...

Modified WebService.wsdl file:

<wsp:Policy wsu:Id="BasicHttpBinding_IService1_policy">
    <wsp:ExactlyOne/>
</wsp:Policy>

Primrose

This article suggests that upgrading to Apache CXF 2.2.7 will fix an issue with the TransportBinding – Primrose