Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

preface: I am a web dev who knows apache servers quite well, but I have little to no knowledge of IIS or .NET

I work with a developer who has been avoiding a request to add a Basic Auth to a staging server running IIS for a while now. Today he finally added it, but added the message

IIS does not allow you to use basic auth and forms auth at the same time.

I got around this by installing a 3rd party process that lets you use .htaccess / apache modules in front of the iis modules.

It's a little more resource intensive on request but for staging it's not really critical.

My question is (since that explanation flies in the face of everything I know about web apps and separation of responsibilities) how can it be possible that IIS would prevent the use of Basic Auth on a site that uses a custom form auth for its users?

share|improve this question
up vote 3 down vote accepted

Basic Authentication is a term that generally refers to authentication within the HTTP protocol.

Forms based authentication is handled within context of a web-based application. This usually involves a form which sets some kind of session identifier with a cookie, and then when the form is processed information is associated with that session on the server side about the users state.

There really isn't any direct relationship between form based authentication which is basically tracked via the session cookie, and the HTTP-based authentication which is actually directly within the HTTP headers.

how can it be possible that IIS would prevent the use of Basic Auth on a site that uses a custom form auth for its users?

It has nothing to do with IIS preventing basic auth, it has to do with the two not being compatible. If you do your initial authentication with a form, then the associated login state will be stored in a session. But the software handling basic authentication doesn't normally know anything about cookies or sessions, all it knows about is HTTP authentication. When you let IIS perform the authentication stem, the authentication happens before your application is even touched.

If you use the built-in facilities of IIS for Basic authentication then you basically have to use that only.

But, it should be possible to implement HTTP authentication within your application by having your application send and parse the correct HTTP headers. For this you would leave IIS set to forms-based authentication, and then you simply do everything within your application. In that way it should be possible to have your application send out the proper headers depending on the session state.

share|improve this answer
thanks for the reply. I think you're basically confirming my initial suspicion, which is that HTTP auth is handled similarly to the way an apache server would handle it, in that the HTTP auth is a concern of the server, and the form auth is a concern of the app, and the fact that he needed to install 3rd party software to enable apache modules and htaccess in IIS is basically a workaround for not knowing what he is doing... – user128996 Jul 19 '12 at 22:28
Well it is handle the same way as Apache. If you use the mod_auth functionality then it will be incompatible with a session based authentication. But you can implement HTTP authentication within your application, and so you could possibly make the two work together, it just takes more work. – Zoredache Jul 19 '12 at 22:30

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.