IIS site for both intranet and anonymous users - asp.net

Question

I'm working on an application that should be available to intranet users running under their own account (Windows authentication). This is easily configured and works.
Now if users are not logged in to the domain (because they are off site or on a device that is not logged in) they should still be able to use the application, minus some personalized functionality.
So to sum that up, this is what I would like to happen:
User opens the application. If windows credentials are available the browser sents them to IIS.
If the users credentials are recieved, the application runs under these credentials (I've got that covered).
If the users credentials are not recieved, the application runs under the IIS anonymous account and personalized functionality is turned off (I've got that covered as well).
What I can't get to work is to optionally send the credentials. If I turn on windows authentication, I'll be logged in, which is fine. However if I try to access the site without sending credentials I'll get a 401, which makes sense. So I turn on anonymous authentication and now credentials are never sent.
This actually makes sense, because IIS never requests for authentication from the browser. The question is, how do I make this scenario work?

Answer 1

You are right on your analysis.
HTTP authentication schemes are :
Anonymous access
Challenge-Response authentications
Negotiate (Kerberos)
NTLM
Digest
Basic authentication
On IIS (and most HTTP servers), the default authentication process respect the order above. ie. If anonymous access succeeded (will not get into details here) others authentication providers are ignored even if they are enabled.
HTTP 401 Challenge
If you want to manage multiple authentication methods and providers you have to use a mechanism which refuse the credentials when you consider them invalid. You can achieve this by sending 401 Responses. This is called HTTP 401 Challenge.
The idea is to tell to the client (browser) that the credentials used for the requested resource are refused.
Depending on the scenario and the client configuration, the client may handle an authentication. And in this case the authentication process may vary : Challenge-Response providers needs a certain number of exchanges to valid the credentials.
Anyway, in your case, with anonymous access enabled, the first 401 response will be interpreted by the browser as "This request requires an authentication". The server automatically include the supported authentication providers in the response header if they are enabled on the server side.
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/7.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Digest qop="auth",algorithm=MD5-sess,nonce="+Upgraded+v1b3a89710edce01754fd608...",charset=utf-8,realm="Digest"
WWW-Authenticate: Basic realm="host"
X-Powered-By: ASP.NET
Content-Length: 0
Proxy-Support: Session-Based-Authentication
If your browser is correctly configured to send the credentials for the zone of your web application (you said so), it'll automatically use the first authentication provider it knows (NTLM for example) and re-process the request with the credentials it knows (Windows credentials in your case).
GET http://host/yourpage.aspx HTTP/1.1
Accept-Encoding: gzip, deflate
Authorization: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==
Connection: Keep-Alive
When the authentication process fail, the server automatically send a 403 Forbidden response to the client to avoid too much traffic. A 403 response stops the challenge. The good news is it takes some challenge to happen : more than 4.
And usually, an HTTP authentication challenge needs near to 3 Challenge-Response maximum to succeed (3 for NTLM and 2 for Negotiate -Kerberos-).
Since you allow anonymous access, the server will not block the client requests and your pages will be called with anonymous credentials. You can still interact with your client in your page by setting yourself the HTTP Response Code. As already said, its only works if you enable another authentication provider in addition to Anonymous.
So the trick is to handle it with a counter on your server side and say "if my auth session/cookie counter is more than 3, my client can't authenticate with the server. Let's say he is anonymous".
Some Code
I didn't do exactly what you need but you can adapt my code :
int i = 3;
int j = 0;
HttpContext httpContext = HttpContext.Current;
// Record authentication process
HttpCookie httpCookie2 = httpContext.Request.Cookies["loginAttemptCount"];
if (httpCookie2 == null || httpCookie2.Value == String.Empty)
{
httpCookie2 = new HttpCookie("loginAttemptCount");
}
else
{
j = Int32.Parse(httpCookie2.Value, System.Globalization.CultureInfo.InvariantCulture);
}
j = (j + 1) % i;
string user = Request.ServerVariables["LOGON_USER"];
// Send 401 responses to authenticate the user
if (j != 0 && user == String.Empty)
{
httpCookie2.Value = j.ToString(System.Globalization.CultureInfo.InvariantCulture);
httpContext.Response.Cookies.Add(httpCookie2);
Response.StatusCode = 401;
return;
}
httpCookie2.Value = String.Empty;
httpContext.Response.Cookies.Add(httpCookie2);
If needed, you can check the authorization provider in the Authorization header.
Request.Headers["Authorization"]
You can use Fiddler to trace your HTTP headers.
Hope it's clear enough.