当我的系统不使用“用户名”时如何实现 IIdentity？

Question

我很惊讶 .NET 中的 IIdentity 接口对主机安全环境做出了某些设计假设，第一是系统使用名称。

我认为这对大多数应用程序来说是有意义的，尤其是传统的计算机安全，其中每个用户都有一个用户名作为其主要标识符，当然在 NT 上 SId（NT 安全标识符）是真实 ID。

此设计假设用户名是不可变的：当用户的用户名同时更改时会发生什么？ IIdentity.Name 属性是只读的，因此在代码中是不可变的。

但主要是，该设计还假设完全使用用户名。如果系统避免使用基于字符串的名称并使用基于整数的显式用户 ID，或者像 GUID 这样更奇特的东西，那又会如何呢？将其实现为String Name { get { return this.UserId.ToStringInvariant(); } } 感觉不对。

更深入地讲，如果当前安全上下文不仅取决于用户的身份验证详细信息，还取决于他当前的客户端软件、网络位置和其他方面，您如何处理“复合身份”？当然，这些可以被认为只是更多的声明示例（我很感激 ClaimsIdentity 现在是 .NET 4.5 中的基本实现），但是如果你有一个复杂的声明，那么声明都是基于 .NET 4.5 中的 string对象图作为声明的一部分，您需要将其转换为某种字符串表示形式（或Claim.Properties 中的二维字符串表示形式）并希望有效。

在老式的 .NET 1.0-3.5 中，我只需通过返回 Name 的用户名来实现 IIdentity（幸运的是，我从事的每个项目都至少有一些类似的用户名，有时非常脆弱），然后在我的实现中添加额外的“声明”作为强类型属性，包括复杂的对象图属性值。

...那一定是正确的吗？ .NET 中是否有任何基础架构代码对IIdentity 的性质做出假设？

Answer 1

IIdentity 接口不对用户名采用任何格式，它实际上只是身份的唯一标识符，因此任何字符串（如 GUID）都可以使用。在 .Net 4.5 中，我们有声明提供程序，允许您仅使用用户名（唯一 id）和称为声明的键/值对集来表示身份。是的，键/值分解是一堆非常松散的数据，但它具有灵活性的优势，允许身份系统以接收应用程序（也称为依赖方）需要的任何方式向身份添加声明。从 .Net 4.5 开始，框架中依赖 IIdentity 的任何类也应该描述需要存在哪些声明，并且您可以配置身份提供程序以添加这些，或使用声明提供程序基础结构在身份验证期间添加它们或授权。