ASP.Net Identity和IdentityServer4声明 [英] ASP.Net Identity and IdentityServer4 Claims

查看:244
本文介绍了ASP.Net Identity和IdentityServer4声明的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I'm using IdentityServer4 as an OIDC provider and ASP.NET Core 2.0.

我已经浏览了几篇文章,以确保IdentityServer发出的声明最终出现在ClaimsPrincipal(即Auth Cookie)中,并设法通过ClaimsAction过滤来使它工作.

I have gone through several posts to ensure that the claims issued by IdentityServer end up in the ClaimsPrincipal (ie Auth Cookie), and have managed to get this working with ClaimsAction filtering.

但是我的问题是... 当使用ASP.NET身份(和EF后备存储)运行IdentityServer时,如何将ASP.NET身份属性映射到IDS4返回的声明.默认情况下,IDS4返回诸如...的声明.

However my question is this ... When running IdentityServer with the ASP.NET Identity (and EF backing store), how do the ASP.NET Identity properties get mapped to the claims returned by IDS4. By default, IDS4 returns claims like ...

  • "sub":来自IdentityUser.Id
  • 名称":来自IdentityUser.UserName
  • "preferred_username":来自IdentityUser.UserName
  • 电子邮件":来自IdentityUser.Email
  • "email_verified":来自IdentityUser.EmailConfirmed

我问这个的原因是我想映射

The reason I ask this, is that I would like to map

  • 给定名称":来自IdentityUser.FirstName(扩展属性)
  • 家庭名称":来自IdentityUser.LastName(扩展属性)

因为在请求PROFILE范围时,默认情况下IDS4似乎没有执行此操作.

as IDS4 does not appear to do this by default when requesting the PROFILE scope.

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

In addition, I would like to ask what would be best-practice for storing user properties. When using the ASP.NET Identity DB, two tables are created ...

  • AspNetUsers
  • AspNetUserClaims

因此,最好的做法是将其他用户属性添加为...

So would it be best practice to add additional user properties as ...

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

推荐答案

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

当您回答您自己时,应该以编程方式映射扩展属性.

How to map user-properties to claims

As you answered yourself, the extended property should be mapped programmatically.

  • 如果要向AspNetUsers表中添加列,请扩展IdentityUser类(例如public class MyApplicationUser : IdentityUser),然后添加自定义属性(例如FirstName).这实质上改变了模型.为了确保EF将模型更改写入数据库表,您需要用新的MyApplicationUser类扩展IdentityDbContext类.
  • 如果要将用户的自定义声明(例如hair_color)添加到AspNetUserClaims表中,则需要调用userManager.AddClaimAsync().您可以在注册过程或登录过程中使用表单中的数据,或从外部身份验证提供商(例如Google,Facebook,Twitter等)收到的声明中进行此操作.
  • If you want to add columns to the AspNetUsers table, you extend the IdentityUser class (e.g. public class MyApplicationUser : IdentityUser), then add your custom properties (eg FirstName). This essentially changes the model. To ensure that EF writes your model changes to the DB table, you need to extend the IdentityDbContext class with your new MyApplicationUser class.
  • If you want custom claims for the user (e.g. hair_color) to be added to the AspNetUserClaims table, you need to call userManager.AddClaimAsync(). You could do this during the registration process or login process with data from the form, or from claims received from external auth providers such as Google, Facebook, Twitter etc.

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

But, as you can read in my answer to your additional question, I think you should not map them, but make them claims right away.

我发现您的另一个问题更有趣:要添加到AspNetUsers的哪些属性以及何时添加到AspNetUserClaims的属性?

I found your additional question more interesting: what properties to add to AspNetUsers and when to AspNetUserClaims?

讨论,我可能会说,主要考虑因素是:

After some discussion, I would probably say, that the main consideration would be:

  • 以ASP.NET身份作为用户数据主要来源的属性,应强类型化数据库列(通常在AspNetUsers中),并在创建主体时传播到声明(必要时).
  • 从另一个来源导入和更新的属性可以立即传播到数据库(AspNetUsersClaims)中的声明中.
  • Properties for which ASP.NET Identity is your primary source of user data should be strongly typed database columns (typically in AspNetUsers) and propagated to claims (when necessary) when creating the principal.
  • Properties imported and updated from another source can be propagated to claims in the DB (AspNetUsersClaims) right away.

示例:

  • 如果hair_color是用户在此标识界面中输入和更改的属性,则将其存储在强类型数据库列中.
  • 如果hair_color是在另一个应用程序中维护并从那里更新的属性,我会将其作为记录存储在Claims表中.
  • if hair_color is a property entered and changed by the user in this identity-interface, you store it in a strongly typed database column.
  • if hair_color is a property maintained in another application and updated from there, I would store it as a record in the claims-table.

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

据我了解,经验法则是:

As I understand it, the rule of thumb is:

  • (仅)旨在与其他应用程序(用户信息)共享的数据应被保护为身份资源,因此在AspNetUsersClaims中声明.
  • 功能上用于认证的
  • 数据(authentication-info)应该是用户(AspNetUsers)的一部分,因此用于以下各项的数据:标识,登录,还原,2事实等(例如用户名,密码,电子邮件) ,电话)
  • data that is (only) meant for sharing with other applications (user-info), should be protected identity resources, hence claims in AspNetUsersClaims.
  • data that is functionally used for authentication (authentication-info) should be part of the user (AspNetUsers), so data for: identification, login, restore, 2-fact, etc. (e.g. username, password, email, phone)

示例:

  • 如果要添加DateOfBirth,请将其添加到AspNetUsersClaims(除非您打算以某种方式使用它进行身份验证/登录)
  • 如果要存储与accountExpiresDateCreatedFromIP之类的帐户/登录相关的数据,请将其添加到AspNetUsers(并扩展IdentityUser)
  • if you want to add a DateOfBirth I would add it to AspNetUsersClaims (unless you intend to use it for authentication/login somehow)
  • if you want to store account/login-related data like accountExpiresDate or CreatedFromIP you add it to AspNetUsers (and extend IdentityUser)

因此,如果您使用UserClaimsPrincipalFactory将用户属性添加到用户声明中,则可能只是将该属性添加到了错误的表中!

So if you use a UserClaimsPrincipalFactory to add a user-property to your user-claims, you may just be adding the property to the wrong table!

当我自己对此感到疑惑时,我实际上找到了你的问题.我开始使用上述经验法则,但是这个问题不断出现,因为许多示例未遵循该法则. 例如. Microsoft有一个示例,建议添加 profile范围:birthdate, name, family_name, given_name, middle_name, nickname, preferred_username.

I actually found your question, while wondering about this myself, yet again. I started using the above rule of thumb, but the question kept coming up, because a lot of examples don't follow this rule. E.g. Microsoft has an example suggesting to add Name and DOB, which seems to contradict this. However, OpenID already defines these properties (a.o.) as standard claims in the optional profile scope: birthdate, name, family_name, given_name, middle_name, nickname, preferred_username.

这篇关于ASP.Net Identity和IdentityServer4声明的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆