手动Windows身份验证

Question

我目前正试图弄清楚如何在我们的ASP.NET应用程序中执行手动Windows身份验证.问题是我们运行了OData服务,并使用FormsAuthentication提供通用登录机制并允许OData的PUT和DELETE谓词,包括表单重定向.

但是,对于某些客户,我们集成了Windows身份验证,以便用户可以使用活动目录顺利集成.现在的问题是我们希望能够在不破坏Odata服务的情况下切换身份验证方法,因为我们依赖它.

我们要做的是使用IhttpModule模仿Windows身份验证机制.到目前为止,我们能够打开和关闭该功能,并且在发出请求时我们会遇到挑战.我不知道的是如何使用从浏览器接收的信息对活动目录执行身份验证:

这是我们用于从当前请求中提取NTLM信息的代码:

/// <summary>
/// <para>Determines whether the current <see cref="HttpRequest"/> is a NTML challenge.</para>
/// </summary>
/// <param name="request">The <see cref="HttpRequest"/> to evaluate.</param>
/// <param name="header">The output header to authenticate.</param>
/// <returns>True if the current <see cref="HttpRequest"/> is considered a NTML challenge.</returns>
 protected bool IsNtlmChallenge(HttpRequest request, out string header)
 {
      const string headerName = @"Authorization";
      if (request.Headers.AllKeys.Contains(headerName))
      {
           header = request.Headers[headerName];
           return true;
      }

      header = string.Empty;
      return false;
 }

这允许我们从请求中提取标头.我现在需要知道的是我如何在活动目录上执行此身份验证.

这是我们用来提取信息的逻辑:

// Check if we need to handle authentication through Windows authentication or not.
if (WindowsAuthentication)
{
    string encryptedHeader;

    // If this is a challenge from the client, perform the Windows Authentication using the 
    // information stored inside the header.
    if(IsNtlmChallenge(HttpContext.Current.Request, out encryptedHeader))
    {
         /* how to authenticate here with the encrypted header? */
    }

    HttpContext.Current.Response.AddHeader("WWW-Authenticate", "NTLM");
    HttpContext.Current.Response.StatusCode = 401;
    return;
}

希望有人能提供我需要的anwser.

Answer 1

好吧，

根据收到的对我的问题的评论，我提出了以下解决方案来绕过我遇到的问题。我知道这不是一个干净的解决方案，但至少它对我们有用。

• 创建一个在您的应用程序内运行的新 Web 应用程序
• 该子应用程序依赖于 Windows 身份验证
  • 禁用匿名身份验证和表单身份验证
• 创建处理 Windows 身份验证的 Login.aspx 页面
• 我们在登录后生成一个 cookie 并重定向到原始应用程序
• 原始应用程序识别 cookie 并获取用户。

这要求我们为两个应用程序生成相同的加密和解密密钥。这可以使用 IIS 管理器中的机器密钥模块为您的应用程序进行设置。如果两个应用程序的密钥不相等，则 cookie 的编码/解码过程将失败。我们将它们设置为使用 SHA1 自动生成，但两个应用程序的密钥相同。

现在我们检查原始登录页面上的设置，如果需要Windows身份验证，则重定向到子应用程序的登录页面并在那里执行登录。然后我们重定向回原来的登录页面并使用 cookie 继续。

这会导致在初始登录时发生一些重定向，但之后应用程序运行得像以前一样顺利。