Indigo and Cassini in Beta1

Visual Web Developer (the part of VS2005) ships with a stand-alone development web server that lets you develop websites without requiring the usage of IIS. I think the official name for this thing is the “ASP.NET Development Web Server”, but I usually refer to it by its code name, Cassini.

It’s possible to host Indigo services inside Cassini. However, there are a couple of “gotcha’s” about Cassini that you should be aware of. If you’re seeing MessgeSecurityExceptions on the client side to the effect of “The HTTP request is unauthorized with client authentication scheme `Anonymous`. The server authentication schemes are `NTLM`”,  you’re probably running into this.

There are two possible ways to fix this problem:

Option 1: Change the client binding to use NTLM authentication

The client bindings produced by Add Web Reference / svcutil.exe use Anonymous authentication by default. Since Cassini require NTLM authentication for all requests, the Indigo client must be configured to provide NTLM credentials with each request. This can be accomplished by opening up the client configuration file (web.config/app.config) and changing the httpTransport binding element to look like this:

                       authenticationScheme="Ntlm"   
                   bypassProxyOnLocal="false"
                   hostnameComparisonMode="StrongWildcard"  
                   mapAddressingHeadersToHttpHeaders="true"
                   proxyAuthenticationScheme="Anonymous"
                   realm=" transferTimeout="00:01:00"
                   useSystemWebProxy="true" />

That is, change the authenticationScheme attribute from “Anonymous” to “Ntlm”.

Option 2: Disable Cassini’s NTLM requirement on the server

This can be accomplished by going to the “Website” menu in Visual Studio and selecting “Start Options”. Uncheck the box for “NTLM Authentication” towards the bottom of the property page. This will disable Cassini’s NTLM requirement and allow anonymous access to your Indigo services.

Disabling this requirement at the server means that you don’t have to modify the client configuration in any way, but it does have possible security implications if your development machine isn’t insulated from external HTTP traffic by a firewall or NAT.

Choosing either Option 1 or Option 2 should fix your MessageSecurityException problems.