ASP.Net Identity和IdentityServer4声明

Question

我正在使用IdentityServer4作为OIDC提供程序和ASP.NET Core 2.0。

我已经浏览了几篇文章，以确保IdentityServer发出的声明最终出现在ClaimsPrincipal中（即Auth Cookie），并设法通过ClaimsAction过滤来实现这一点。

但是，我的问题是...当使用ASP.NET Identity（和EF后备存储）运行IdentityServer时，ASP.NET Identity属性如何映射到IDS4返回的声明。默认情况下，IDS4返回诸如...的声明。

• “ sub”：来自IdentityUser.Id
• “名称”：来自IdentityUser.UserName
• “ preferred_username”：来自IdentityUser.UserName
• “电子邮件”：来自IdentityUser.Email
• “ email_verified”：来自IdentityUser.EmailConfirmed

我问这个的原因是我想作图

• “ given_name”：来自IdentityUser.FirstName（扩展属性）
• “ family_name”：来自IdentityUser.LastName（扩展属性）

因为在请求PROFILE范围时，默认情况下IDS4似乎不执行此操作。

另外，我想问一下存储用户属性的最佳实践。使用ASP.NET Identity DB时，将创建两个表...

• AspNetUsers
• AspNetUserClaims

因此，最佳实践是将其他用户属性添加为...

1. IdentityUser上的属性（作为新字段添加到AspNetUsers中）或...
2. AspNetUserClaims中的其他声明（可以在注册或登录时使用UserManager.AddClaimAsync（）添加这些声明）

Answer 1

如何将用户属性映射到声明

正如您自己回答的那样，应该以编程方式映射扩展属性。

• 如果要向AspNetUsers表中添加列，请扩展IdentityUser类（例如public class MyApplicationUser : IdentityUser），然后添加自定义属性（例如FirstName）。这实质上改变了模型。为确保 EF 将您的模型更改写入 DB 表，您需要IdentityDbContext使用新MyApplicationUser类扩展该类。
• 如果您希望将用户的自定义声明（例如hair_color）添加到AspNetUserClaims表中，您需要调用userManager.AddClaimAsync(). 您可以在注册过程或登录过程中使用表单中的数据或从外部身份验证提供商（如 Google、Facebook、Twitter 等）收到的数据执行此操作。

但是，正如您在我对您的其他问题的回答中所读到的那样，我认为您不应该映射它们，而应立即声明它们。

在哪里存储用户属性

我发现您的其他问题更有趣：要添加哪些属性AspNetUsers以及何时添加AspNetUserClaims？

编辑：更新的答案

经过一些讨论，我可能会说，主要考虑因素是：

• ASP.NET Identity 作为用户数据主要来源的属性应该是强类型数据库列（通常在 中AspNetUsers）并在创建主体时传播到声明（必要时）。
• 从另一个来源导入和更新的属性可以立即传播到 DB ( AspNetUsersClaims) 中的声明。

例子：

• 如果hair_color是用户在此身份接口中输入和更改的属性，则将其存储在强类型数据库列中。
• 如果hair_color是在另一个应用程序中维护并从那里更新的属性，我会将其存储为声明表中的记录。

在我编写原始答案（如下）的情况下，要共享的用户数据是从另一个（主要）来源间接更新的，但对于身份验证详细信息，ASP.NET Identity 是主要来源。所以它导致了相同的分布，但出于不同的原因。

原答案

据我了解，经验法则是：

• （仅）用于与其他应用程序（用户信息）共享的数据应该是受保护的身份资源，因此在AspNetUsersClaims.
• 功能上用于身份验证的数据 (authentication-info) 应该是用户 ( AspNetUsers) 的一部分，因此数据用于：标识、登录、恢复、2-fact 等（例如用户名、密码、电子邮件、电话）

例子：

• 如果你想添加一个DateOfBirth我会把它添加到AspNetUsersClaims（除非你打算以某种方式使用它进行身份验证/登录）
• 如果您想存储与帐户/登录相关的数据，accountExpiresDate或者CreatedFromIP您将其添加到AspNetUsers（并扩展IdentityUser）

因此，如果您使用 aUserClaimsPrincipalFactory将用户属性添加到您的用户声明中，您可能只是将该属性添加到错误的表中！

TLDR

我实际上再次发现了您的问题，同时我自己也对此感到疑惑。我开始使用上面的经验法则，但问题不断出现，因为很多例子都没有遵循这个规则。例如，Microsoft 有一个建议添加Name 和 DOB的示例，这似乎与此矛盾。然而，OpenID的已经定义了这些性能（AO）为标准的权利要求中任选的profile范围：birthdate, name, family_name, given_name, middle_name, nickname, preferred_username。