How to remove unwanted WWW-Authenticate headers

Question

From an MVC app, I'm sourcing an iCal subscription with authentication following the answer to this SO question:

Serving an iCalendar file in ASPNET MVC with authentication

The iCal stream is being created dynamically from events in the DB using the DDay.iCal library.

This solution works fine on the local development server: both OSX Calendar and Outlook can subscribe to and receive updates from the app.

However, on the shared server at my web host, the authentication fails for both Calendar and Outlook. That is, they both keep asking me for user & password after the (correct) ones fail.

EDIT: If I point a browser at the calendar URL it also fails authentication.

EDIT: Getting weirder—Firefox authenticates and gets the iCal file. Safari, Chrome and IE fail authentication.

If I point curl at the calendar URL with the same credentials I'm successful (i.e. I get the desired iCal file). And, of course, the same credentials can be used to login to the MVC app.

EDIT — I think I know what's going on, but I don't know how to fix it. In my OnAuthorization() I add only WWW-Authentication Basic but with Fiddler I can see that three types of authentication are offered:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Secure Calendar"
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
... etc ...

At this point only Firefox responds with Basic Authorization, which succeeds.

GET <<URL>> HTTP/1.1
...
Authorization: Basic <<encoded credentials>>

IE responds with Negotiate, which fails

GET <<URL>> HTTP/1.1
...
Authorization Negotiate <<encoded stuff>>

Who is adding the other two and how can I make it stop? Here's more detail from the server response:

HTTP/1.1 401 Unauthorized
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 3.0
WWW-Authenticate: Basic realm="Secure Calendar"
X-AspNet-Version: 4.0.30319
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
X-Powered-By-Plesk: PleskWin
Date: Tue, 23 Oct 2012 13:27:48 GMT

Thanks, Eric

Answer 1

Ha ha, the answer lay in IIS configuration.

I asked the admins at my host to turn off the other authentications, which broke everything but the iCal feed.

Now they've turned a couple back on again and the MVC site works as well as the calendar feed with authentication... whew! Very, very big smile.

Here's the IIS configuration we ended up with:

Name                        Status         Response Type
Anonymous Authentication    Enabled
ASP.NET Impersonation       Disabled
Basic Authentication        Disabled       HTTP 401 Challenge
Digest Authentication       Disabled       HTTP 401 Challenge
Forms Authentication        Enabled        HTTP 302 Login/Redirect
Windows Authentication      Enabled        HTTP 401 Challenge

I'm not sure why this works—or what else might break—but today I'm happy.