IIS网站Intranet和匿名用户 [英] IIS site for both intranet and anonymous users

问题描述

我工作的一个应用程序，应提供给自己的账户（Windows身份验证）运行的内网用户。这是很容易配置和工作的。

现在，如果在没有登录用户的域（因为它们是场外或者没有登录的设备上），他们应该还是可以使用该应用程序，减去一些个性化的功能。

所以总结说起来，这是我想发生什么：

1. 用户打开应用程序。如果Windows凭据可在浏览器货物内他们IIS。


2. 如果用户凭据收到，应用程序在这些凭据运行（我已经得到了介绍）。


3. 如果用户凭据没有收到，IIS匿名帐户下运行应用程序和个性化的功能处于关闭状态（我已经得到了覆盖，以及）。

我不能去工作是选择性地发送凭据。如果我打开Windows身份验证，我会登录，这是罚款。但是如果我不尝试发送凭据访问该网站我会得到一个401，这是有道理的。于是我打开匿名身份验证，现在凭据不会发送。

这实际上是有意义的，因为IIS从不从浏览器的认证请求。现在的问题是，如何使这种情况下工作？

解决方案

您就在您的分析。
HTTP认证方案是：

• 匿名访问


• 质询 - 响应认证
  
  
  
  • 协商（Kerberos）
  
  
  • NTLM
  
  
  • 摘要
  
  


• 基本身份验证

在IIS（大多数HTTP服务器），默认的认证过程遵守上述顺序。 IE浏览器。如果匿名访问成功（不会进入细节在这里），即使它们已启用其他身份验证提供被忽略。

HTTP 401挑战

如果您要管理多个身份验证方法和供应商必须使用，当你考虑他们无效而拒绝凭据的机制。您可以通过发送 401 响应实现这一目标。这就是所谓的 HTTP 401挑战。

的想法是告诉给客户端（浏览器）与用于所请求资源的凭证被拒绝。

根据方案和客户端配置，客户端可以处理的认证。在这种情况下的认证过程可能会有所不同：质询 - 响应提供商需要一定数量的交流到有效的凭证

不管怎样，在你的情况下，启用匿名访问，第一个 401 响应会被浏览器PTED为此请求需要认证跨$ P $。服务器会自动包含在响应头所支持的身份验证提供，如果他们在服务器端启用。

  HTTP / 1.1 401未经授权
服务器：Microsoft-IIS / 7.5
WWW身份验证：协商
WWW验证：NTLM
WWW身份验证：摘要qop=\"auth\",algorithm=MD5-sess,nonce=\"+Upgraded+v1b3a89710edce01754fd608...\",charset=utf-8,realm=\"Digest\"
WWW身份验证：基本境界=主机
的X已启动方式：ASP.NET
内容长度：0
代理服务器的支持：基于会话的验证
 

如果您的浏览器配置正确发送凭据为Web应用程序的区域（你这么说的），它会自动使用它知道的第一个身份验证提供者（ NTLM 为例）和再处理与您的情况下，它知道凭据（Windows凭据请求）。

  GET HTTP：//host/yourpage.aspx HTTP / 1.1
接受编码：gzip，紧缩
授权：NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw ==
连接：保持活动
 

在验证过程失败，服务器会自动发送一个 403禁止响应客户端，以避免过多的流量。 A 403 停止响应的挑战。好消息是，它需要一些挑战发生了：4个以上。
通常，一个HTTP认证挑战，需要近3质询 - 响应的最大成功（3 NTLM 和2 协商-Kerberos - ）。

由于你允许匿名访问时，服务器不会阻止客户端的请求，你的网页将与匿名凭据调用。你可以与你的客户通过设置自己 HTTP响应code 仍互动在你的页面。前面已经说过，如果你能在另外的另一个身份验证提供者匿名。

其仅适用

所以，关键是用一个计数器来处理它在你的服务器端，并说：如果我的身份验证会话/ cookie的计数器超过3，我的客户端无法与服务器进行身份验证。比方说，他是匿名的。

有些code

我没有这样做正是你需要的，但你能适应我的code：

  INT I = 3;
    INT J = 0;
    的HttpContext的HttpContext = HttpContext.Current;    //记录认证过程
    的HttpCookie httpCookie2 = httpContext.Request.Cookies [loginAttemptCount];
    如果（httpCookie2 == NULL || httpCookie2.Value ==的String.Empty）
    {
        httpCookie2 =新的HttpCookie（loginAttemptCount）;
    }
    其他
    {
        J = Int32.Parse（httpCookie2.Value，System.Globalization.CultureInfo.InvariantCulture）;
    }    J =（J + 1）％I;    字符串用户= Request.ServerVariables [LOGON_USER];    //发送401响应用户进行身份验证
    如果（J = 0＆安培;！＆放大器;用户==的String.Empty）
    {
        httpCookie2.Value = j.ToString（System.Globalization.CultureInfo.InvariantCulture）;
        httpContext.Response.Cookies.Add（httpCookie2）;
        Response.Status code = 401;
        返回;
    }    httpCookie2.Value =的String.Empty;
    httpContext.Response.Cookies.Add（httpCookie2）;
 

如果需要，您可以检查授权头授权供应商。

  Request.Headers [授权]
 

您可以使用提琴手来追踪你的HTTP标头。

希望这是很清楚。

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:

1. User opens the application. If windows credentials are available the browser sents them to IIS.
2. If the users credentials are recieved, the application runs under these credentials (I've got that covered).
3. 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?

解决方案

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.

这篇关于IIS网站Intranet和匿名用户的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！