Hi All.
I’m debating a new article.
I’m currently debating whether to spend some time documenting an interesting solution to a fairly esoteric scenario. I’m not sure if it is worth the investment (in my time), so I’m going to throw it open to the community.
Give me feedback – if you have an interest in seeing this solution, please leave a comment. The only reason I mention this is because the solution is really quite interesting, and a good lesson in the rarer binding types (and message & transport security) in Windows Communication Foundation (WCF).
Here’s the premise:
We have a .NET 2.0 client (which can not be upgraded to 3.5 or 4.0) which must consume a web service by providing a Web Service Extension (WSE) 3 policy file – which stipulates a separate set of credentials (username/password/domain) for authentication in a downstream legacy system.
Presently, this client calls a series of legacy ASMX services (also .NET 2.0). However, there is a desire to upgrade these services to WCF (for more widespread use) and so we can take advantages of .NET 4.0 in the service implementation and beyond. The challenge is to provide the same functionality (policy file attached to the transport) for later authentication.
The information would be transmitted by HTTPs or via HTTP under a VPN (so, ultimately, encrypted). This is obviously a fairly intriguing paradigm, made more interesting by the prospect of actually not using the WSE3 policy information for handshake authentication.
The original design, from my understanding, was to make the passing of credentials transparent to the service calls themselves (hence, not passing username, password and domain per service call explicitly). I could be wrong about that, but in any case this is the scenario we have today.
Here’s where you fit in:
So, I repeat – who’d be interested in seeing the solution? Please leave a comment to indicate an interest. Depending on how much interest there is, I’ll put together both a long article and a sample, demonstrative, solution.
Cheers, R
