jueves, 21 de noviembre de 2013

"An invalid security token was provided..." invoking CXF Web Services

Error:  An invalid security token was provided (An error happened processing a Username Token "{0}")

Complete SOAP fault response:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <soap:Fault>
      <faultcode xmlns:ns1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">ns1:InvalidSecurityToken</faultcode>
      <faultstring>An invalid security token was provided (An error happened processing a Username Token "{0}")</faultstring>
    </soap:Fault>
  </soap:Body>
</soap:Envelope>

There are lots of  reasons which can cause this error. As stated by the message, there's a problem in the security token included in the SOAP request.

In my case, the Web service client was not sending the Type attribute for the Password element of the UsernameToken's Security element.

The error was introduced after upgrading the used CXF version (from an very old version to 2.6.1). The underlying project which implements WS Security in CXF is WSS4J. CXF 2.6.1 ships WSS4J 1.6.6. WSS4J 1.6 enforces compliance to the Basic Security Profile 1.1 (BSP) specification by default. The older CXF version shipped an older WSS4J version which did not enforce compliance to the BSP spec.

It seems the Type attribute for the password element is optional in WS-Security but mandatory in the BSP spec.

In this case we choosed not to demand the clients to include the attribute but to configure the service to not to be compliant with the BSP spec. We use Spring configuration for CXF; this can be easily done in the XML configuration file:

<jaxws:inInterceptors>
    <bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
        <constructor-arg>
            <map>
                 ...
                 <entry key="isBSPCompliant" value="false"/>  
                 ...
            </map>
        </constructor-arg>
    </bean>
</jaxws:inInterceptors&gt

This error also usually happens with the EncodingType attribute.

This conversation proposes an alternative configuration parameter: ws-security.is-bsp-compliant.

References: