Enforcing SOA message security policy with WebSphere Service Registry and Repository and WebSphere DataPower

Integrating WebSphere Service Registry and Repository and WebSphere DataPower

This tutorial presents the reader with a concrete method for using a central repository in this example WebSphere Service Registry and Repository (WSRR) to implement business policies governing SOA message flows, enforced by the WebSphere DataPower SOA appliances. The necessary configuraton steps for both the WSRR and the WebSphere DataPower appliance are detailed.

Share:

David Shute, WebSphere DataPower Enablement Program Manager, IBM

A member of the DataPower team at time of acquisition, David Shute has been working with DataPower technologies for six years.



21 December 2011

Also available in Chinese Japanese

Overview

Modern business-to-business communications have evolved and increased in size and complexity to the point where the management and governance of enterprise message flows presents a critical and difficult challenge. These message flows represent significant revenue streams and so must be handled carefully, using robust tools. Nonetheless, policies must be put in place to protect critical assets and preserve standard business practices.

Many enterprises look for scalable methods to establish and enforce business-oriented policies that govern their SOA-oriented communication systems. The Web Services Policy standards and mechanisms are designed to meet these needs.

WebSphere offers two products that together can deliver the ability to set and enforce business policies using the WS-Policy standards: WebSphere Registry and Repository and WebSphere DataPower SOA Appliances.

This tutorial demonstrates how to use these two products together to implement the following business policy:

  • All requests bound for a given enterprise application must be signed.
  • All responses returned by the enterprise application must be encrypted.

Here is an illustration of the architecture of the solution presented in this tutorial.

Figure 1. Figure 1. Solution architecture
Solution architecture

The business manager can set business policies within the Registry. The DataPower devices, in turn, obtain the necessary configuration information to enforce the policies in live message flows.

Configure the registry

This tutorial demonstrates the use of automatic updates to the DataPower device configuration using features made available in the WSRR version 7.5 release. The configuration steps for the Registry are the same for WSRR versions 6.2 and later.

Begin implementing this policy enforcement architecture by configuring the Registry. Configuration of the registry consists of the following three basic steps:

  • Upload the WSDL describing the enterprise service to be externalized
  • Upload the files describing the policies to implemented
  • Create a Saved Search within the registry that returns the WSDL

Upload the WSDL

To upload the WSDL describing the back end enterprise service, log into the WSRR console. Follow these steps:

  1. Click on Load Documents.
Figure 2. Figure 2. Load documents
Load documents
  1. Load the Echo.wsdl file from your local filesystem.
Figure 3. Figure 3. Loading files path
Load files
  1. Click WSDL Documents in the Service Documents area to verify the the new WSDL file is available. Note that the Registry identifies files by both the filename (Echo.wsdl) and the namespace (http://ibm.com/was/wssample/sei/echo/).
Figure 4. Figure 4. WSDL listing
WSDL listing

Upload the Policy files

Now that the basic WSDL is in place and available for any DataPower device to access, it is time to upload the policy files that describe the business policies to enforce. Here is the content of the wsp-sp-1-1-sign-parts.xml policy file.

Listing 1. wsp-sp-1-1-sign-parts.xml policy file
<?xml version='1.0' encoding='UTF-8'?>


<wsp:Policy 
   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
   xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512"
   xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
        oasis-200401-wss-wssecurity-utility-1.0.xsd"
   wsu:Id="wsp-sp-1-1-sign-parts">

  <dpe:summary xmlns="" xmlns:dpe="http://www.datapower.com/extensions">
    <dppolicy:domain xmlns:dppolicy="http://www.datapower.com/policy">
      http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512
    </dppolicy:domain>
    <description>
      Implements WS Security Policy 1.1 - support SignedParts
    </description>
  </dpe:summary>

  <wsp:ExactlyOne>
    <wsp:All>
      <sp:SignedParts>
        <sp:Body/>
      </sp:SignedParts>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

In this case, the file expresses the policy that the body part of all SOAP messages must be signed. Note that this makes no distinction between request messages or response messages. This file can be obtained from the store:/// directory of a DataPower device. Note that you can copy these files to a local:/// directory and modify them as needed.

This file is uploaded to the Registry through the following steps.

  1. Click on Load Documents at the top of the page.
  2. Identify the location of the policy file on your local filesystem.
  3. Select Policy from the Document Type dropdown list.
  4. Click OK. The following panel appears.
Figure 5. Figure 5. Documents to load listing
Documents to load listing
  1. Click Finish. You will see confirmation that the upload succeeded.

Next, the file expressing the policy regarding encryption must be uploaded to the Registry. The steps are very similar to the previous upload.

  1. Click on Load Documents at the top of the page.
  2. Identify the location of the policy file on your local filesystem.
  3. Select Policy from the Document Type dropdown list.
  4. Click OK. The following panel appears.
Figure 6. Figure 6. Documents to load listing
Documents to load listing
  1. Click Finish.

Now that the basic policy expressions are in place, the file describing how to tie the policy to the WSDL must be uploaded to the device.

Note that the WSDL file is identified not by filename (Echo.wsdl) but by namespace (http://ibm.com/was/wssample/sei/echo/). If there is more than one WSDL file loaded in the Registry with this target namespace, it is possible the policy will be attached to a different WSDL file than the one you are expecting to use.

Note that the Policy Reference refers to the wsu:Id assigned to the Policy in the file ("wsp-sp-1-1-encrypted-parts-body") and not to the file containing that ID.

The following figure illustrates how the Policy Attachment file connects the WSDL and the basic policy expression.

Figure 7. Figure 7. Connection between WSDL file and the basic policy expression
Connection between WSDL file and the basic policy expression

Upload the Policy Attachment file in the same way you uploaded the other policy files.

  1. Click on Load Documents at the top of the page.
  2. Identify the location of the policy file on your local filesystem.
  3. Select Policy from the Document Type dropdown list.
  4. Click OK. The following panel appears.
Figure 8. Figure 8. Policy Attachment file
Policy Attachment file
  1. Click Finish. You will see confirmation that the upload succeeded.

The enterprise business policy states that all requests must be signed and all responses must be encrypted. Our Policy Attachment file expresses only one of the two conditions. The Attachment file just uploaded only handles the signed requests; an additional Policy Attachment file is needed for encrypted responses.

Follow the same procedure as used previously.

  1. Click on Load Documents at the top of the page.
  2. Identify the location of the policy file on your local filesystem.
  3. Select Policy from the Document Type dropdown list.
  4. Click OK. The following panel appears.
Figure 9. Figure 9. Policy Attachment file
Policy Attachment file
  1. Click Finish. You will see confirmation that the upload succeeded.

This completes the upload of all the needed policy files. By listing out the available Policy documents, you can verify that both Policy Attachment files are now available in the Registry.

Figure 10. Figure 10. Policy document listing of attachments
Policy document listing of attachments

To confirm that WSRR has correctly parsed and applied the policies to the WSDL file, open the WSDL file within the Registry. To do this, return to the Home screen and display WSDL documents. This will display the following screen:

Figure 11. Figure 11. Details of WSDL file
Details of WSDL file

Click the Policy tab. The following screen appears.

Figure 12. Figure 12. Policy contents
Policy contents

Note the Policy expressions under the echoOperationRequest and echoOperationResponse messages. This verifies that the Registry has correctly parsed and applied the policy statements to the WSDL. This is what the DataPower device will receive when the device obtains this WSDL from the Registry.

Create a Saved Search

To create a saved search in the Registry, it is necessary to first create a query (or search) within the Registry.

Here are the steps to create the Saved Search.

  1. Return to the Home screen. Click the arrow next to the Queries entry on the left hand menu.
Figure 13. Figure 13. Queries entry
Queries entry
  1. Click the link to launch the Query Wizard.
  2. Select WSDL Documents from the dropdown. Your screen should resemble the following:
Figure 14. Figure 14. WSDL documents
WSDL documents
  1. Click Next.
  2. Specify the name of the WSDL in the Name field presented on the query details page, as shown below.
Figure 15. Figure 15. WSDL name
WSDL name
  1. Click Next.
  2. A summary of the query details then appears, as shown here.
Figure 16. Figure 16. WSDL query details
WSDL query details
  1. Click Finish. This causes the query to execute and return results. This query returns just the WSDL desired.
Figure 17. Figure 17. Save query
Save query
  1. Enter a name (such as GetEchoWSDL) for this search under Save this Search. This name will be used to configure the DataPower subscription object.
  2. Click Save.

This completes the configuration of the Registry.

Configure the WebSphere DataPower device

A Web Service Proxy service on the DataPower device can obtain its configuration information from a WSRR Saved Search, such as the one just configured above. As of DataPower firmware version 4.0.1.0 and WSRR Version 7.5, the DataPower device can also automatically update this information when the WSDL saved in the Registry is updated. This feature allows the device to be updated immediately, rather than waiting for a poll interval (which could be as long as days) to elapse. This section will detail the steps needed to configure a Web Service Proxy to use the Automatic Update feature along with a Saved Search Subscription.

To enable the automatic update feature, it is first necessary to adjust the configuration of the XML Management Interface of the device. To do this, first switch to the default domain of the device and follow these steps.

  1. Select Network > Management > XML Management Interface from the navigation menu.
  2. Check the WSRR Subscription box, as shown here. Note that this box will not appear if you are not using firmware 4.0.1.0.
Figure 18. Figure 18. WSRR subscription options
WSRR subscription options
  1. Click Apply.

Now return to the application domain you will use to build services (typically not the default domain).

Begin configuring the service by clicking the Web Service Proxy icon on the Control Panel.

  1. Click the Add button beneath the list of any existing Web Service Proxy objects. The first page of the Web Service Proxy configuration process displays.
  2. Enter the name of the new proxy in the field provided.
  3. Click Create Web Service Proxy. The WSDL configuration page of the Proxy appears.
Figure 19. Figure 19. Create Web Service Proxy
Create Web Service Proxy
  1. Click WSRR Saved Search Subscription.

A set of blank fields appear as shown in the following illustration.

Figure 20. Figure 20. WSRR Server
WSRR Server
  1. Enter Echo in the New field. This is the name of the Subscription object.
  2. Click the + button under WSRR Server. A new window opens to display the form to create a new WSRR Server object.
  3. Configure the WSRR Server object as shown in the following illustration.
Figure 21. Figure 21. WSRR Server object
WSRR Server object

Note that the correct values for the SOAP URL, Username and Password will vary depending upon your circumstances. The WSRR Server Version must be 7.5 or later to support automatic updates (rather than polling). This version must be 6.2 or higher to support saved search subscriptions.

  1. Click Find a Saved Search. This causes the device to contact the Registry and obtain a list of all Saved Searches available.
Figure 22. Figure 22. Find a Saved Search
Find a Saved Search
  1. Select GetEchoWSDL from the list and click Apply.
  2. Select Automatic (WSRR 7.5 or later) from the Synchronization Method dropdown list. When the WSDL stored on the WSRR server changes, the Registry will automatically notify the DataPower device that a newer version is available and the DataPower device will obtain it from the Registry, potentially changing the services offered by the Proxy. Note that the use of this option also requires a modification to the configuration of the XML Management Interface of the device, covered previously.
  3. Click the + button under WS-Policy Parameter Set. Because this Proxy is set to Enforce the policy contained in the WSDL (note the WS-Policy Enforcement Mode), the Proxy will need various sets of keys and credentials to verify the signatures contained in requests and also to encrypt response messages if they are not already encrypted.
  4. Configure the Parameter Set as shown.
Figure 23. Figure 23. Parameter Set
Parameter Set

Note that the Parameter Name and Parameter Value are the same for all three entries; only the Policy Domain changes. While it is possible to use only one Policy Domain entry to achieve the enforcement goal, including all three ensures that the device will not encounter namespace issues between the Parameter Set and the WSDL. If you use only one Policy Domain, it must match the namespace used in the Policy files.

Note that you will need to create a set of keys (public certificate and matching private key) to complete this configuration. You can create these objects by selecting Encryption Certificate from the Parameter Name dropdown list and then clicking the + button under Parameter Value.

A Parameter Set that includes only these Encryption Certificate entries provides all of the information needed by the Proxy to enforce the policy.

You might optionally add some additional parameters which cause the proxy to ignore the timestamp in the signature contained in requests. If the timestamp is not ignored, the signature will expire within 5 minutes. The following illustrates the addition of these parameters.

Figure 24. Figure 24. Policy parameter
Policy parameter
  1. Click Submit when the parameter set is complete.

The configuration page for the Proxy service will now appear similar to the following illustration.

Figure 25. Figure 25. Proxy service configuration
Proxy service configuration
  1. Click Next. The Proxy will now contact the WSRR server and obtain whatever WSDLs are returned by the Saved Search Subscription. You are then presented with the inputs required to establish a Front Side Handler and to adjust the destination URL.
  2. Select an existing Front Side Handler from the list of available Handlers or click the + button to create a new Handler. This new Handler should use the HTTP protocol and must allow HTTP GET requests in addition to the enabled defaults.
Figure 26. Figure 26. Front side handler
Front side handler
  1. Click Apply to create or modify the Front Side Handler.
  2. Type /echo in the field under URI.
  3. Click Add under Edit/Remove.
  4. Adjust the Remote properties to connect to the destination server. This location will vary depending upon your circumstances. The complete configuration of an XML Firewall service that provides correct responses is included in the download files.
Figure 27. Figure 27. Local endpoint handler
Local endpoint handler
  1. Click Next. The Proxy service will now complete the configuration of the service using the Policy parameters set. The Proxy should be ready to accept requests.
Figure 28. Figure 28. Configuring web service proxy
Configuring web service proxy
  1. Verify that the Proxy includes the Policy statements by retrieving the WSDL from the Web Service Proxy service. Do this by issuing a URL in a browser similar to the following:

    http://DP_addr:3110/echo?wsdl

This retrieves the WSDL. Here is the last part of this WSDL, where the Policy Attachments have been applied correctly to the Request and Response messages.

Listing 2. Request and Response message
<wsdl:binding name="EchoSOAP" type="ns0:EchoServicePortType">
   <soap11:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
      <wsdl:operation name="echoOperation">
	<soap11:operation soapAction="echoOperation" style="document"/>

                 <wsdl:input name="echoOperationRequest">
		<wsp:PolicyReference URI="#policy1"/>
		     <soap11:body use="literal"/>
	      </wsdl:input>
	      
	      <wsdl:output name="echoOperationResponse">
		<wsp:PolicyReference URI="#policy0" />
		      <soap11:body use="literal"/>
	       </wsdl:output>

        </wsdl:operation>
</wsdl:binding>
  1. Verify the status of the Saved Search Subscription by clicking Okay under WSDL Status on the WSDLs page of the proxy.
Figure 29. Figure 29. Saved search status
Saved search status
  1. Submit a signed request file to the service. A Curl command would be similar to the following:

    curl –data-binary @echo-signed
    http://DP_addr:3110/echo

The response should be encrypted, as illustrated here.

Figure 30. Figure 30. Command response
Command response

An examination of the debug logs of this transaction show the point at which the proxy finds and verifies the signature contained in the request. If no signature were found, the proxy would have rejected this request, and returned the error message "Rejected by Policy".

11:02:06	multistep	info	487360	request	9.32.115.47	
0x80c00002	wsgw (RegistryPolicy): rule (message-input_127_5-req): 
#2 filter: 'INPUT store:///verify.xsl' completed OK.

11:02:06	multistep	debug	487360	request	9.32.115.47	
0x80c0004e	wsgw (RegistryPolicy): Stylesheet URL to compile is 
'store:///verify.xsl'

Here are the entries showing the proxy applying encryption to the unencrypted response message.

11:02:06	multistep	info	487360	response	
9.32.115.47	0x80c00002	wsgw (RegistryPolicy): rule 
(message-output_127_6-process-resp): 
#4 filter: 'enc-output store:///required-elements-filter.xsl' completed OK.

11:02:06	multistep	debug	487360	response	
9.32.115.47	0x80c0004e	wsgw (RegistryPolicy): Stylesheet URL 
to compile is 'store:///required-elements-filter.xsl'

11:02:06	multistep	info	487360	response	
9.32.115.47	0x80c00002	wsgw (RegistryPolicy): rule 
(message-output_127_6-process-resp): 
#3 Conditional on INPUT completed OK.

11:02:06	multistep	info	487360	response	
9.32.115.47	0x80c00002	wsgw (RegistryPolicy): rule 
(message-output_127_6-process-resp): 
#2 xform: 'Transforming INPUT with
http://127.0.0.1:63502/DocumentCryptoMap.xml?objDomain=Ryan&
objName=message-output_127_6-1-conditional-content-encrypt-2-enc-enc-cryptomap 
results stored in enc-output' completed OK.

11:02:06	multistep	debug	487360	response	
9.32.115.47	0x80c0004e	wsgw (RegistryPolicy): Stylesheet URL to compile is
'http://127.0.0.1:63502/DocumentCryptoMap.xml?objDomain=Ryan&
objName=message-output_127_6-1-conditional-content-encrypt-2-enc-enc-cryptomap'

Diagnostics

The WS-Proxy generates informative messages regarding many of the operations of a subscription. Here are some of the log entries generated by the Proxy regarding subscriptions and automatic notifications.

Here is the initial registration exchange with the WSRR server:

09:51:16	wsrr	notice	69503	 	  	
0x810000c8	wsrr-saved-search-subscription (Echoer): 
WSRR subscriber registered using ws-proxy RegistryPolicy

09:51:16	wsrr	notice	69503	 	  	
0x810000c9	wsrr-saved-search-subscription (Echoer): 
WSRR subscriber unregistered using ws-proxy RegistryPolicy

Here the subscription is created with the WSRR server(default domain log):

10:46:56	wsrr	info	101668	 	  	
0x81000451	Resolving 
'wsrr://WSRR25/376a0c37-eafa-4ac1.bef4.660fd266f4cc/#wsp-sp-1-1-encrypted-parts-body'.

10:46:56	wsrr	info	101668	 	  	
0x81000451	Resolving 
'wsrr://WSRR25/081ecd08-4c2b-4b32.9183.2b884d2b837c/#wsp-sp-1-1-sign-parts'.

10:46:56	wsrr	info	101668	 	  	
0x81000451	Resolving 'wsrr://WSRR25/8e42008e-125c-4cc4.bb24.147558142425/'.

10:46:56	wsrr	info	66257	 	  	
0x810004d0	wsrr-saved-search-subscription (Echoer): 
The subscription 'Echoer' contains '1' WSDL files.

10:46:56	wsrr	debug	66257	 	  	
0x810004ef	wsrr-saved-search-subscription (Echoer): 
Setting WSRR Event Notification bsrURI '0c12ef0c-baca-4aaf.aa37.a4581ca4373a'.

10:46:56	wsrr	debug	69663	 	  	
0x810004ce	The subscription 'Echoer' is creating the PolicyReference 
'wsrr://WSRR25/376a0c37-eafa-4ac1.bef4.660fd266f4cc/#wsp-sp-1-1-encrypted-parts-body' 
for the WSDL with bsrURI '8e42008e-125c-4cc4.bb24.147558142425'.

10:46:56	wsrr	debug	69663	 	  	
0x810004cd	The subscription 'Echoer' is creating the AppliesTo 
URI 'http://ibm.com/was/wssample/sei/echo/#wsdl11.message(echoOperationResponse)' 
for the WSDL with bsrURI '8e42008e-125c-4cc4.bb24.147558142425'.

10:46:56	wsrr	debug	69663	 	  	
0x810004cc	The subscription 'Echoer' is creating a 
PolicyAttachment for the WSDL with bsrURI '8e42008e-125c-4cc4.bb24.147558142425'.

10:46:56	wsrr	debug	69663	 	  	
0x810004ce	The subscription 'Echoer' is creating the 
PolicyReference 
'wsrr://WSRR25/081ecd08-4c2b-4b32.9183.2b884d2b837c/#wsp-sp-1-1-sign-parts' 
for the WSDL with bsrURI '8e42008e-125c-4cc4.bb24.147558142425'.

10:46:56	wsrr	debug	69663	 	  	
0x810004cd	The subscription 'Echoer' is creating the AppliesTo URI 
'http://ibm.com/was/wssample/sei/echo/#wsdl11.message(echoOperationRequest)' 
for the WSDL with bsrURI '8e42008e-125c-4cc4.bb24.147558142425'.

10:46:56	wsrr	debug	69663	 	  	
0x810004cc	The subscription 'Echoer' is creating a 
PolicyAttachment for the WSDL with bsrURI '8e42008e-125c-4cc4.bb24.147558142425'.

10:46:56	wsrr	info	69663	 	  	
0x810004cb	The subscription 'Echoer' has a 
WSDL with bsrURI '8e42008e-125c-4cc4.bb24.147558142425' 
and '2' policy attachments.

10:46:56	wsrr	info	69663	 	  	
0x8100044d	The subscription 'Echoer' of type Saved-Search contains 
the WSDL 'Echo.wsdl' with bsrURI '8e42008e-125c-4cc4.bb24.147558142425' 
and location 'Echo.wsdl'.

10:46:55	wsrr	debug	69663	 	  	
0x810004e6	The subscription 'Echoer' creating a WSRR Notification 
Event for 'GetEchoWSDL' with bsrURI '7ee5467e-0bb0-40ef.9b3d.567bf4563d6c', 
Fetch Policy 'true', Notify IP '9.70.154.57', Notify Port '5550', and 
renewal interval '1'.

10:46:55	wsrr	info	69663	 	  	
0x810004e2	The subscription 'Echoer' is creating 
a WSRR Notification Event for 'GetEchoWSDL' of type 
'saved-search' with bsrURI '7ee5467e-0bb0-40ef.9b3d.567bf4563d6c'.

10:46:55	wsrr	notice	69503	 	  	
0x810000c8	wsrr-saved-search-subscription (Echoer): 
WSRR subscriber registered using ws-proxy RegistryPolicy

Here we see the new WSDL incorporated into the Proxy configuration:

11:37:54	ws-proxy	info	91567	 	  	
0x81000081	wsgw (RegistryPolicy): 
Adding new wsdl '8e42008e-125c-4cc4.bb24.147558142425'.

Here is an update notification entry in the application domain log:

11:37:54	ws-proxy	info	91567	 	  	
0x8100007c	wsgw (RegistryPolicy): Process update from subscription 
Echo for wsdl wsrr://WSRR25/8e42008e-125c-4cc4.bb24.147558142425/, 
service key 8e42008e-125c-4cc4.bb24.147558142425.

Here is the log entry in the default domain for an update notification:

Figure 31. Figure 31. Update notification
Update notification

If the subscription becomes invalid due to a change on the WSRR (such as deleting the saved search) or a change on the DataPower device, here are the log entries in the application domain:

10:41:23	wsrr	warn	65121	 	  	
0x810000fc	wsrr-saved-search-subscription (Echoer): 
WSRR subscription Echoer fail to retrieve files from server

10:41:23	wsrr	error	65121	 	  	
0x810004f2	wsrr-saved-search-subscription (Echoer): 
Encountered an error while creating Automatic Subscription.

10:41:23	wsrr	debug	65121	 	  	
0x810004f6	wsrr-saved-search-subscription (Echoer): 
WSRR Event Notification bsrURI cleared.

10:41:23	wsrr	error	69663	 	  	
0x8100044f	Failed to fetch WSDL, Concept, or Saved 
Search 'GetEchoWSDL0' from 
http://9.70.155.25:9080/WSRR/6.2/Metadata/XML/Query/GetEchoWSDL0.

10:41:23	network	error	69663	 	  	
0x80e00040	url-open: Remote error on url 
'http://9.70.155.25:9080/WSRR/6.2/Metadata/XML/Query/GetEchoWSDL0'

When the error is corrected, you will again see the subscription initialization sequence occur, as shown above.

Managing versions

Endpoint services often evolve as clients use them, changing to meet the needs of customers, changing to offer new capability, or changing to maintain compatibility with standards. This kind of change often requires a modification of the WSDL file that describes the service. A primary benefit of using automatically updated subscriptions is the automatic updating of the DataPower services tied to those subscriptions whenever the WSDLs that describe the endpoint services change. When the service capability changes, the WSDL changes and that new version of the WSDL is loaded into the WSRR service.

The WSRR service does not, as standard practice, overwrite existing files. Thus, when a new version of an existing WSDL is loaded into WSRR, two versions of the WSDL with the same name and namespace will exist in the Registry. Here is an example:

Figure 32. Figure 32. WSDL namespace duplicate
WSDL namespace duplicate

A saved search query depending on the name of the WSDL document will return both versions of the loaded WSDL. The DataPower device will only use the first one it gets, which may be either one.

There are several methods for managing versioning using WSRR.

  1. Add the new WSDL version and delete the old. WSRR detects this change and sends notification to the DataPower device, which then obtains the new version of the WSDL.
  2. Use Classifications. Each artifact in the Registry can be classified, and a search conducted based on classification values. The following illustrates the assignment of a classification to a WSDL.
Figure 33. Figure 33. WSRR classification details
WSRR classification details

See the Classifications property in the lower left corner. WSRR includes a standard governance model, designed to manage the lifecycle of assets. Note the Governance tab at the top of this illustration. A search could key on one of the standard life cycle classifications, rather than a custom classification shown here.

Here is the Query Wizard panel that allows you to select a Classification to use for a search criteria.

Figure 34. Figure 34. WSRR classification
WSRR classification
  1. Use other properties of the WSDL document to differentiate versions. This can include custom properties which you could use in much the same way classifications are used. Here is an example.
Figure 35. Figure 35. Differentiate WSDL versions
Differentiate WSDL versions

The SearchKey property is a custom property added to the WSDL record.

Conclusion

The Web Service Proxy running on the DataPower device effectively enforces the business policies established by the enterprise and expressed through the configuration of the Registry. All WS Proxy services configured to use the Saved Search Subscription will automatically receive the same configuration.

This combination of products allows an enterprise to establish business policies in one place and have that policy implemented and enforced automatically in many places. Because the DataPower device automatically refreshes itself through the subscription, the business can change policies easily and this change will propagate automatically to the DataPower enforcement points.


Download

DescriptionNameSize
Sample files for this articleEchoPolicyFiles.zip2.4KB

Resources

  • Follow developerWorks on Twitter.
  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
  • Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services, WebSphere, Security
ArticleID=782291
ArticleTitle=Enforcing SOA message security policy with WebSphere Service Registry and Repository and WebSphere DataPower
publish-date=12212011