Metro to WCF Interoperability
Published: July, 2010
Introduction
This whitepaper takes a practical look at the results of interoperability testing of web services and clients created using the Windows Communication Foundation (WCF) stack[1] from Microsoft and the Metro stack[2] from Oracle. This testing effort was designed to help find and root out any potential incompatibilities between these stacks to make it easier for WCF and Metro developers to build web services and clients that can communicate using the SOAP and WS-* family of protocols.
The testing effort followed guidelines that you can find on the Web Services Interoperability Organization (WS-I) website at http://ws-i.org. WS-I is an open industry organization chartered to establish Best Practices for Web services interoperability, for selected groups of Web services standards, across platforms, operating systems and programming languages. This whitepaper discusses the WS-I testing effort for several scenarios, and also includes practical advice for getting your WCF and Metro web services and clients to interoperate in the most natural way possible.
The WS-I guidelines are designed to accommodate a very broad range of web service stacks, and building web services that conform to these guidelines will increase the chances of a web service or client to interoperate with other services and clients that are also configured to conform to WS-I guidelines. In some scenarios to achieve conformance with WS-I requires a bit more work, occasionally involving more convoluted configuration than might be necessary to communicate between any two particular stacks. Because this paper is focused on WCF <--> Metro interoperability, the testing team kindly tested some scenarios that aren't strictly conformant with WS-I but are more natural in WCF and Metro and allow interoperability between services and clients built using these stacks, and the paper calls this out where appropriate.
Scenarios
The testing effort was very comprehensive, covering many of the WS-I profiles. This paper focuses on eight scenarios, moving from broadly used scenarios to more specialized ones where interoperability can be more challenging:
- Interoperability with various data types
- Basic Profile 1.2 conformant service with one-way and request-response operations
- Basic Profile 2.0 conformant service with one-way and request-response operations
- MTOM (Message Transmission Optimization Mechanism)
- Basic Security Profile conformant service
- Reliable Secure Profile conformant service (one-way calls with non-addressable client)
- Reliable Secure Profile conformant service (request-response with non-addressable client)
- Reliable Secure Profile conformant service (secure reliable request-response)
Three WS-I profiles are involved in these scenarios. Here are links to the profiles for further reading:
Data Types
An important step to practical interoperability between a client and a web service is a wire-level agreement on how fundamental types of data should be serialized. Also it should be possible to generate client code to call the service based on the service description. Basic Profile testing helps ensure these expected interoperability features are present, and both the Basic Profile 1.2 and Basic Profile 2.0 scenarios cover the use of the data types described in this section.
Once support for sending and receiving a simple string is established, supporting more interesting data types such as dates as well as complex data types such as structures and collections allow for richer contracts.
The data types covered by these scenarios include the following:
- byte (both signed and unsigned)
- int (both signed and unsigned)
- short (both signed and unsigned)
- long (both signed and unsigned)
- boolean
- base64binary
- decimal
- float
- double
- string
- URI
- DateTime
- Duration
- XML Qualified Name
- AnyType
An AnyType parameter can hold any of the types in this list. In its serialized form, the concrete type of an AnyType parameter is identified with an xsi:type attribute.
Complex data types were also covered by these tests, which included arrays of integers and arrays of strings. The implication of these tests is that data structures and generic collections made up of these types of basic objects and arrays will interoperate successfully.
The WCF and Metro clients and web services successfully interoperated using simple and complex data types with RPC/literal and document/literal wrapped encodings. During the testing, WCF and Metro refined the tests such as for RetAnyType so the scenario could be readily understood by third-party clients and web services.
Basic Profile 1.2 Conformance
One of the most fundamental goals of the Basic Profile is to define a set of testable requirements to which a web service should adhere in order to achieve the best possible interoperability with other stacks. For example, the Basic Profile tells us that a Unicode Byte Order Mark (BOM) at the beginning of a message is acceptable, and that conformant receivers must be ready to accept a message with a BOM. As another example, when using HTTP, Basic Profile prohibits the XML DTD (Document Type Definition) and XML processing instructions from being present in a SOAP message. There are many rules in the Basic Profile that constrain or clarify the use of XML, SOAP, and HTTP features, and help narrow the possible interpretations of the core Web Services specifications so that it's more likely that conforming clients and web services will interoperate smoothly.
During testing, both the WCF and Metro clients and web services achieved interoperability.
Practical Usage
Practically speaking, what this means is that it's possible to send one-way or request-response SOAP 1.1 messages from a WCF client to a Metro service and receive a valid response, and vice versa. Both the request and the response message can contain simple and complex data types. Both the WCF and Metro stacks are designed with these fundamental requirements in mind, so you shouldn't need significant special configurations or code to achieve them.
Test Description
The approach to testing these myriad basic requirements involves conducting collaborative testing to achieve application-level interoperability. A monitoring tool is used to capture traffic between the client and service being tested. Metadata from the service is also captured, including WSDL and XML schemas. The captured traffic and metadata are then fed into an analysis tool which verifies each requirement in the profile. The output of the analysis step is a test report that indicates which test assertions passed or failed.
Basic Profile 2.0 Conformance
While Basic Profile 1.2 focused exclusively on SOAP version 1.1 messages, Basic Profile 2.0 added interoperability tests for SOAP version 1.2 messages, as well as MTOM encoding. SOAP 1.2 is an improvement[3] over SOAP 1.1 that can lead to better interoperability between clients and web services as well as more flexibility in transport protocol and serialization choices. Besides the addition of support for a new version of SOAP, this profile also incorporates errata and builds on the foundation of Basic Profile 1.2.
As with the Basic Profile 1.2 testing effort, simple and complex data types were successfully tested under Basic Profile 2.0.
Practical Usage
As with Basic Profile 1.2, it's possible to send one-way or request-response SOAP 1.2 messages from a WCF client to a Metro service and receive a valid response or vice versa, using both simple and complex data types
WCF Configuration Tips
A WCF web service doesn't expose a WSDL description by default (this is a security feature designed so that someone new to WCF doesn't accidentally expose more information about their service than intended). It's easy to enable WSDL by adding a service behavior via configuration. The behavior configuration also allows the version of WS-Policy to be specified.
Here is a sample service configuration that exposes WSDL using WS-Policy 1.5:
<system.serviceModel> <services> <service name="MyService" behaviorConfiguration="enableMetadata"> <endpoint address="MyService" binding="ws2007HttpBinding" contract="IMyService"/> </service> </services> <behaviors> <serviceBehaviors> <behavior name="enableMetadata"> <serviceMetadata httpGetEnabled="true" policyVersion="Policy15"/> </behavior> </serviceBehaviors> </behaviors> </system.serviceModel>
Basic Profile 2.0: MTOM
MTOM (Message Transmission Optimization Mechanism) is helpful when SOAP messages contain a large amount of binary data, for example, when transmitting binary files such as bitmap images and movies. In order to be transported in a SOAP envelope, binary data normally must be encoded using base 64 (base64binary) to ensure it can be correctly parsed by the receiver in all cases. This effectively increases its size in the SOAP envelope by a third. MTOM allows binary data to be pulled out of the SOAP envelope and attached in a more efficient manner, in a binary part of a MIME multi-part message.
During Basic Profile 2.0 testing, both the WCF and Metro clients and web services were found to correctly interoperate using MTOM optimizations, both on the sending and receiving side.
Practical Usage
This is a very practical and useful optimization for any service where large attachments such as images or audio files must be transported. MTOM is used in the medical industry to save bandwidth when sending high resolution medical images. And in large part due to tests like these, it is possible to use MTOM when communicating between WCF and Metro clients and web services.
Test Description
Three important cases are covered by MTOM testing. In each of these cases, the base64binary data is optimized using MTOM. The tests ensure interoperability of these optimizations.
- A base64binary type contained directly in the message body
- A base64binary type contained in an array or structure in the message body
- A base64binary type contained directly in a message header
WCF Configuration Tips
MTOM is an optional feature that is disabled by default in WCF. It can be enabled for any service endpoint via a binding configuration. Once this is done, all large binary fields found in either the body or header will be automatically optimized using MTOM. Here is an example:
<system.serviceModel> <bindings> <wsHttpBinding> <binding name="UseMTOM" messageEncoding="Mtom"/> </wsHttpBinding> </bindings> <services> <service name="SongService"> <endpoint address="SongService" binding="wsHttpBinding" bindingConfiguration="UseMTOM" contract="ISongService"/> </service> </services> </system.serviceModel>
Metro Configuration Tips
MTOM is an optional feature that is disabled by default in Metro. It can be enabled for a service implementation via the @MTOM annotation.
@javax.xml.ws.soap.MTOM
@WebService
public class SongServiceImpl implements SongService {
....
}
Alternatively, MTOM can be enabled in the sun-jaxws.xml configuration file:
<endpoints xmlns='http://java.sun.com/xml/ns/jax-ws/ri/runtime' version='2.0'> <endpoint name="Mtom" implementation="SongServiceImpl" url-pattern="/songService" enable-mtom="true"/> </endpoints>
When using JAX-WS typed clients, use the service constructor that includes features, and pass the MTOMFeature as one of the feature parameters.
Basic Security Profile
There are two approaches to securing SOAP messages: transport- and message-level security. Transport level security is a point-to-point security solution, while message-level security is an end-to-end solution.
Implementing authentication at the transport level has drawbacks in some scenarios. First, it limits a receiver's ability to implement a security feature known as nonrepudiation. This is helpful in situations where a sender sends a message and then later repudiates (claims he didn't send) the message. When using transport level security, there's no discrete signature on the SOAP message itself, so this can be troublesome. Second, because transport level security is point to point, in authenticated systems with intermediaries such as Microsoft BizTalk Server, the receiver doesn't see the original sender's identity; rather it sees the intermediary.
Using message level security helps to solve these problems by pushing cryptography down into the SOAP Security header so that it travels along with the message, through any intermediaries, on to the final destination. This end-to-end security allows the ultimate receiver to see the signature of the original sender, as opposed to an intermediary like BizTalk. With the sender's signature in the SOAP Security header, it also becomes possible for a receiver to log signed messages for later rebuttal if the sender attempts to deny sending a message. And finally, message level security also allows critical parts of the message to be encrypted by the sender so that only the ultimate receiver will be able to decrypt them, but not any intermediaries. Even more importantly, an intermediary will be able to read the sections of the message (typically headers) that are not encrypted. This allows for scenarios such as routing even in the face of end-to-end encryption of the body of the message.
During testing, both the WCF and Metro stacks were found to correctly interoperate when playing the role of either sender or receiver in this scenario.
Test Description
The majority of the testing in this effort covered BSP 1.1 scenarios that aren't often used when interoperating between WCF and Metro, so the team performed an extra test for this paper that was more typical. This test scenario was a request and response protected with mutual authentication using X.509 certificates to authenticate both the server and the client. All messages were signed for authentication and integrity then encrypted for confidentiality.
WCF Configuration Tips
Message level security is enabled by default when using wsHttpBinding or ws2007HttpBinding, however the credential type is "Windows" by default, which isn't a broadly interoperable credential type. A binding customization is required to configure the use of certificates as shown below.
<system.serviceModel> <bindings> <ws2007HttpBinding> <binding name="UseCertificates"> <security mode="Message"> <message clientCredentialType="Certificate" establishSecurityContext="false" negotiateServiceCredential="false"/> </security> </binding> </ws2007HttpBinding> </bindings> <services> <service name="MyService"> <endpoint address="MyService" binding="ws2007HttpBinding" bindingConfiguration="UseCertificates" contract="IMyService"/> </service> </services> </system.serviceModel>
The Basic Security Profile doesn't cover session based security (WS-SecureConversation), and it wasn't explored during this testing effort, which is why establishSecurityContext is set to "false" above. This effectively asks WCF to use per-message security. But session based security can be more efficient in many scenarios, especially when a single proxy is used to make several calls to a secure web service. Both WCF and Metro implement WS-SecureConversation and are highly interoperable in practice, so it's not likely that you'll have trouble if you decide to leave session security on instead of disabling it as shown above.
The negotiateServiceCredential setting is also disabled, which implies that the client must have a copy of the server's certificate beforehand in order to successfully make a call using this binding. Service certificate negotiation is a feature that is also outside of the scope of the Basic Security Profile.
Certificate Management in Windows
In Windows, a certificate is typically installed into a "certificate store" before being used at runtime. An easy way to do this is with the Certificates snap-in for the Microsoft Management Console, shown below.
Certificates that have a corresponding private key (e.g., PFX files) should be installed in the Personal store, and the corresponding private key must be configured to allow WCF to access it[4]. The private key allows you to prove your identity to the party with whom you are communicating.
If you are implementing a service, your service certificate will have a private key and should be installed in the Local Computer Personal store. If you are implementing a client, your client certificate will have a private key and should be placed in the Personal store of the user who will be running the client.
The other party in the conversation is also represented by a certificate, but in this case the private key is held by the other party. These certificates can be loaded directly from a disk file via the X509Certificate2 constructor, or they can be installed in a certificate store such as Trusted People and loaded from there.
Dealing with Self-Signed Certificates
During testing, often self-signed certificates are used. These certificates are not trusted by WCF, and will cause the runtime authentication handshake to fail unless they properly configured beforehand. There are a number of ways of dealing with this. The simplest is to tell WCF not to perform any certificate trust validation at all, with a behavior configuration that sets the certificateValidationMode to "None". The example below shows how to configure a service to accept a self-signed certificate from a client:
<system.serviceModel> <services> <servicename="MyService" behaviorConfiguration="certificateValidation"> <endpointaddress="MyService" binding="ws2007HttpBinding" contract="IMyService"/> </service> </services> <behaviors> <serviceBehaviors> <behaviorname="certificateValidation"> <serviceCredentials> <clientCertificate> <authentication certificateValidationMode="None" /> </clientCertificate> </serviceCredentials> </behavior> </serviceBehaviors> </behaviors> </system.serviceModel>
A second choice is to set certificateValidationMode to "PeerTrust" (instead of "None" in the example above) and install the other party's self-signed certificate into the TrustedPeople store.
A third choice, which doesn't require any WCF configuration at all, is to install the other party's self-signed certificate into the Trusted Root Certification Authorities store. Be certain to remove this certificate when you're done testing, as it does open a security vulnerability. Because of this, you should never choose this option on a production machine.
For your own self-signed certificates where you hold the private key, you'll need to install a copy of the certificate into the Trusted Root Certification Authorities store. As long as the private key is not disclosed to any untrusted party, this does not open a security vulnerability.
There's a lot more to certificate management in Windows that this paper doesn't have room to cover, but you can learn more about this topic by reading the MSDN library[5].
Certificate Management in Java and GlassFish
In Java a certificate is typically installed into a Java keystore before being used at runtime. And Keytool[6] is the primary tool available for Java developers in general and GlassFish users.
If you are implementing a service, your service certificate will have a private key and should be installed in a keystore (when the service is deployed on GlassFish the keystore is the Glassfish keystore). If you are implementing a client, your client certificate will have a private key and should be placed in a client keystore (when the client is deployed on GlassFish the keystore is the Glassfish keystore) configured into the metro client side configuration file. The metro configuration file on the client and server side should be updated with a keystore assertion that describes the alias (the identifier for the key-pair).
Certificates which identify root authorities will not have an associated private key and such certificates need to be added as Trusted Entities into a java keystore (generally refered to as a truststore). The GlassFish truststore is generally populated with a variety of Trusted Authority Certificates of various trusted issuers.
Certificates of other parties can be placed in a Java CertStore, they can also be placed in the truststore during testing phases but be certain to move to a CertStore when you're done testing, as it does make the certificate a trusted root otherwise.
You can learn more about X509 certificate configuration in Metro on both the client and server side when running on Glassfish and Non-GlassFish container(s) by reading this article[7].
Dealing with Self-Signed Certificates in Metro
When using self-signed certificates for testing, place them in the Trusted Root Authority store (truststore) of your peer. Be certain to remove this certificate when you're done testing, as it does open a security vulnerability. Because of this vulnerability, you should avoid testing with self-signed certificates on production machines.
A Metro service can also configure a custom Certificate Validator where it can do special handling for self-signed certificates[8]. However this is not an option when the application needs to use transport security (SSL/TLS). When SSL/TLS is involved the only option is to place the self-signed certificate inside the truststore of your peer.
Metro Configuration Tips
Message level security is not enabled by default in Metro for a web service should be enabled by specifying the required WS-Policy (WS-SecurityPolicy) assertions and attaching those policies to appropriate WSDL elements (wsdl:Binding, input and output messages of a wsdl:operation, or to the wsdl:operation element itself). When using NetBeans for web service development, security for a web service can be enabled by choosing a suitable security mechanism . You can learn more about security mechanisms from the Metro and NetBeans documentation[9].
Message level security is automatically enabled for a Metro web service client whenever the client tries to contact a secure web service. "Secure web service" refers to a service whose WSDL has been annotated with policies as described above. If the service does not publish WSDL (the default in WCF), or if the published WSDL does not have policies, then security can still be enabled in a Metro web service client by having those policies in the Metro client-side configuration file. You can learn more about the Metro client configuration in the Metro documentation[10].
Due to import restrictions, the JDK doesn't support key sizes larger than 128 bits. A patch[11] can be applied to the JDK in order allow longer key lengths to be used. This patch was used during testing to allow for 256 bit keys.
Reliable Secure Profile (RSP) Scenarios
The Reliable Secure Profile (RSP) considers interoperability with respect to WS-ReliableMessaging (RM), as well as scenarios involving both RM and message level security. Some of these scenarios focus purely on RM, while others also compose message security, which is why the word "Secure" is part of the profile. This paper covers three scenarios, the first two focusing purely on interoperability while using RM, with the last scenario demonstrating interoperability when using message level security in conjunction with reliable messaging.
Reliable messaging should not be confused with "durable" messaging, which typically involves persistent message queues, allowing for message recovery in the face of application crashes. The WS-ReliableMessaging specification doesn't require an implementation to persist messages, so across web service stacks, these sorts of durability guarantees generally cannot be expected (as of this writing neither WCF nor Metro implement RM using durable messaging). Instead, RM implementations generally provide a transparent measure of reliability at the application level using in-memory buffering similar to what TCP provides at a lower level in the network stack. This is useful when you want to enhance reliability of SOAP messages in the face of unreliable intermediaries and unreliable network connections. For example, consider a user walking around a building with a handheld wireless device that switches between various wireless access points, dropping and later reestablishing a network connection to the service. With reliable messaging, this spotty network connectivity can be smoothed out so the client and service don't notice this detail. Another use for RM is to hide failures from SOAP intermediaries such as data-driven routers.
Reliable messaging provides several different types of guarantees. Duplicate messages can be automatically discarded. Messages can be automatically buffered in the receiving process to ensure ordered delivery. A sender can learn if a message was received via a system of acknowledgements.
Reliable One Way
The first scenario to consider is reliable one-way messaging. This is a simple case of reliable messaging where the sender doesn't expect a response from the receiver. All of the same reliability guarantees are in place, but the sender doesn't receive any output from the receiver. Because no response is expected, WS-MakeConnection doesn't come into play.
During testing, both the WCF and Metro clients and web services were found to correctly interoperate when playing the role of either sender or receiver in this scenario.
Test Description
A simple ping service forms the basis of these tests, where the client sends a request to the service using reliable messaging. The tests ensure that the expected RM sequencing messages are exchanged. The tests are performed using a variety of protocol versions, including both SOAP 1.1 and 1.2, with the latter being the standard, recommended protocol.
WCF Configuration Tips
Request-response messaging is the default for WCF service contracts. To enable one-way messaging, annotate the service contract as shown below.
[ServiceContract]
public interface ISayHello
{
[OperationContract(IsOneWay = true)]
void SayHello(string message);
}
Reliable messaging is not enabled by default in WCF. Enabling it requires a simple binding configuration, as shown below. Note that ordered delivery is an optional constraint that causes WCF to buffer messages so that they may be reordered before delivery to the application in case they don't arrive in the order they were sent.
<system.serviceModel> <bindings> <ws2007HttpBinding> <binding name="UseRM"> <reliableSession enabled="true" ordered="true" /> <security mode="None" /> </binding> </ws2007HttpBinding> </bindings> <services> <service name="MyService"> <endpoint address="MyService" binding="ws2007HttpBinding" bindingConfiguration="UseRM" contract="ISongService"/> </service> </services> </system.serviceModel>
Metro Configuration Tips
As with WCF, in Metro the default message exchange pattern is request-response. To enable one-way messaging in Metro, annotate the method as shown below:
@Oneway
@WebMethod
public void sayHello(string message)
{
System.out.println("Hello " + message);
}
Reliable messaging is not enabled by default in Metro. There are three steps to enable it:
1. Extend the WSDL to require reliable messaging, as shown below:
<wsp:Policy wsu:Id="wsrm11policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <wsp:All> <wsp:ExactlyOne> <wsp:All> <ns1:RMAssertion xmlns:ns1="http://docs.oasis-open.org/ws-rx/wsrmp/200702"/> <ns2:UsingAddressing xmlns:ns2="http://www.w3.org/2006/05/addressing/wsdl"/> </wsp:All> </wsp:ExactlyOne> </wsp:All> </wsp:Policy>
2. Provide an endpoint wsit configuration file. This is simply the contents of the WSDL with named, but empty message elements and no types element. An excerpt is shown here for clarity:
... <wsp:Policy wsu:Id="wsrm11policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <wsp:All> <wsp:ExactlyOne> <wsp:All> <ns1:RMAssertion xmlns:ns1="http://docs.oasis-open.org/ws-rx/wsrmp/200702"/> <ns2:UsingAddressing xmlns:ns2="http://www.w3.org/2006/05/addressing/wsdl"/> </wsp:All> </wsp:ExactlyOne> </wsp:All> </wsp:Policy> <message name="sayHello"/> <portType name="MyService"> <operation name="sayHello"> <input message="tns:sayHello"/> </operation> </portType> ...
3. If the Metro code is acting as a client (as opposed to a service), ensure that the proxy is explicitly closed so that the proper RM sequencing messages are sent.
((Closeable)proxy).close();
Reliable Request Response
The second scenario is a very typical use of reliable messaging, where the client sends a request to the service and expects a response. Both the request and response are protected with RM guarantees.
During testing, both the WCF and Metro clients and web services were found to correctly interoperate when playing the role of either sender or receiver in this scenario.
Test Description
A simple echo service forms the basis of these tests, where the client sends a request to the service using reliable messaging. A reliable messaging session is established and the service replies to the client's request. The tests are performed using a variety of protocol versions, including SOAP 1.1 and 1.2, with the latter being the standard, recommended protocol.
WCF Configuration Tips
Reliable messaging is not enabled by default in WCF. Enabling it requires a simple binding configuration, as shown below. Note that ordered delivery is an optional constraint that causes WCF to buffer messages so that they may be reordered before delivery to the application in case they don't arrive in the order they were sent.
<system.serviceModel> <bindings> <ws2007HttpBinding> <binding name="UseRM"> <reliableSession enabled="true" ordered="true" /> <security mode="None" /> </binding> </ws2007HttpBinding> </bindings> <services> <service name="MyService"> <endpoint address="MyService" binding="ws2007HttpBinding" bindingConfiguration="UseRM" contract="ISongService"/> </service> </services> </system.serviceModel>
Metro Configuration Tips
Follow the same guidelines as in the Reliable One Way scenario to configure a Metro endpoint for reliable messaging.
Reliable & Secure Request Response
This scenario couples the guarantees of reliable messaging (duplicate detection, acknowledgements, ordered delivery, and so on) with message-level security features (end-to-end authentication, integrity, and confidentiality). It is similar in all respects to the other RM scenarios with the exception that message-level security is also involved.
During testing, both the WCF and Metro clients and web services were found to correctly interoperate when playing the role of either sender or receiver in this scenario.
WCF Configuration Tips
To interoperate with Metro, a standard binding can be used, as shown below. Note that establishSecurityContext is set to "true", which instructs WCF to use WS-SecureConversation, which is required when using secure reliable messaging.
<bindings> <ws2007HttpBinding> <binding name="UseRM"> <reliableSession enabled="true" ordered="true" /> <message clientCredentialType="Certificate" establishSecurityContext="true" negotiateServiceCredential="false"/> </binding> </ws2007HttpBinding> </bindings>
Metro Configuration Tips
Metro version 2.0.1 or later is required for this scenario. Below is an example of a policy that enables reliable secure messaging.
<wsp:Policy wsu:Id="CustomBinding_IEcho5_policy"> <wsp:ExactlyOne> <wsp:All> <wsrmp:RMAssertion xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702"> <wsp:Policy> <wsrmp:DeliveryAssurance> <wsp:Policy> <wsrmp:ExactlyOnce/> <wsrmp:InOrder/> </wsp:Policy> </wsrmp:DeliveryAssurance> </wsp:Policy> <netrmp:InactivityTimeout Milliseconds="600000" xmlns:netrmp="http://schemas.microsoft.com/ws-x/wsrmp/200702"/> <netrmp:AcknowledgementInterval Milliseconds="200" xmlns:netrmp="http://schemas.microsoft.com/ws-rx/wsrmp/200702"/> </wsrmp:RMAssertion> <sp:SymmetricBinding xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> <wsp:Policy> <sp:ProtectionToken> <wsp:Policy> <sp:SecureConversationToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"> <wsp:Policy> <sp:RequireDerivedKeys/> <sp:BootstrapPolicy> <wsp:Policy> <sp:SignedParts> <sp:Body/> <sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing"/> <sp:Header Name="From" Namespace="http://www.w3.org/2005/08/addressing"/> <sp:Header Name="FaultTo" Namespace="http://www.w3.org/2005/08/addressing"/> <sp:Header Name="ReplyTo" Namespace="http://www.w3.org/2005/08/addressing"/> <sp:Header Name="MessageID" Namespace="http://www.w3.org/2005/08/addressing"/> <sp:Header Name="RelatesTo" Namespace="http://www.w3.org/2005/08/addressing"/> <sp:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing"/> </sp:SignedParts> <sp:EncryptedParts> <sp:Body/> </sp:EncryptedParts> <sp:AsymmetricBinding> <wsp:Policy> <sp:InitiatorToken> <wsp:Policy> <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"> <wsp:Policy> <sp:RequireThumbprintReference/> <sp:WssX509V3Token10/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:InitiatorToken> <sp:RecipientToken> <wsp:Policy> <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToInitiator"> <wsp:Policy> <sp:RequireThumbprintReference/> <sp:WssX509V3Token10/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:RecipientToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic128Rsa15/> </wsp:Policy> </sp:AlgorithmSuite> <sp:Layout> <wsp:Policy> <sp:Strict/> </wsp:Policy> </sp:Layout> <sp:IncludeTimestamp/> <sp:OnlySignEntireHeadersAndBody/> </wsp:Policy> </sp:AsymmetricBinding> <sp:Wss11> <wsp:Policy> <sp:MustSupportRefThumbprint/> </wsp:Policy> </sp:Wss11> <sp:Trust13> <wsp:Policy> <sp:MustSupportIssuedTokens/> <sp:RequireClientEntropy/> <sp:RequireServerEntropy/> </wsp:Policy> </sp:Trust13> </wsp:Policy> </sp:BootstrapPolicy> <sp:MustNotSendAmend/> </wsp:Policy> </sp:SecureConversationToken> </wsp:Policy> </sp:ProtectionToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic128Rsa15/> </wsp:Policy> </sp:AlgorithmSuite> <sp:Layout> <wsp:Policy> <sp:Strict/> </wsp:Policy> </sp:Layout> <sp:IncludeTimestamp/> <sp:OnlySignEntireHeadersAndBody/> </wsp:Policy> </sp:SymmetricBinding> <sp:Wss11xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> <wsp:Policy/> </sp:Wss11> <sp:Trust13 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> <wsp:Policy> <sp:MustSupportIssuedTokens/> <sp:RequireClientEntropy/> <sp:RequireServerEntropy/> </wsp:Policy> </sp:Trust13> <wsam:Addressing> <wsp:Policy> <wsam:AnonymousResponses/> </wsp:Policy> </wsam:Addressing> </wsp:All> </wsp:ExactlyOne> </wsp:Policy>
Conclusion
This whitepaper has taken a practical look at building interoperable web services and clients using WCF and Metro. The paper showed that it is possible and typically quite easy to build web services and clients in both WCF and Metro that interoperate with each other. The scenarios covered by this paper ranged from data type interoperability (Basic Profile) to secure and reliable services (Reliable Secure Profile). Where interoperability is a challenge, use the advice in this paper to get started. If you have a scenario that falls outside of the coverage of this paper, see if WS-I has a similar scenario and try configuring your system in a similar way.
Acknowledgements
This paper wouldn't be possible without the help of many people within Microsoft, Oracle, and ThoughtWorks. Thanks go out to Kent Brown, Doug Bunting, Colleen Evans, Mark Cowlishaw, Ram Jeyaraman, Monica Martin, and Asir Vedamuthu from Microsoft and to Harold Carr and Rama Pulavarthi, Marek Potociar, and V B Kumar Jayanti from Oracle.
Endnotes
[4] See http://msdn.microsoft.com/en-us/library/aa702621.aspx as well as http://learn.iis.net/page.aspx/764/ensure-security-isolation-for-web-sites/
[5] Learn more about WCF and certificates at http://msdn.microsoft.com/en-us/library/ms731899.aspx
[7] See http://weblogs.java.net/blog/2009/06/01/security-token-configuration-metro (particularly helpful is the section named, “Configuration for X509Token”)
[8] See the article referenced above for more details.
[10] See https://metro.dev.java.net/guide/Understanding_WSIT_Configuration_Files.html