Network Deployment (Distributed operating systems), v8.0 > Secure applications and their environment > Secure web services > Secure web services > Administer Web Services Security > Administer message-level security for JAX-WS web services > Secure requests to the trust service using system policy sets > Enable secure conversation
Scoping of Web Services Secure Conversation
Web Services Secure Conversation supports two scoping mechanisms: the default and the Java API for XML Web Services (JAX-WS) client service level.
Review the following information about the two scoping mechanisms to ensure the proper scoping of secure conversation and policy set for WAS.
Default
The default scope is based on a cluster, an application, a module, and a target service endpoint. For a client running in a thin client environment, it is considered to be a single application, cluster, and module.
In this scoping mode, all the instances of the JAX-WS client within a particular application, cluster, and module to the same target service endpoint share the same secure conversation. For example, in the following figure, the two client instances (Client 1 and Client 2) are in the same module. Client 1 and Client 2 share the same secured conversation with Service 1. The other two client instances (Client 3 and Client 4), which are in a different module than Clients 1 and 2 and which share a secured conversation with each other but not with Clients 1 and 2.
JAX-WS client service level
Scope at the JAX-WS client service level is enabled by specifying a property in the token generator binding configuration of the Secure Conversation Token (SCT)in the client application request (application outbound). The binding is located in the META-INF of the deployed application.
For example, if the application is WSSampleClientBeta.ear and the binding directory is SecureConversation123binding, the binding file would be located at:
$PROFILE_DIR/config/cells/ <cellname>/WSSampleClientBeta.ear/deployments/WSSampleClientBeta /META-INF/SecureConversation123binding/PolicyTypes/WSSecurity/bindings.xml.
An example of the configuration follows:
<tokenGenerator name="gen_enctgen"
classname="com.ibm.ws.wssecurity.wssapi.token.impl.CommonTokenGenerator">
<valueType localName="http://schemas.xmlsoap.org/ws/2005/02/sc/sct" uri="" />
<callbackHandler classname="com.ibm.ws.wssecurity.impl.auth.callback.WSTrustCallbackHandler">
<properties name="com.ibm.ws.wssecurity.sc.SCTScope" value="SERVICE_SCOPE"/>
</callbackHandler>
<properties name="com.ibm.ws.wssecurity.sc.dkt.ServiceLabel" value="WSC"/>
<properties name="com.ibm.ws.wssecurity.sc.dkt.ClientLabel" value="WSC"/>
<jAASConfig configName="system.wss.generate.sct"/>
</tokenGenerator>
The following code example demonstrate the behavior after the property in the token generator binding configuration of the SCT in the client application request (application outbound) is enabled. In this mode, Web Services Secure Conversation is scoped at the JAX-WS client service instance.
QName serviceQname = new QName("http://ws.apache.org/axis2", "EchoService");
QName portQname = new QName("http://ws.apache.org/axis2", "EchoServicePort");
String endpointUrl = "http://myhost/......";
Service svc1 = Service.create(serviceQname);
svc1.addPort(portQname, null, endpointUrl);
Dispatch
<Source> dispatch = svc1.createDispatch(portQname, Source.class, null);
……
……
Service svc2 = Service.create(serviceQname);
svc2.addPort(portQname, null, endpointUrl);
Dispatch
<Source> dispatch = svc2.createDispatch(portQname, Source.class, null);
where svc1 and svc2 are in two different secure conversations with the target service endpoint.
We can change the scope by using either the administrative console or by using scripting to add a property.
Web Services Secure Conversation
Enable secure conversation