OK, so with the actual issue here being the ElytronSecurityDomainContextImpl not propagating the subject to the EJB layer (which is tracked by WFLY-10480), this jira is now only about providing a generic JBossWS CXF interceptor that does what the user is doing in his application (relying on JBossWS-SPI). As such, this jira is not critical anymore and can be moved to next release (I'd like to think about other possible usecases too before adding such an interceptor to JBossWS).
The actual fix in WFLY-10480 is already included in a PR and the jira is blocking for next WildFly release.

So, rhn-engineering-ema has been trying the application here, manually set up the elytron security domain adding the following to the CLI script:

 /subsystem=undertow/application-security-domain=ApplicationDomain:add(http-authentication-factory=application-http-authentication)
 /subsystem=ejb3/application-security-domain=ApplicationDomain:add(security-domain=ApplicationDomain)

but eventually figured out a roadblock which is now filed under https://issues.jboss.org/browse/WFLY-10480 .

Ops, sorry, well the code is pretty much the same as https://github.com/wildfly/wildfly/blob/11.0.0.Final/webservices/server-integration/src/main/java/org/jboss/as/webservices/service/EndpointService.java#L125

Thank you for looking into this. Unfortunately, I cannot open the link, since I don't have access to the jboss-eap7 repository.

Btw, here is basically where the webservices subsystem check the type of security domain it's been passed: https://github.com/jbossas/jboss-eap7/blob/EAP_7.1.0.CR4-dev/webservices/server-integration/src/main/java/org/jboss/as/webservices/service/EndpointService.java#L125

jan.krause1, I've just tried your application. The webservices subsystem is using the security domain that the application is specifying in its jboss-web.xml, which is the one named "other". AFAICS in the standalone.xml patched using the provided CLI script, the "other" domain is not an Elytron domain. I believe there's something to be fixed in the standalone.xml configuration, I'll have a colleague of mine (with more experience than me on Elytron) follow up on this.

rhn-support-asoldano, thank you for the quick reply. As we observed, there seems to be another problem while propagating the created identity to a remote server.
We try to transfer the created principal from the webservices subsystem to the ejb subsystem via a security domain provided by the Elytron subsystem. But instead of using the Elytron security domain, it seems that a legacy security domain is used in the webservices subsystem. In conclusion there is no known possibility for us to place the created principal in the ejb subsystem. Elytron is mandatory, as we need to be able to transfer the identity to a remote EAP without any applicationside changes.

We have to find a solution for this second problem to fulfill our own requirements.

jan.krause1, thanks, I was actually going to propose a solution exactly they way you've implemented in the attached archive. Basically, JBossWS exposes the SPI for programmatically pushing the subject context to the container, so you can add a CXF interceptors in your application and perform that.
Clearly, no check is performed on credentials, the subject is directly set.

We developed a custom WSS4JInInterceptor, that creates a principal that is also visible in the EJB context. Please have a look at the attached "redhat-saml-interceptor.zip", especially at the updated CLI and README files.