WSE2 is already obsolete but I still see people trying to reach interoperability from WSE2 to WCF. Surprisingly there are a number of interesting ws-security scenarios where this is possible. Today I will discuss one scenario where it may be harder.
WSE configuration allows to configure the algorithms we use for encryption:
Some scenarios work great with RSA15 but when we change it to RSAOAEP we may see this exception from the WSE party:
Let's see what in the message that WCF sent to WSE may cause this:
We can see that the encryptedKey is indeed encrypted with the RSAOAEP algorithm. Also the RSAOAEP RFC states that:
Hence the DigestMethod element.
So why WSE throws an exception when a mandatory parameter is specified? Let's look at a WSE generated message to see if it produces anything different:
Looks the same to me. So let's drill down into the WSE stack to understand the root cause. The error seems to be thrown from within this method:
Ok so we are comparing the current message parameters (value) to some default value (this._parameters). But what is this default? Let's look in the ctor:
Oh boy. WSE2 compares xml fragments as strings! So it sees this:
as different from this:
While the above fragments have the same xml semantics.
Just in order to convince my self this is the issue, I have manually changed the soap so that it will have the WSE-style digest. This worked like a charm. This kind of gives us the general solution here which is to build a WSE filter that changes the soap format to the one WSe expects. Note that you can only change non-signed soap parts, which is usually the case with the encrypted key. The easier option of course is to revert to the RSA15 algorithm.
And let's not forget the main point which is to never compare xml as a string.
You may have experienced the first connection from a Wcf client to a service to be extremely slow. In some cases this is expected as the first connection establishes a session which may require exchange of multiple messages. However in some cases there is no obvious reason for that.
One cause may be a slow http proxy. By default, Wcf uses the default http proxy configured in internet explorer. The proxy may be specified directly or in form of a configuration script:
If this is the cause of the slowness you can reproduce it by surfing to any site using a new IE instance - same slowness should occur.
The possible solutions are:
1. Remove the proxy configuration from IE. 2. Configure your WCF binding with UseDefaultProxy=false.
A few days ago I published the below reflector generated code:
And asked what was the original code. Well, here it is:
no goto at all.
Liran and an anonymous reader corresponded that goto may not be that bad in all cases. They are right, loop controls such as break and continue are disguised goto's. Liran also mentioned the multi-level breaks in Java which satisfy some of the goto possible use cases. For me all of these are an attempt to capture the 'good' goto use cases and keep our code clean from possible abuse of the generic flavor.
My motivation for the whole inquiry was seeing a lot of goto's in framework code using the reflector. One example is BasicHttpMessageSecurity.CreateMessageSecurity(). I wanted to make sure I am up to the times with the latest coding fashions. When I have downloaded the WCF sources locally to debug them I no no sign of goto.
When you need to compare two Url's never trust on simple string comparison. Always use a comparison that takes semantics into consideration. In C#, System.Uri can be used. Check the below:
