如何说服 Internet Explorer 允许以其他用户身份进行身份验证？

Question

感谢您的阅读和您的想法；这是一个棘手的问题，所以我想我应该分享一下，看看这对于比我们更有经验的开发人员来说是否真的是一个公平的挑战。

我们正在为企业 Microsoft Active Directory 环境开发一个 Web 应用程序，并使用 IIS 提供的 Windows 身份验证以及表单身份验证来对用户进行单点登录身份验证。我知道当两者都启用时 IIS 会抱怨，但它工作得很好，而且我们部署的每个站点都没有需要解决的奇怪问题 - 直到现在。

新站点拥有“共享”计算机，使用通用帐户永久登录，该帐户对他们需要使用的应用程序具有只读访问权限。这意味着我们无法区分应该对应用程序具有不同权限的用户；我们需要某种方式提示用户输入身份验证详细信息。

第一次尝试是认真的谷歌搜索；世界上似乎没有其他人遇到我们的问题，除了一些被误导的灵魂，他们向以太提出问题但没有得到回应。

经过一番集思广益并弄清楚 IIS 身份验证的工作方式后，解决该问题的最直接方法似乎是发出 401 Unauthorized 来响应已知为共享帐户的用户。这里的初步测试似乎卓有成效，在浏览器内成功更改了用户名，但是该网站的原型没有提示输入凭据，并且浏览器保留了相同的帐户详细信息。我们还研究了 IE 特定的 JavaScript

document.execCommand("ClearAuthenticationCache")

，它在实验室中工作，但在现场却不起作用。现场对 IE 安全设​​置的进一步实验表明，如果 webapp 站点被排除在 Intranet 区域之外，浏览器将自动重新进行身份验证，无论使用何种方法欺骗浏览器提示用户输入新帐户详细信息。

现在我们被困住了。我们有解决方法可以让其按时进行，但它们绝对不是“正确”的答案：

• 要求用户在登录我们的应用程序之前注销共享帐户（...恶心）
• 从 Intranet 中排除我们的 Web 应用程序所有计算机上的区域都
• 为用户提供非 SSO 登录服务，

我相信有一种规范的方法可以做到这一点 - 一种已知的模式，一个已经解决的常见基本问题，类似的东西 - 我非常感兴趣听听有哪些创造性的方法可以解决此类问题，以及是否有其他人实际上曾经经历过类似的事情。

Answer 1

我们最终确定了一个解决方案，将查询提交到服务器知道的 LDAP 目录。这意味着必须接受用户的密码，但没有其他解决方案足以在生产环境中运行。

希望这对某人有帮助。需要 .NET Framework 3.5+。

using System.DirectoryServices.AccountManagement;

private static bool IsLdapAuthenticated(string username, string password)
{
    PrincipalContext context;
    UserPrincipal principal;

    try
    {
        context = new PrincipalContext(ContextType.Domain);
        principal = Principal.FindByIdentity(context, IdentityType.SamAccountName, username) as UserPrincipal;
    }
    catch (Exception ex)
    {
        // handle server failure / user not found / etc
    }

    return context.ValidateCredentials(principal.UserPrincipalName, password);
}

Answer 2

您无法创建一个拒绝共享帐户访问的页面吗？然后，在需要用户使用非共享帐户重新进行身份验证的任何时候，重定向到该页面，并在查询字符串中编码返回 URL？这应该会触发浏览器显示通常的登录对话框。

用户重新进行身份验证后，新页面应该重定向回查询字符串中的返回 URL。