We currently expect users deploying a WS-Trust STS endpoint to set a dependency to org.apache.cxf.impl module, to gain visibility on the org.apache.cxf.ws.security.sts.provider.SecurityTokenServiceProvider class as well as misc utility classes from cxf-services-sts-core.jar.
This has the side effect of exposing impl details of the whole Apache CXF to the deployment, as well as generating a warning in the logs as that module is private.
Moreover, should JAX-RS annotations be added to any of the jars we have in the cxf module, the STS deployment would fail due to the way jaxrs subsystem works on WildFly.

We should hence set a dependency to an independent module which should filter the exported classes (at least we should only expose the contents of the cxf-services-sts-core and cxf-rt-ws-security jars).

Update from Alessio on JBWS-3981:
I've added a new org.jboss.ws.cxf.sts module to be used for STS deployment dependencies. Now, I could not simply export a filtered set of packages from org.apache.cxf.impl in there, basically because WFCORE-1372. So, I've split cxf-rt-ws-security.jar and cxf-services-sts-core.jar into separate cxf sub-modules and re-exported them in org.jboss.ws.cxf.sts. This way the cxf submodules act as filters and the org.jboss.ws.cxf.sts module do not need to filter anything and hence avoid the bug.

Update from Jason:
I would make this a blocker as it is an API visibility problem.

Proposed solution:
Create SP release of JBossWS on top of jbossws-cxf-5.1.3.Final + include https://github.com/jbossws/jbossws-cxf/commit/c868fe3c49be983c5955b54ceadf42d7d1c33b9a