Pages

Thursday, June 12, 2014

This is a guest post by Isaac Kleinman about web services interoperability with eMedNy

I was recently tasked with building a SOAP Client to consume some services provided by eMedNy, New York State Dept. of Health's electronic Medicaid system. While eMedNy provides a number of web services for providers such as medical and prescription history etc., my project focuses on their subscriber (patient) eligibility service. Once you manage to successfully communicate with the service, the actual exchange consists of submitting an X12-formatted 270 file which is an eligibility request and receiving a 271 (eligibility response) in return.

Working with this arcane format is challenging in its own right and is more than worthy of its own post. However, configuring the certificates and structuring the SOAP security message headers proved to be even more challenging. I still haven't completely gotten my mind around the concept, but apparently the service was written in Java and uses WS-Security to define its security policy. It's possible that building a client in Java is a smooth process, but doing so in .NET proved to be a quite complicated ordeal. While I can't fully explain all the details of the issues at hand, I can, at least, describe the steps I took to get my project up and running. Yaron Naveh was extremely helpful at each step of the way; hat-tip to him.

Officially, Microsofts's `svcutil` utility was supposed to do all the magic for me: just provide the WSDL URL and the appropriate proxy and config files get generated and you're good to go. This was far from the case. Here's what happened when I ran `svcutil`:

The generated `output.config` file contains a similar error:

Now, I haven't even gotten clarity yet as to what exactly this error message means or what is causing it, but as you can see, due to the error, not much configuration is happening here at all. Thus, I don't include this file in my project.

As an aside, the proxy file, `MHService.cs`, contains a whopping 55K loc. Most of this is not relevant to the services I'm using. (I suspect I only need about 30 of those lines, but I haven't gotten to sifting it yet.)

After making that change, running the program should give you this error:

Unhandled Exception: System.ServiceModel.Security.MessageSecurityException: The incoming message was signed with a token which was different from what used to encrypt the body. This was not expected.

For some reason, WCF is not properly identifying the server certificate token. Hard as I tried, I have not (yet) been able to figure out how to tweak the configuration to overcome this issue. As a last resort, I had no choice but to roll my own custom encoder. The code is based on the examples provided on MSDN, but I've tried to remove a lot of the parts that are not needed for our case, so that it's somewhat more obvious what the code does.

So here is the CustomTextMessageBindingElement class:

here is the CustomTextMessageEncoderFactory class:

and, finally, here is the actual CustomTextMessageEncoder class. The `ReadMessage` method is where the decryption takes place. I intend to make the method a bit neater using the `EncryptedXml` class, but here it is for now:

At this point, we can go back to the configuration code and replace the use of the default encoder:

Thanks for a very nice post.. This helped me along my way a lot! I am trying to make a client for a service for energy, meter readings, in NL. They also have a response that is not encrypted with my signing certificate.

There are, of course, some differences... The response looks different and a general tip for people who want to use this is to capture a response (using the WCF tools or by just putting a break point in the custom MessageEncoders ReadMessage method and examine the content of the "doc" variable.

In my case there were namespace differences and my service also returned a KeyIdentifier, along with the CipherValue, in the EncryptedKey tag. So I had to use "CipherValue[0]" = Key and "CipherValue[1]" = Message.