I mentioned in a previous posting that all dispatching in WSE 2.0 uses EndpointReferences from WS-Addressing. I also mentioned that we had extended the definition of an EndpointReference in the programming model to include the notion of transport address. Here's an overview of the mechanism.
In the simplest case, EndpointReference.Address is both the name of the target and its location. For example, http://localhost/myservice can be used as a name and a transport address. However, now that WSE 2.0 has a model to allow a single SoapService to be hosted on multiple transports we needed a mechanism to distinguish between these instances but still apply a single policy for them. In addition, the demise of WS-Routing left us looking for a means to refer to a service by name and then discover its location. Finally, in the case of the soap.tcp transport, we wanted users to have a means of specifying which network interface a particular SoapService was bound to - this is important in the case of multi-homed machines. Enter EndpointReference.Via.
Let's assume that you have a service that has a well-known name, for example urn:MyService. You now want to host that service so that it is accessible using the soap.tcp transport. Constructing an EndpointReference using the two URI's below will name the service and specify the transport that it is hosted on:
The soap.tcp transport will start a listener for the IP Any address on the machine and will accept messages sent to urn:MyService on any interface. Moreover, the policy engine will enforce policies for the endpoint named urn:MyService irrespective of which transport the message arrived on.
Now lets assume that:
As a sender of a message, you can also use two URI's to specify where WSE should deliver the message. Using the first two URI's given above, the <wsa:To> header will contain urn:MyService but the message will be sent using a connection to soap.tcp://mycomputer. Note that the EndpointReference.Via in this case is not part of the SOAP message itself, it is simply used to specify the transport address. However, when the message is received, the soap.tcp transport will inject a Via address based on the network interface that the message arrived on. It will then proceed to use both the <wsa:To> header and the generated Via to dispatch the message - only a SoapService registered with a matching Addresss and Via will receive the message.
The Via does not have to be specified directly at the sender, instead WSE 2.0 will use the ReferralCache to try to find a transport address if one is not specified. This mechanism is almost exactly the same as was used for the WS-Routing and WS-Referral implementation in WSE 1.0. A similar model is used with the built-in HTTP router: a message arrives with only a <wsa:To> header, the router takes that and uses its ReferralCache (or your override) to determine the next hop for the message.
Since <wsa:FaultTo>, <wsa:ReplyTo> and <wsa:From> are also EndpointReferences, a sender can specify a transport address in any of these and, in that case, it is carried in the message as part of the {any} element construct allowed in the EndpointReference schema.
For services that are not registered using SoapReceivers.Add - ASMX services or SoapServices using ASP.NET - you can use the SoapActor attribute to specify the name of the service. WSE 2.0 will ensure that a message arriving over HTTP has a <wsa:To> header that matches the value of this attribute if it is present, or matches the value of the request URL. Since the policy engine uses the <wsa:To> header to select the appropriate rules to enforce, this check prevents a sender from trying to use <wsa:To> to select an incorrect, possibly weaker, policy when the message is delivered. Note that this check means that you must use EndpointReference.Via if you plan to intercept messages using a tracing tool - if you don't the <wsa:To> header won't match the request URL when it is forwarded by the tracer and the message will be failed at the receiver.
WSE 2.0 also includes a new configuration entry, allowRedirectedResponses, that determines whether Via information included in <wsa:ReplyTo>, <wsa:FaultTo> or <wsa:From> headers is obeyed - the default for this setting is false. If you enable it, you must perform adequate verification of a signature over the value of the Via or you may be opening yourself up to becoming a reflector in an attack against another machine.
Finally, custom transport authors need to be aware of the processing that is required for EndpointReference.Via in order to ensure correct processing and protect the integrity of services; more on that in another entry later.
Posted by herveyw at May 7, 2004 10:47 PMThis comment is about Secure Conversation. When initiating a secure conversation, if using code instead of policy, I create a RequestSecurityContextTokenClient with a base token (UsernameToken) and a proof token (X509SecurityToken). When I look at the message sent for RSTR, the username and password is not encrypted bu default but I can use code the encrypt the BaseToken. My question is how can I do this with policy?
Another question: if I decide to write a custom SecurityContextToken derived from SecurityContextToken class that carries extra properties, I will need to have a new SCT class, a new SCTManager, and a new SCTService. Do I need to to create a new SCTClient since the existing one only deal with the base SCT? How about anything related to policy? Or else how does it know to use my custom SCT class?
I have some customers who are very sensitive to standards. Are "soap.tcp" and DIME on some standard track? And if yes, which one?
On a more technical issue. Can I use a single TCP connection to send two-way asynchronous messages between the two communicating entities? And if yes, how can that be described in WSDL? (Both sides would provide the same service, callable by the other side - think "chat").
And finally, is there a "secured" version of soap.tcl using SSL, or something alike to encrypt traffic. If yes, how to describe that (i.e. http vs. https).
Thanks,
-max