Wcf trick: Dynamically change proxy address

@YaronNaveh

It is quite common to have a few service environments, for example one for testing and one for production. One way to switch a Wcf client from one environment to another is by changing the address in app.config:

<endpoint address="http://localhost/Service.svc" ... />

However sometime we need to dynamically change the address from code due to some logic.
The naive approach would be to do something like this:

MyService client = new MyService("WSHttpBinding_MyService",
        "http://new_server/Service.svc")

The reason this is naive is that app.config may contain additional information on the endpoint, namely its identity and headers:

<endpoint address="http://localhost/Service.svc" Name="WSHttpBinding_MyService" ...>
   <identity>
     <dns value="ServerIdentity"/>
   </identity>
</endpoint>

when we create the proxy with a different endpoint in the constructor we override the identity information. This may result in this error:

Identity check failed for outgoing message. The expected DNS identity of the remote endpoint was 'localhost' but the remote endpoint provided DNS claim 'ServerIdentity'. If this is a legitimate remote endpoint, you can fix the problem by explicitly specifying DNS identity 'ServerIdentity' as the Identity property of EndpointAddress when creating channel proxy

The solution
Create the proxy normally. Then separately assign the new endpoint address keeping the identity and header values:

proxy.Endpoint.Address = new EndpointAddress(
    new Uri("http://new_server/Service.svc"),
    proxy.Endpoint.Address.Identity,
    proxy.Endpoint.Address.Headers);

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!

Wcf and WebLogic security interoperability

@YaronNaveh

Yesterday I have mentioned some recent white papers about web services interoperability.
Today I've stumbled in another recent article which shows username over certificate interoperability between Oracle WebLogic Server 11g and Microsoft.NET WCF 4.0. This article has step by step instructions to make it happen.

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!

Web services interoperability white papers

@YaronNaveh

A few years ago a white paper on web services interoperability would start with "turn off secure conversation" or "avoid the following types". A recent set of white papers published by Microsoft shows the today all vendors are much more mature and ready for real world interoperability.

Abu Obeida and Mike Champion from Microsoft announced recently the below articles. I recommend this reading for those of you who need to write interoperable web services. Of course not each article is relevant for each interop scenario so guess what? I've read them for you so you can decide which ones are relevant for you.

Data types interoperability between .NET and Java
Christian Weyer and Buddhike de Silva have listed most types you might ever want to use with web services and verified their interoperability status. This is a must read for every public facing web service developer.
One thing that I am missing here though is the Axis2 java stack which is very popular. Also I'm confused by the check on WebSphere - as an application server you can use various stacks on it so I'm not sure which one was used. I assume Wcf was used on the .Net side (".Net 4" is specified) and I'm very curious if the data contract was able to cope with all scenarios or was xml serialization required in some cases. Generally data contract are optimized to enforce "best practice" which is sometimes counterproductive for interoperability.

The conclusion is very promising - good interoperability exists in almost all scenarios. One important reminder is the lack of interoperability with Hashtable and some of the generic types.

Security Interoperability Guideline between WCF-WIF and Oracle WebLogic

Jesus Rodriguez wrote a great article on ws-security interop between Wcf and Oracle WebLogic. Naturally the article dives into the ws-security details and is very technical. It proves that X.509 message security is a good option for interoperability. While jesus shows how to achieve federation interoperability via SAML and WS-Trust, it is clear that there is still a way to go here as a holder-of-key scenario is still not possible. I have not tested it myself but hopefully bearer tokens should also work well with these parties. The article does not mention it as it deals with message security while bearer tokens are a mix of message and transport.

Security Interoperability Guideline between WCF-WIF and IBM WebSphere Application Server

Jesus adds another good one and this time on interoperability between Wcf and WebSphere. The username and x.509 scenarios work pretty well. The article mentions that WS-Trust interoperability is possible, but does not give the details, so I'm not sure if it is a mistake in the upload or if it really required some tweaks which were out of scope. Either way this is yet another proof that there is still a way to go with federation interoperability. Such security scheme will be very popular in the cloud era so hopefully all vendors will keep investing in it. As it stands now Wcf+Wif have great support for the related scenarios so I'll report on any news from the other vendors.

As a side note, While MTOM interoperability is possible here, I have seen in the past a few gotchas so hopefully a future paper will cover that up (I'll try to write about it myself actually).

Standards-Based Interoperability between SAP NetWeaver and Microsoft .NET Framework
A rich set of scenarios are working in this case, including security and MTOM. It is a little disappointing that a basic scenario like custom headers only partially pass, but NetWeaver is an opinionated framework that expose its users only what is relevant for them.

Metro to WCF Interoperability
The combination of Metro and Wcf shows off the richest set of working interoperability scenarios. This is not surprising considering the fact that one of the goals of WSIT (Metro's security stack) is interoperability with Wcf.

To conclude, all articles are very interesting and show that interoperability is a reality.

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!

Silverlight 5: More details on WS-Trust support

@YaronNaveh

Yesterday Microsoft had announced Silverlight 5 Beta to be released in the first half of 2011. Sure, there are plenty of great features there, but if you are readers of my blog I'm sure you are especially interested in a particular one. Here is a hint (click to enlarge):

Yes, more of the WS-* stuff is making its way into SL.

While this is all good news, the announcement is missing more details as for what exactly will be supported. This post will analyze the status of SL & WS-Trust in SL 4 + following unofficial projects, and based on the missing gaps I will try to estimate what the upcoming release *might* include.

Background - Federation and WS-Trust
This post is not aimed to be an introduction to federation or to claims based programming, but as a quick reminder here is the general flow:

Our environment contains:

Application Service. This service contains some operations that clients want to consume. The service will only accept client requests that embed a token gotten from the STS (usually a Saml token, which is an Xml token format). One reason might be that the service does not want to deal with authentication and leaves this mission to the STS which is developed by a dedicated team.

STS. STS role is to authenticate clients and generate tokens that the client can present to the service. This is a little oversimplified, mainly since there are some STS that only aim to provide client identity, and some that provide protection over the resource (service), and in many cases both of them will be used.

Client. The client is any application (client or server) that wants to consume the application service and needs to get a token from the STS first. The client is of course not necessarily using Silverlight.

Needless to say is that Wcf is a great framework for such scenarios.

How Silverlight fits this picture?

A lot of organizations already have security infrastructure that contains STS. They would like SL applications to work with it also, mainly so SL applications can call other web services which expects a Saml identity.

What is the current status of SL & WS-Trust (SL4+ unofficial projects)

Until the beginning of 2010 there was no built-in support for such scenarios, and some creative solutions were used. Earlier this year Caleb Baker had disclosed a project that brings WIF support to SL as part of the identity developer training kit. WIF is (among other stuff) a set of extensions to WCF that makes working with claims easier. Since Saml is very aligned with the claims model, and STS usualy emits Saml over WS-Trust protocol, this effectively brought WS-Trust support for SL for the first time.

What *might* SL5 support?
In other words we need to ask what is missing after the mentioned WIF support.

As far as I know the mentioned support was not official but a part of a training kit. Many organization will not use it until it is official.

WIF generally work on XP only. I say "generally" because the WIF/SL seems to be standalone so I'm not sure if that's the case with it also. Anyway since SL is not windows-only we will probably get this subset of WIF on all platforms.

WIF works well, but it is a different programming model than the Wcf WSFederation binding. Possibly Microsoft will consider supporting the native Wcf model as well.

STS is not limited to bearer tokens as the current WIF implementation is. This is actually an SL limitation since it only supports a subset of the Wcf bindings and most of the X.509 certificate settings are not supported. Microsoft might consider to support more bindings which might be used to communicate with the STS / application service.

The current training kit does not natively support multi leg federation (e.g. more than one STS), although dominick had published the a way to fix it.

Again, these are just my guesses / wish-list, but either way this is great news for every silverlight developer.

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!