身份逻辑概念和误解
identity logical concepts and misconcepts
我觉得这说起来很尴尬，但我无法真正理解身份的工作方式，我可以通过编程方式做几乎任何我需要的事情，但它只是没有融合在一起
例如，简而言之，如果我想将某人标记为管理员，我是否应该创建一个名为 "IsAdmin"
的声明
或名为 "Admin" 的角色？
或者我应该创建自己的身份用户并包含 属性
甚至覆盖 ClaimsPrincipalFactory 以将其作为声明包含（第三个选择中的 属性）
所以我几乎可以用这 4 种方法来完成，但我不明白什么时候该做什么，哪种更适合，或者它是如何工作的
如果您想将某人标记为管理员或任何其他责任或将来删除该责任，使用 Role 更有意义。当然，您可以自定义 IdentityUser 并添加 IsAdmin 属性，但看起来更像是硬编码，将来如果想要新的职责，您可以添加另一个 IsX 到 IdentityUser。
声明是名称值对，表示主题是什么，而不是主题可以做什么。例如，您可能拥有由当地驾驶执照颁发机构颁发的驾驶执照。您的驾照上有您的出生日期。在这种情况下，索赔名称将为 DateOfBirth，索赔价值将为您的出生日期。我在声明中存储了一些关于 UserId 的附加信息，而不是让用户从数据库中获取 UserId.
如果您需要将某人标记为管理员，则意味着您需要保持该状态。保存用户管理状态的最简单方法是向数据库中的用户声明集合添加一个 "role" 声明 "admin"（通过使用 SQL query/simple 控制台 app/or 和管理界面）。但这不是保持用户管理状态的唯一方法。您可以想象任何对您的应用程序有意义的持久机制，并使用您的第四个选项来创建标识。
然后是在运行时判断用户是否是管理员。当用户登录时，他通常会获得附加到用户身份的用户持久声明集合。如果您添加了角色声明，您可以阅读该声明以检查登录用户是否是管理员。如果您依赖其他机制来确定用户是否是管理员，您应该查询这些资源以检查用户是否是管理员，并在运行时将相关声明添加到用户声明集合中（通常在用户登录时完成）。当通过添加默认和构造的自定义声明最终确定用户的声明时，将使用包含所有运行时声明的 cookie 创建会话。然后 Web 应用程序将不需要查询用户持久化状态，因为它现在可以通过在后续请求中使用 cookie 来构建运行时声明集合。
我应该创建一个名为 "IsAdmin" 的声明吗？
是的，如果它使您的授权代码更简单。但不应坚持这种说法。应该是用户登录时根据用户其他持久化的properties/claims构造的
一个角色叫"Admin"？
是的，这是将用户标记为管理员的最常见方式。该角色可以保存到数据库并在运行时使用 asp.net 身份读取。
我是否应该创建自己的身份用户并将其包括在内属性，
不，您不应该修改身份用户以包含像这样经常更改的属性。
甚至覆盖 ClaimsPrincipalFactory 以将其包含为声明（第三个选择中的 属性）
如果您需要在创建用户身份之前访问其他资源，则可以采用此路线。例如，您已将用户的管理状态保存在您自己的映射中 table.
我觉得这说起来很尴尬，但我无法真正理解身份的工作方式，我可以通过编程方式做几乎任何我需要的事情，但它只是没有融合在一起
例如，简而言之，如果我想将某人标记为管理员，我是否应该创建一个名为 "IsAdmin"
的声明或名为 "Admin" 的角色？
或者我应该创建自己的身份用户并包含 属性
甚至覆盖 ClaimsPrincipalFactory 以将其作为声明包含（第三个选择中的 属性）
所以我几乎可以用这 4 种方法来完成，但我不明白什么时候该做什么，哪种更适合，或者它是如何工作的
如果您想将某人标记为管理员或任何其他责任或将来删除该责任，使用 Role 更有意义。当然，您可以自定义 IdentityUser 并添加 IsAdmin 属性，但看起来更像是硬编码，将来如果想要新的职责，您可以添加另一个 IsX 到 IdentityUser。
声明是名称值对，表示主题是什么，而不是主题可以做什么。例如，您可能拥有由当地驾驶执照颁发机构颁发的驾驶执照。您的驾照上有您的出生日期。在这种情况下，索赔名称将为 DateOfBirth，索赔价值将为您的出生日期。我在声明中存储了一些关于 UserId 的附加信息，而不是让用户从数据库中获取 UserId.
如果您需要将某人标记为管理员，则意味着您需要保持该状态。保存用户管理状态的最简单方法是向数据库中的用户声明集合添加一个 "role" 声明 "admin"（通过使用 SQL query/simple 控制台 app/or 和管理界面）。但这不是保持用户管理状态的唯一方法。您可以想象任何对您的应用程序有意义的持久机制，并使用您的第四个选项来创建标识。
然后是在运行时判断用户是否是管理员。当用户登录时，他通常会获得附加到用户身份的用户持久声明集合。如果您添加了角色声明，您可以阅读该声明以检查登录用户是否是管理员。如果您依赖其他机制来确定用户是否是管理员，您应该查询这些资源以检查用户是否是管理员，并在运行时将相关声明添加到用户声明集合中（通常在用户登录时完成）。当通过添加默认和构造的自定义声明最终确定用户的声明时，将使用包含所有运行时声明的 cookie 创建会话。然后 Web 应用程序将不需要查询用户持久化状态，因为它现在可以通过在后续请求中使用 cookie 来构建运行时声明集合。
我应该创建一个名为 "IsAdmin" 的声明吗？ 是的，如果它使您的授权代码更简单。但不应坚持这种说法。应该是用户登录时根据用户其他持久化的properties/claims构造的
一个角色叫"Admin"？ 是的，这是将用户标记为管理员的最常见方式。该角色可以保存到数据库并在运行时使用 asp.net 身份读取。
我是否应该创建自己的身份用户并将其包括在内属性， 不，您不应该修改身份用户以包含像这样经常更改的属性。
甚至覆盖 ClaimsPrincipalFactory 以将其包含为声明（第三个选择中的 属性） 如果您需要在创建用户身份之前访问其他资源，则可以采用此路线。例如，您已将用户的管理状态保存在您自己的映射中 table.