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 WebSphere® Application Server.

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.

Application A contains Clients 1 and 2, Application B contains Clients 3 and 4, and Service 1, with secured conversation lines between each client to Service1.

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.

You can change the scope by using either the administrative console or by using scripting to add a property.




Related concepts
Web Services Secure Conversation
Related tasks
Enabling secure conversation
Concept topic Concept topic    

Terms of Use | Feedback

Last updatedLast updated: Sep 19, 2011 6:15:55 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=matt&product=was-express-dist&topic=cwbs_wsscscoping
File name: cwbs_wsscscoping.html