JBossWS 5 brings a lot of new features and improvements, mainly through the upgrades of the Apache CXF (3.0 migration guide), Apache WSS4J (2.0 migration guide) and Apache Santuario components.

Below is a quick summary of the non backward compatible changes that are likely going to impact final users.

WS-Security changes

  * the org.apache.ws.security.WSPasswordCallback class has been moved to package org.apache.wss4j.common.ext; custom implementations of CallbackHandler likely need to consider this;

  * similarly, most of the SAML bean objects from the package org.apache.ws.security.saml.ext have been moved to org.apache.wss4j.common.saml package;

  * the RSA v1.5 Key Transport algorithm is no longer allowed by default

  * the Security Token Service (STS) now validates ActAs tokens too, while it was previously validating OnBehalfOf tokens only; as a consequence, valid username/password have to be specified in the UsernameToken that's provided as ActAs token.

  * the SAML Bearer tokens are now required to have an internal signature; additionally, the org.apache.wss4j.dom.validate.SamlAssertionValidator has a setRequireBearerSignature mehod to enable/disable this signature verification.

JBoss Modules structure

  * the cxf-api and cxf-rt-core jars have been merged into cxf-core. As a consequence the org.apache.cxf module in WildFly now contains the cxf-core jar and exposes more classes then what it was doing previously

Bouncy Castle requirements & changes

  * On JBossWS 5.0.0.Beta1 / Apache CXF 3.0.1 / Apache WSS4J 2.0.1: in order for using AES encryption with GCM for symmetric encryption in XML/WS-Security, BouncyCastle 1.49, 1.51 or greater is required; alternatively, the system property "org.apache.xml.security.cipher.gcm.useIvParameterSpec" can be set to "true" to avoid issues;

  * On JBossWS 5.0.0.Beta2 and greater releases, if a BouncyCastle library is available in current classpath, that is used for getting the BouncyCastle Security Provider instance; that also means there's no need anymore for statically installing BouncyCastle in the current JVM.

Apache CXF Bus selection strategies

  * The default bus selection strategy for clients running in-container is now TCCL_BUS , instead of THREAD_BUS . No changes for clients running out of container, the default strategy is still THREAD_BUS. Users can restore the previous behavior by setting the "org.jboss.ws.cxf.jaxws-client.bus.strategy" system property to "THREAD_BUS" when booting WildFly (or, of course, by explicitly overriding the strategy when creating clients)

JAX-WS 2.2 requirements for WebServiceRef

  * As a consequence of the change above, the container needs to use the JAX-WS 2.2 style additional constructor (using WebServiceFeature) for building clients to be injected into webservice references. It is hence required that user provided Service classes injected by the container implement the latest (2.2) version of JAX-WS.

CN check

In previous JBossWS releases, the org.jboss.security.ignoreHttpsHost system property could be used to disable HTTPS URL hostname check against service's Common Name (CN) given in its certificate. That property is replaced by cxf.tls-client.disableCNCheck property in JBossWS 5.0.0.CR1 or greater.

Predefined configuration on server side and classloading

As a consequence of having enabled injections into handlers declared in predefined client and endpoint configuration, it's not possible anymore to automatically try loading handler classes from the org.jboss.as.webservices.server.integration module. As a consequence proper module dependencies might need to be specified in the deployments that are going to leverage a given predefined configuration.