The SOAP component in SwitchYard provides SOAP-based web service binding support for services and references in SwitchYard.
Composite-level services can be exposed as a SOAP-based web service using the <binding.soap> binding definition. The following configuration options are available for binding.soap when binding services:
wsdl : location of the WSDL used to describe the web service endpoint. A relative path can be used if the WSDL is included in the deployed application. If the WSDL is located outside the application, then a file: or http: URL can be used.
socketAddr : the IP Socket Address to be used. The value can be in the form hostName/ipAddress:portNumber or hostName/ipAddress or :portNumber.
wsdlPort : port name in the WSDL to use. If unspecified, the first port definition in the WSDL is used for the service endpoint
contextPath : additional context path for the SOAP endpoint. Default is none.
In AS7 by default the JBossWS-CXF stack is enabled now and hence the socketAddr parameter will be ignored. However this parameter can be used for standalone usage under JDK's JAXWS-RI.
Here's an example of what a SOAP service binding looks like:
<sca:composite name="orders" targetNamespace="urn:switchyard-quickstart-demo:orders:0.1.0">
<sca:service name="OrderService" promote="OrderService">
<soap:binding.soap>
<soap:wsdl>wsdl/OrderService.wsdl</soap:wsdl>
<soap:socketAddr>:9000</soap:socketAddr>
</soap:binding.soap>
</sca:service>
</sca:composite>
Binding a reference with SOAP can be used to make SOAP-based web services available to SwitchYard services. The following configuration options are available for binding.soap when binding references:
wsdl : location of the WSDL used to describe the web service endpoint. A relative path can be used if the WSDL is included in the deployed application. If the WSDL is located outside the application, then a file: or http: URL can be used.
wsdlPort : port name in the WSDL to use. If unspecified, the first port definition in the WSDL is used for the service endpoint.
endpointAddress : the SOAP endpoint address to override from that specified in the WSDL. Optional property, if not specified will use the one specified in the WSDL.
<sca:composite name="orders" targetNamespace="urn:switchyard-quickstart-demo:orders:0.1.0">
<sca:reference name="WarehouseService" promote="OrderComponent/WarehouseService" multiplicity="1..1">
<soap:binding.soap>
<soap:wsdl>wsdl/OrderService.wsdl</soap:wsdl>
<soap:endpointAddress>http://www.change.com/toanewendpointurl</soap:endpointAddress>
</soap:binding.soap>
</sca:reference>
</sca:composite>
To enable WS-Security within your application, a few steps are required:
Define a Policy within your WSDL, and reference with with a PolicyReference inside your binding.
Configure your <soap.binding> with a <securityAction so JBossWS-CXF knows which tokens to respect within incoming SOAP requests.
Include a WEB-INF/jboss-web.xml in your application with a <security-domain> specified, so JBossWS-CXF (who, in the case of WS-Security, is doing the JAAS login "at the front door") knows which modules to use for authentication and roles mapping.
SwitchYard provides a policy-security-wss-username Quickstart as an example. Here are the pertinent sections:
META-INF/WorkService.wsdl
<binding name="WorkServiceBinding" type="tns:WorkService">
<wsp:PolicyReference URI="#WorkServicePolicy"/>
...
</binding>
<wsp:Policy wsu:Id="WorkServicePolicy">
<wsp:ExactlyOne>
<wsp:All>
<sp:SupportingTokens xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken10/>
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SupportingTokens>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
META-INF/switchyard.xml
<binding.soap xmlns="urn:switchyard-component-soap:config:1.0">
<wsdl>META-INF/WorkService.wsdl</wsdl>
<contextPath>policy-security-wss-username</contextPath>
<securityAction>UsernameToken</securityAction>
</binding.soap>
WEB-INF/jboss-web.xml
<jboss-web>
<security-domain>java:/jaas/other</security-domain>
</jboss-web>
With the above pieces in place, JBossWS-CXF will intercept incoming SOAP requests, extract the UsernameToken, attempt to authenticate it against the LoginModule(s) configured in the application server's "other" security domain, and provide any authorized roles. If successful, the request will be handed over to SwitchYard, who can do further processing, including enforcing our own policies. In the case of WS-Security, SwitchYard will not attempt a second clientAuthentication, but instead will respect the outcome from JBossWS-CXF. Note that if the original clientAuthentication fails, it is a "fail-fast" scenario, and the request will not be channeled into SwitchYard.
In the current release, support for WS-Security Signature and Encryption requires additional, manual steps. The next release will streamline the process significantly.
The Policy in your WSDL needs to reflect the added requirements. An example of this can be found in the JBossWS documentation here: Signature and Encryption.
Manual addition of a CXF InInterceptor which sets certain CXF security properties is currently required.
Accomplishing that last point can be done like this:
META-INF/switchyard.xml
<binding.soap xmlns="urn:switchyard-component-soap:config:1.0">
<wsdl>META-INF/WorkService.wsdl</wsdl>
<contextPath>policy-security-wss-username</contextPath>
<inInterceptors>
<interceptor class="com.example.MyInterceptor"/>
</inInterceptors>
</binding.soap>
com/example/MyInterceptor.java
public class MyInterceptor extends WSS4JInterceptor {
private static final PROPS;
static {
Map<String,String> props = new HashMap<String,String>();
props.put("action", "Signature Encryption");
props.put("signaturePropFile", "META-INF/bob.properties");
props.put("decryptionPropFile", "META-INF/bob.properties");
props.put("passwordCallbackClass", "com.example.MyCallbackHandler");
PROPS = props;
}
public MyInterceptor() {
super(PROPS);
}
}
META-INF/bob.properties
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password=password org.apache.ws.security.crypto.merlin.keystore.alias=bob org.apache.ws.security.crypto.merlin.file=META-INF/bob.jks