+

Search Tips   |   Advanced Search

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 admin console or by using scripting to add a property.


 

Related concepts


Web Services Secure Conversation

 

Related tasks


Enable secure conversation