SeeAlso: EDRADesignNotes

Summary: Using WSE 2.0 with the EDRA

We’re currently working on analyzing the WSE 2 feature scenarios and trying them with the EDRA through various proof of concepts to determine what (if anything) would be good to do to ensure that WSE 2 features can fully work and integrate smoothly with the EDRA. For the EDRA 1.0 we didn't specifically test it with WSE 2 features, so that is why we decided to state that WSE 2 support will be part of 1.1, because we'll have had a chance to analyze and test the scenarios.

Though for the most part our proof of concepts have shown that there isn't really much necessary to support it, and some customers using EDRA are already using WSE with the ASMX interface transport. Because WSE and the EDRA both work primarily through a SOAP extension, the WSE features and plug-ins occur when the WSE SOAP extension is called, then the EDRA gets executed when its SOAP extension gets called, and they don’t seem to conflict with each other.

A specific example is with the WSE security feature to verify the digital signature of SOAP messages using a user name and password. You create a ""UsernameTokenManager"" derived class, then add a <securityTokenManager> element to your Web.config, which makes the WSE SOAP extension call your class. In your ""UsernameTokenManager"" derived class you verify the username token (as shown in the WSE docs). So it effectively all happens in the WSE SOAP extension before the EDRA SOAP extension gets invoked. The one additional thing in the ""UsernameTokenManager"" class that would make sense is setting the ""Thread.CurrentPrincipal"" to a ""GenericPrincipal"" with the identity name from the username token. The EDRA authorization handlers key off of the ""Thread.CurrentPrincipal"", so that would allow you to still use those.

Theoretically you could create EDRA handlers that make it unnecessary to use WSE filters for such things as WS-Security authentication. While in some cases it may not be difficult to do something like that, it generally wouldn't be compelling to do so. We don't see anything wrong with applying WSE filters before EDRA for handling these features. Our perspective is basically that we see three types of cross cutting responsibilities in your service: transport, boundary, and implementation.
- Transport responsibilities are tightly coupled to the transport mechanism and mostly relate to the deserialization and interpretation of the message.
- Boundary responsibilities are normally unrelated to the transport (maybe some boundary rules are due to the nature of who/what uses that transport, but not strictly based on the transport technology itself), and generally are for "doorway" behavior such as validating and authentication (i.e. things you want to do before you let them in the door).
- Implementation responsibilities are for the fulfillment of the services duties. So for example if you need all orders to be audited, you can include an auditing handler.

Using WSE filters for transport responsibilities seems fine. The EDRA service interface tier is intended for your boundary responsibilities, and the service implementation tier is intended for your implementation responsibilities. There also isn't a compelling need to make all handlers/filters run only in a single pipeline (WSE or EDRA).

Now something like a WSE filter for authentication is essentially fulfilling a mix of transport and boundary responsibilities (since it is extracting/deserializing the user credentials from the request and verifying they are correct), but being super strict about who handles what responsibilities is overkill if it is excessively inconvenient to prevent it. Another example is MSMQ doesn't have a pipeline you can use for transport responsibilities, so instead of creating an MSMQ pipeline, you could use the EDRA service interface pipeline for that even though it would technically be transport specific (our signed message authentication handler is an example of this).