WSE 3.0 Security: Interoperability Considerations

WSE 3.0 Security: Interoperability Considerations

Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0

Microsoft Corporation

patterns & practices Developer Center
Web Service Security: Home
December 2005

Contents

Overview
Interoperability Between WSE 2.0, WSE 3.0, and WCF
Web Services Security Interoperability with Other Platforms
More Information

Overview

The Web Service Security guide provides detailed information about how to provide Web services security in your environment, including implementation patterns that use Web Services Enhancements (WSE) 3.0 to implement a set of core standards, such as XML, SOAP, Web Services Description Language (WSDL), and WS-Security. In many cases, your environment will include multiple platforms, so to successfully act on some of the guidance, you need to understand some important interoperability issues that arise in a Web services environment.

This appendix provides an overview of interoperability issues that you may encounter when developing Web services secured using SOAP message security. It is not intended to provide a detailed analysis of other areas of interoperability relating to technologies such as XSD, WSDL, or SOAP. For in-depth information about interoperability and Web service security, see WS-I Basic Security Profile 1.0 Reference Implementation: Preview release for the .NET Framework version 1.1 on MSDN. There is also a WSE 3.0 Community Technical Preview (CTP) of this application available on the Microsoft WS-I Basic Security Profile community workspace [Content link no longer available, original URL:https://go.microsoft.com/fwlink/?linkid=47780&clcid;=0x409].

Interoperability Between WSE 2.0, WSE 3.0, and WCF

This section details the degree of interoperability that is available between the different Microsoft platforms for Web Service development.

WSE 3.0 and the Windows Communication Framework (WCF)

Microsoft provides on the wire interoperability between WSE 3.0 and WCF (formally code-named "Indigo"). This allows messages sent from a client based on WSE 3.0 to be consumed by a WCF service, and vice versa. WCF includes two standard bindings for backward compatibility with ASMX Web services and WSE 3.0. The BasicHttpBinding, which does not incorporate message layer security, provides wire-level compatibility with ASMX Web services, while the WsHttpBinding is fully interoperable with WSE 3.0 (with a few minor configuration changes).

However, there will not be an automated mechanism to upgrade WSE 3.0 applications to run on WCF. The WS-I BSP Reference Implementation application was designed to reduce the burden of upgrading code. For more information, see Chapter 6, Designing Web Services for Interoperability and Resilience of WS-I Basic Security Profile 1.0 Sample Application: Preview release for the .NET Framework version 1.0.

WSE 3.0 and WSE 2.0

Because of changes in the underlying specifications for WS-Addressing, WS-Trust, and WS-SecureConversation, WSE 3.0-enabled applications do not interoperate with WSE 2.0-enabled applications. However, WSE 3.0 and WSE 2.0 client applications can run side-by-side with the .NET Framework 2.0. You can host WSE 3.0-enabled Web services and WSE 2.0-enabled Web services on the same computer, but they must be in separate virtual directories for ASP.NET or separate applications for Windows Forms applications.

It is theoretically possible to develop Web services using WSE 2.0 in such a way that they can interoperate with WSE 3.0 (and WCF) by using only a reduced set of specifications—specifically, SOAP 1.1, WSDL 1.0, and WS-Security 1.0. However, Microsoft does not support interoperability in this situation. The safest way to plan for interoperability with WCF is to upgrade the WSE 2.0 code to WSE 3.0.

Web Services Security Interoperability with Other Platforms

Interoperability issues can arise for many reasons, ranging from incorrect implementations of XSD data types to varying support for extensibility points, such as which algorithms are implemented. Complete coverage of these issues is outside the scope of this appendix, but it does discuss three major areas that may result in interoperability issues.

Support for Advanced Web Services Specifications

Web service specifications are intentionally designed to be composable. Because of this, there are more advanced capabilities, such as layering security on top of the fundamental specifications that relate to messaging. To achieve interoperability between different platforms, you should understand how each platform has implemented the underlying Web service specifications.

Web services specifications implemented in WSE 3.0 include: WS-Security 1.0 and 1.1, WS-Trust, WS-SecureConversation, WS-Addressing (08/2004 draft), SOAP Message Transmission Optimization Mechanism (MTOM), SOAP 1.1, and SOAP 1.2. For more information about the implemented specifications, see the WSE 3.0 documentation.

Figure 1 illustrates an overview of the Web services specifications related to security.

Figure 1. The SOAP message security stack

Note that not all Web services specifications in Figure 1 are currently implemented in WSE 3.0. Most major vendors currently support WS-Security 1.0, but some vendors may not yet have implemented more advanced specifications, such as WS-Trust and WS-SecureConversation.

Support for New Versions of Web Services Specifications

WSE 2.0 implemented WS-Security 1.0, but WSE 3.0 implements both WS-Security 1.0 (WSS1.0) and WS-Security 1.1 (WSS1.1). WS-Security 1.1 introduces several new capabilities that include:

• XML digital signature confirmation. Web services can now confirm to a client when an XML digital signature is verified. Clients can decide whether to accept SOAP responses from Web services that do not send signature confirmations.
• EncryptedKey security tokens. EncryptedKeyToken security tokens are used to optimize the performance of cryptographic operations when only the public key from an asymmetric key pair, such as a certificate, is present. You can use EncryptedKeyToken security tokens to secure SOAP message exchanges between anonymous clients that have only the public key for a Web service's certificate.

For a detailed description of each turnkey scenario, see the WSE 3.0 documentation. However, Table 1 also provides a summary of WSE 3.0 turnkey scenarios, and their dependency on WS-Security specifications. If interoperability with WSS1.0 is required, make sure you use an assertion marked with an "X" in the WSS 1.0 column. You should ensure that your Web services support WSS 1.1 before requiring the client to check for the optional SignatureConfirmation capability because this is a WSS 1.1 feature. WSE 3.0 tooling automatically generates policy that has the SignatureConfirmation option set to false.

Table 1. Summary of WSE 3.0 Turnkey Scenarios and WS-Security Dependence

The following code example shows an example of the MutualCertifcate10 policy assertion with the requireSignatureConfirmation field, which you can be set to true or false.

<mutualCertificate10
  clientActor
  requireDerivedKeys="true|false"
  establishSecurityContext="true|false"
  messageProtectionOrder="Signature and encryption order"
  renewExpiredSecurityContext="true|false"
  serviceActor
  requireSignatureConfirmation="true|false"  
  ttlInSeconds >
  <clientToken>
  <serviceToken>
  <protection>
</mutualCertificate10 >

Most major vendors currently support WS-Security 1.0, but some vendors may not yet have implemented WS-Security 1.1.

Varying Support for Extensibility Options Within the Specifications

A number of Web services specifications contain extensibility points that vendors may implement. For example, an extensibility point within the WS-Security specification is the selection of cryptography algorithms. WS-I has created profiles that help to reduce the number of options within extensibility points. For this reason, it is more likely that different platforms will interoperate.

One extensibility point used by WSE 3.0 and WCF that is not implemented by all vendors is the key transport algorithm. Key transport algorithms are used to optimize encryption by encrypting symmetric encryption keys, such as data encryption keys, with asymmetric encryption keys. WSE 3.0 and WCF use a default setting of RSA_OAEP. If you need to interoperate with an application that has not implemented RSA_OAEP, you may need to consider changing to RSA15 instead. RSA_OAEP is also not supported on Windows operating systems earlier than Windows XP. The following excerpt from the WS-I Basic Security Profile refers to the key transport algorithm.

R5621 When used for Key Transport, any xenc:EncryptionMethod/@Algorithm attribute in an ENCRYPTED_KEY MUST have a value of "http://www.w3.org/2001/04/xmlenc#rsa-1_5" or "http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"

The RSA (PKCS#1.5) algorithm ("http://www.w3.org/2001/04/xmlenc#rsa-1_5") is widely implemented and deployed in existing practice. The RSA-OAEP algorithm ("http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p") is relatively new and becoming widely implemented and deployed.

Example

The following configuration example specifies that symmetric session keys generated for X509SecurityToken security tokens are encrypted using the RSA15 algorithm instead of the default RSA_OAEP algorithm. This configuration is placed in the App.config file or the Web.config file of the server.

<configuration>
  <microsoft.web.services3>
    <security> 
      <binarySecurityTokenManager>
        <add valueType="http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
        type="Microsoft.Web.Services3.Security.Tokens.X509SecurityTokenManager, Microsoft.Web.Services3, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" priority="1" group="0">
          <!—-Default value is keyAlgorithm name="RSAOAEP" -->
          <keyAlgorithm name="RSA15"/>
      </add>
    </security>
  </microsoft.web.services3>
</configuration>

If you encounter additional interoperability issues related to WSE 3.0, post a message on the Microsoft WS-I Basic Security Profile community workspace [Content link no longer available, original URL:https://go.microsoft.com/fwlink/?linkid=47780&clcid;=0x409].

More Information

For in-depth information about interoperability and Web service security, see WS-I Basic Security Profile 1.0 Reference Implementation: Preview release for the .NET Framework version 1.1 on MSDN.

For information about how the WS-I BSP Reference Implementation application reduces the burden of upgrading code, see Chapter 6, "Designing Web Services for Interoperability and Resilience" of WS-I Basic Security Profile 1.0 Reference Implementation: Preview release for the .NET Framework version 1.0 on MSDN.

For information about the WS-I Basic Security Profile 1.0 Reference Implementation application, see the WSE 3.0 Community Technical Preview (CTP) [Content link no longer available, original URL:https://go.microsoft.com/fwlink/?linkid=47780&clcid;=0x409] on the "Microsoft WS-I Basic Security Profile community workspace".

For information about the implemented specifications, see the "WSE 3.0 documentation".

For information about the WS-I Basic Security Profile, see "Basic Security Profile Version 1.0".

For information about SOAP Message Security 1.0, see "Web Services Security: SOAP Message Security 1.0 (WS-Security 2004) from OASIS".