3

我正在尝试在我的 WPF 客户端/服务器 (WCF) 应用程序中使用 Windows Identity Foundation 进行授权，该应用程序可能会或可能不会在与提供身份验证的活动目录相同的信任环境中运行。例如，认证可能由活动目录提供，但应用程序可能在云中运行，并且应用程序的用户配置文件角色/权限将由应用程序数据库提供。

为了完全理解我应该做什么，我觉得我在脑海中遗漏了 WIF 流程的一个基本部分：

  1. 用户使用 Active Directory 用户名/密码登录 Windows 域
  2. 用户打开我的应用程序。
  3. 我引用了登录用户的 WindowsIdentity，现在可以查看他们的登录令牌和所有配置的角色/声明 - 但就像他们可以登录域一样，他们可以登录到自己的机器并且仍然拥有 WindowsIdentity 令牌。
  4. 我可以将用户的 Windows 身份绑定到他们在我的数据库中的用户配置文件，并授予他们访问我的应用程序中他们的配置文件允许他们访问的特定功能的权限。

我缺少的部分是我有来自 WindowsIdentity.GetCurrent() 的这个 WindowsIdentity 实例......我如何验证是什么产生了这个？即它是本地机器用户还是活动目录用户，如果它是活动目录用户，我怎么知道它是我真正的活动目录服务器？

例如 - 几个场景：

方案 1

  1. 用户使用与我的活动目录域相同的名称来命名他们的本地计算机
  2. 用户在该计算机上创建一个本地用户，其用户名与他们知道存在于我的活动目录中的用户相同，该用户对我的应用程序具有完全管理访问权限。
  3. 他们登录到我的应用程序，并且出于所有密集目的，他们似乎具有相同的用户名，就好像管理用户登录到我的活动目录一样。

在这种情况下，用户有一个本地用户帐户，而不是 Active Directory 帐户，并且它有一个伪造的身份，旨在有目的地绕过应用程序安全性。

我假设有某种方法可以确定这是 Windows 本地用户帐户而不是 Active Directory 用户？我可以使用在 WindowsIdentity 中找到的用户名调用我的用户帐户的活动目录，并比较 SID 以确定这实际上是一个欺骗的用户帐户，并且应该拒绝用户访问。

这是正确的方法吗？有没有什么方法可以从 WindowsIdentity 中看出它是由我的活动目录发出的，并且这个身份没有被篡改？

方案 2

  1. 用户创建了一个与我的活动目录同名的欺骗活动目录服务器，并创建了一个模拟与场景 1 中描述的本地用户相同的过程的帐户。

现在我有一个具有相同域名和用户名的活动目录用户，我为方案 1 建议的相同解决方案也可以解决此方案的问题，但再次确定此令牌不是由我的活动创建的会很好目录只是通过检查令牌。

有人可以清除我缺少的东西 - 或者我是否缺少任何东西？我是否应该只调用 Active Directory 以验证提供的 WindowsIdentity 是否允许访问我的应用程序？

4

1 回答 1

1

简单的回答：您的活动目录不仅仅通过名称来识别。当您的计算机加入域时，它会交换一组凭据。欺骗活动目录或任何其他计算机比仅仅创建具有相同名称的计算机要困难得多。Windows 负责机器之间的所有幕后身份验证。除了错误和漏洞，您可以非常确定，当您调用 WindowsIdentity.GetCurrent() 时，会有一条由不同凭据支持的完整推力链来验证用户身份。

更完整的答案：有两种类型的 windows 身份验证：

  1. 第一种类型是在网络中的对等点之间（即域外）。在这种情况下，当计算机 A 中的用户连接到计算机 B 时，它实际上使用的是 B 的本地用户。如果 B 中的用户恰好与 A 中的用户具有相同的名称和密码，则无需用户干预即可进行身份验证。如果没有出现登录屏幕，用户需要为 B 中的某个用户提供凭据。无论如何，用户实际上是在登录计算机 B，而 B 不需要信任或知道计算机 A 中的本地使用。
  2. 第二种类型是在域中。我相信如果计算机本身属于域的一部分或与它有信任关系的域中，您只能从域中添加用户。在任何情况下，当计算机 B 将拥有一组不同的凭据时，它可以对域控制器进行身份验证。现在，当来自计算机 A 的用户想要登录计算机 B 时，它要求域控制器（它知道并信任）对用户进行身份验证。一旦从域控制器获得 OK，用户就会被接受。

Windows 支持各种用于身份验证的协议，其中一些协议比其他协议更新且更强大。网络管理员配置接受哪些协议。大多数（全部？）协议不涉及通过网络发送实际密码（查看摘要身份验证以获取此类协议的示例或阅读旧的 NTLM 协议）

于 2013-04-15T13:17:53.693 回答