Tackle WS-Security specification interoperability challenges, Part 1: Problem overview and four available workarounds

Are you struggling with a WS-Security specification level interoperability problem? Web services are often promoted as the ideal solution to application interoperability, and they are effective at integrating applications regardless of platform, vendor, and programming language. But they're not immune from interoperability issues. Discover some common problems caused by incompatibilities between different versions of the WS-Security specification, and find the best way to deal with the issues in your environment. Be sure to check out the handy chart at the end of the article to compare the benefits and drawbacks of each solution.

David Leigh (dleigh@us.ibm.com), Senior Software Engineer, IBM

David LeighDavid Leigh is a Senior Software Engineer in IBM Software Group's Scenario Analysis Lab organization, located in Research Triangle Park, North Carolina. His areas of expertise include IBM WebSphere Process Choreographer, application and server security, high availability, monitoring, IBM AIX®, and Linux®.



03 May 2007

Also available in Chinese Russian Spanish

An overview of incompatibility issues

Develop skills on this topic

This content is part of a progressive knowledge path for advancing your skills. See Implementing WS-Security for Java web services

Most interoperability issues arise not from the base Web services specification (which is quite mature and stable), but rather from the various WS-* Web services extensions, such as WS-Security. As these standards evolve, vendors must choose which draft specifications to support, and developers occasionally need to cope with incompatibility issues between different specifications.

The WS-Security standard provides mechanisms for applying authentication, integrity, and confidentiality to SOAP messages. These capabilities are often required for the adoption of Web services and Services-Oriented Architecture (SOA) within the enterprise. IBM® middleware began providing support for WS-Security with IBM WebSphere® Application Server V5.0.2. This implementation of WS-Security was based on the OASIS working draft 13 specification. WebSphere Application Server V5.1 and other IBM middleware based on the Java™ 2 Platform, Enterprise Edition (J2EE) 1.3 run times (such as IBM WebSphere Portal Server V5 and IBM WebSphere Business Integration Server Foundation V5) also contain WS-Security implementations based on the draft 13 specification. With the J2EE 1.4 run time included in WebSphere Application Server V6.0, IBM provided a WS-Security implementation based on the WS-Security 1.0 specification. IBM WebSphere Process Server and other IBM middleware using J2EE 1.4 run times contain WS-Security implementations based on the version 1.0 specification.

Unfortunately, due to changes in the wire format of the WS-Security SOAP header specification, Web service consumer applications and target Web services that conform to the draft 13 specification can't interact with consumer applications and target services that conform to the version 1.0 specification. For example, a J2EE 1.3 Web service consumer application running in WebSphere Portal Server V5.1 can't use WS-Security to communicate with a J2EE 1.4 service provider application running in WebSphere Application Server V6.0. And the problem isn't limited to the IBM middleware software stack. For example, the Microsoft® .NET Web Services Enhancements (WSE) 1.0 is also based on a draft version of the WS-Security specification, and the same interoperability problems occur when trying to communicate between this stack and any other that's based on the WS-Security 1.0 specification.

Figure 1. WS-Security specification level incompatibility problem
WS-Security specification level incompatibility problem

If confronted by this incompatibility, you have a few options to get around the problem. The remainder of this article describes these options and provides some guidance toward choosing an appropriate solution based on your business requirements and technical constraints.

For the sake of simplicity, let's assume that the Web service consumer application uses the WS-Security draft 13 specification, and the Web service provider application uses the WS-Security 1.0 specification. Note: The workarounds suggested here can also be applied to the reverse scenario in which the Web service consumer uses the WS-Security 1.0 specification, and the Web service provider uses the draft 13 specification.


Workaround 1: Upgrade Web service consumer applications to J2EE 1.4

The simplest way to avoid the problem altogether is to ensure that your Web service consumer applications are using the same WS-Security specification version as your Web service provider applications. This requires upgrading your Web service consumer application to J2EE 1.4, and possibly also upgrading your middleware to a version that supports J2EE 1.4 applications.

Upgrading J2EE 1.3 Web service consumer applications to J2EE 1.4 is a development exercise. IBM Rational® Application Developer provides a J2EE migration wizard that's capable of migrating Enterprise JavaBeans (EJB) projects, Web projects, J2EE Connector Architecture (JCA) Connector projects, and Web services from the J2EE 1.3 specification level to the J2EE 1.4 specification level.

To use the J2EE migration wizard to migrate a J2EE 1.3 application to J2EE 1.4, simply right-click the Enterprise Application project in the Project Explorer view of the J2EE Perspective, then select Migrate > J2EE Migration Wizard from the pop-up menu. After the wizard completes, you can configure the WS-Security client bindings. These bindings aren't automatically migrated by the wizard, and they must be manually configured as a post-migration task.

Next you need to ensure that the application server to which your Web service consumer application is deployed is capable of supporting J2EE 1.4 applications. For enterprise applications, WebSphere Application Server V6.0 is capable of running J2EE 1.4 applications. And for portlets, WebSphere Portal Server V5.1.0.4 is capable of running a Web project that's been migrated to J2EE 1.4. If you have these or later versions, then your migrated Web service consumer applications should run without problems. Otherwise, you may need to upgrade your middleware.

Figure 2. Upgrade Web service consumer application(s) to J2EE 1.4
Upgrade web service consumer application(s) to J2EE 1.4
Table 1. Roles and tasks for upgrading Web service consumer applications to J2EE 1.4
RoleTask
Application developerMigrate Web service consumer applications to J2EE 1.4
DeployerSet up the J2EE 1.4 operating environment for Web service consumer applications
Test engineerVerify that the migrated Web service consumer works as expected

Migrating your applications and (if necessary) your middleware to J2EE 1.4 is the preferred way to avoid the WS-Security specification level interoperability problem. It eliminates the problem altogether and provides the strategic benefits of being at the latest middleware code levels.

However, depending on your applications and your middleware environment, it may be inconvenient or difficult to migrate your Web service consumer applications to J2EE 1.4. Furthermore, the effort required to implement this approach increases linearly with each additional Web service consumer application using the WS-Security draft 13 specification that must be migrated.


Workaround 2: Use a Web Services Gateway

The Web Services Gateway is a software component of IBM WebSphere Application Server Network Deployment, which can be optionally configured after product installation. IBM WebSphere DataPower SOA Appliances are purpose-built, easy-to-deploy network devices. Both Web Services Gateway and WebSphere DataPower SOA Appliances are intended to help simplify and secure the deployment of Web services in the enterprise. WebSphere DataPower SOA Appliances can also be used to improve the performance of Web services applications.

Either the Web Services Gateway or a DataPower appliance can be used to address the WS-Security specification level interoperability problem. As shown in Figure 3, both of these solutions have the capability to proxy a Web service that uses the WS-Security 1.0 specification and make this service available to all Web service consumers that use the WS-Security draft 13 specification.

Note: In the remainder of this article, this workaround is referred to as the middleware proxy approach.

Figure 3. Use a Web Services Gateway or DataPower appliance
Use a Web Services Gateway or DataPower appliance
Table 2. Roles and tasks for using the middleware proxy approach
RoleTask
DeployerInstall the Web Services Gateway or DataPower appliance
Configure the J2EE 1.4 service on the Web Services Gateway or DataPower appliance
Test engineerVerify that the Web service consumer works as expected

One advantage to the middleware proxy approach is that no application development tasks are required. The Web services provider and consumer applications can interoperate through the middleware proxy without changes. For this reason, the middleware proxy scales well when there are many Web service consumers using the WS-Security draft 13 specification that need to be integrated with a Web service provider using the WS-Security 1.0 specification. After the middleware proxy has been installed and configured with a provider service, it can be used to integrate any number of Web service consumers with no additional effort.

Another advantage to this approach is that you gain all of the benefits of using either the Web Services Gateway or the DataPower appliance. These components can simplify deployment and management of Web services in the enterprise and, in doing so, improve the return on investment for your Web services applications and infrastructure. Furthermore, if you choose to use a DataPower appliance, the capabilities in the device can actually improve performance of your Web services applications. For more information on the benefits of the Web Services Gateway and WebSphere DataPower SOA Appliances, see the links in the Resources section at the end of this article.

A disadvantage to the middleware proxy approach is that it introduces a nontrivial set of operations and administration tasks. You must install, configure, and manage the middleware proxy component as any other critical infrastructure component. If you've purchased the WebSphere Application Server Network Deployment Edition, then you already have the Web Services Gateway component, and no additional purchase is necessary. On the other hand, if you choose to use a DataPower appliance, there may be costs associated with acquiring this network device.

Another drawback is that this approach might break the trust model between the Web service consumer and Web service provider. This is because, depending on the security being applied, the middleware proxy may need to verify and decrypt the inbound SOAP message sent from the consumer to the proxy and then reapply security on the outbound SOAP message that's sent from the proxy to the provider. This can have serious implications to your security architecture.


Workaround 3: Use an EJB proxy

If you're looking for a lightweight, low-cost alternative to the middleware proxy approach, using an EJB proxy might be suitable. In this approach, a new J2EE 1.4 EJB application is developed and deployed to the front-end middleware tier, which also hosts the Web services consumer application. This approach requires the front-end middleware tier to contain WebSphere Application Server V6.0 or later, or another J2EE application server capable of supporting J2EE 1.4 applications.

Figure 4 shows how the EJB proxy approach is used to allow a J2EE 1.3 portal application to communicate with a J2EE 1.4 Web service provider. The Portal application communicates with the EJB proxy using the EJB's Remote Method Invocation (RMI) interface, and the EJB passes the request to the Web service provider using the WS-Security 1.0 specification.

Figure 4. Use an EJB proxy
Use an EJB proxy
Table 3. Roles and tasks for using the EJB proxy approach
RoleTask
Application developerCreate the EJB proxy application
Integrate the Web services consumer with the EJB proxy application
DeployerDeploy and manage the EJB proxy application
Test engineerVerify that the Web service consumer works as expected

The effort required to implement the EJB proxy approach is primarily application-development work, although this workaround does introduce another application that must be deployed, secured, and managed by the operations team.

The EJB proxy approach is best suited to sandbox, test, or proof-of-concept situations in which upgrading Web services consumer applications to J2EE 1.4 is not an option and in which the cost of setting up a middleware proxy is prohibitive. A drawback of this approach is that it doesn't scale well when there are a lot of Web service consumers using the WS-Security draft 13 specification that need to be integrated with a Web service provider that uses the WS-Security version 1.0 specification. In this case, each Web service consumer application must be separately integrated with the EJB proxy, which can make the necessary development effort become large.


Workaround 4: Add a new provider endpoint

In this last approach, you add a J2EE 1.3 Web service endpoint to the J2EE 1.4 provider application. Depending on how your J2EE 1.4 Web service provider application is implemented, it may be a simple exercise to add an additional Web project based on the Java Servlet 2.2 (J2EE 1.3) specification and package this with the provider application. Your provider application will then contain two Web service endpoints as shown in Figure 5.

Figure 5. Add a new provider endpoint
Add a new provider endpoint
Table 4. Roles and tasks for using the new provider endpoint approach
RoleTask
Application developerCreate a new Web service endpoint in a new Java Servlet 2.2 Web project
Package the new Web project in the J2EE 1.4 EAR file
DeployerDeploy and manage the Web service provider application
Test engineerVerify that the Web service consumer works as expected

This approach scales well when there are many Web service consumer applications. After the Web service provider application is modified so that it provides a J2EE 1.3-compatible Web service endpoint, any number of Web service consumer applications can use this new endpoint. And unlike either the EJB proxy approach or the middleware proxy approach, this approach has no performance impact.

As with the EJB proxy approach, this workaround is primarily an application development exercise and introduces another Web service endpoint that must be managed and secured.

This approach is best used when the Web service implementation classes are simple JavaBeans components or EJB components. If the Web service implementation logic is contained in a servlet, in a Service Component Architecture (SCA) component, or in an Enterprise Service Bus (ESB) mediation module, then it will likely be difficult to create the Java Servlet 2.2 (J2EE 1.3) Web project and package it with the Web service provider application.


Summary

Table 4 outlines the relative benefits and drawbacks of the three workarounds described in this article to help you to determine the best workaround approach for your situation.

Table 4. Comparison of workaround benefits and drawbacks
ApproachBenefitsDrawbacksBest used
Upgrade Web service consumer applications to J2EE 1.4
  • Being at the latest middleware and J2EE specification levels
  • No performance impact
  • Not very scalable; each Web service consumer application must be migrated separately
  • Middleware migration may also be required
  • Some applications and middleware environments may be inconvenient and difficult to migrate
When the number of consumer applications is small and especially when the consumer-side middleware environment is already capable of supporting J2EE 1.4 applications
Use a middleware proxy
  • Very scalable; after configured, the proxy can support any number of consumer applications
  • No changes needed to consumer or provider applications
  • Ease of management benefits from the Web Services Gateway or DataPower appliance
  • Performance benefits when using a DataPower appliance
  • Additional operations and administration tasks required to support a new critical infrastructure component
  • Some performance impact when using the Web Services Gateway
  • May break trust model if the proxy needs to verify and decrypt the inbound SOAP message and then reapply security on the outbound message
When there's a large number of consumer applications or when the consumer applications can't be modified
Use an EJB proxy
  • Implementation is a basic programming exercise, thus no extra infrastructure is required
  • Some performance impact
  • Not very scalable; the EJB proxy must be integrated with each consumer application
  • Introduces a new application that must be deployed, secured, and managed
When you need a lightweight, low-cost solution for sandbox, test, or proof-of-concept situations
Add a new provider endpoint
  • Implementation is a basic programming exercise, thus no extra infrastructure is required
  • No performance impact
  • Very scalable; after configured, the proxy can support any number of consumer applications
  • Not easily implemented when the Web service implementation logic is more complex than a simple JavaBeans or EJB component
  • Introduces a new provider endpoint that must be secured and managed
When looking for a lightweight solution and when the Web service implementation logic is a JavaBeans or EJB component

Stay tuned for subsequent articles in this series, which will provide details and examples that show you how to implement the middleware proxy and EJB proxy workarounds.

Acknowledgements

I'd like to thank the following individuals for their comments and contributions to this article:

  • Hyen Chung, architect and lead developer of Web services security on the WebSphere platform
  • Billy Lo, senior IT architect, IBM Global Business Services

Resources

Learn

Get products and technologies

  • Innovate your next development project with IBM trial software, available for download or on DVD.

Discuss

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
ArticleID=210047
ArticleTitle=Tackle WS-Security specification interoperability challenges, Part 1: Problem overview and four available workarounds
publish-date=05032007