我觉得这说起来很尴尬，但我无法真正理解身份的工作方式，我可以通过编程方式做几乎所有我需要的事情，但它只是没有走到一起
因此，例如，简而言之，如果我想将某人标记为管理员，我是否应该创建一个名为"IsAdmin"的声明
或名为"管理员"的角色？
还是我应该创建自己的身份用户并包含该属性
甚至覆盖 ClaimsPrincipalFactory 以将其作为声明包含在内(第三个选择中的属性)
所以我几乎可以用这 4 种方式做到这一点，但我不明白什么时候做什么，哪个更适合，或者它打算如何工作
如果您需要将某人标记为管理员，则意味着您需要保持该状态。保存用户管理员状态的最简单方法是将"角色"声明"admin"添加到数据库中的用户声明集合(通过使用 SQL 查询/简单控制台应用/或管理界面)。但这并不是保留用户管理员状态的唯一方法。您可以想象对应用程序有意义的任何持久机制，并使用第 4 个选项来创建标识。
然后确定用户在运行时是否为管理员。当用户登录时，他通常会获取附加到用户标识的用户持久声明集合。如果添加了角色声明，则可以阅读该声明以检查登录用户是否为管理员。如果依赖于确定用户是否为管理员的其他机制，则应查询这些资源以检查用户是否为管理员，并在运行时将相关声明添加到用户声明集合(通常在用户登录时完成)。当用户的声明通过添加默认和构造的自定义声明最终确定时，将使用包含所有运行时声明的 cookie 创建会话。然后，Web 应用将不需要查询用户持久状态，因为它现在可以通过在后续请求中使用 cookie 构造运行时声明集合。
-
我是否应该创建一个名为"IsAdmin"的声明？ 是的，如果它使您的授权代码更简单。但这种说法不应该坚持下去。当用户基于用户的其他持久属性/声明登录时，应构造它。
-
名为"管理员"的角色？ 是的，这是将用户标记为管理员的最常见方法。该角色可以保存到数据库中，并使用 asp.net 标识在运行时读取。
-
我是否应该创建自己的身份用户并包含该属性， 不可以，不应修改标识用户以包含经常更改的属性，如下所示。
-
甚至覆盖 ClaimsPrincipalFactory 以将其作为声明包含在内(第三个选项中的属性) 如果在创建用户标识之前需要访问其他资源，则可以采用此路由。例如，您已将用户的管理员状态保存在自己的映射表中。