【问题标题】:Should I store user data as claims or in a user profile table?我应该将用户数据存储为声明还是用户资料表?
【发布时间】:2015-09-04 12:16:50
【问题描述】:

我正在开发一个面向公众的系统,理想情况下该系统会增加大量流量。这都是 c# .net 工作。

我正在使用基于声明的身份,因此我目前正在使用用户声明表来存储用户数据,但随着用户群的增长,我觉得这将变得太慢而无法支持流量。我正在考虑可能创建一个用户配置文件表来水平存储非安全相关数据,而不是像索赔表中那样垂直存储,只在索赔表中留下安全数据。

这是解决问题的合理方法吗?任何人都可以分享他们对此类场景的经验中的一些见解吗?

更新

我的问题不在于随用户身份传递的 JWT 令牌的大小。我的问题是关于严格使用“UserClaim”表以 Claim 形式存储 ALL 的用户数据,而不是使用 UserProfile 或类似的表来存储某些东西,以及正如发现“此数据进入索赔表与此数据进入配置文件表”之间的正确平衡。

【问题讨论】:

  • 您确定索赔数量/尺寸是问题所在吗?这会让我大吃一惊。在这种情况下,您可以使用 WIF 的小型会话 cookie 解决方案。它使用本地存储来存储声明,并且只是会话 cookie 中的指针/键/引用。

标签: c# .net security claims-based-identity user-profile


【解决方案1】:

我建议只将数据保留在用于授权决策的令牌中,而不是使用用户配置文件信息来膨胀令牌。

令牌有效的时间戳、令牌的目标受众、用户名、用户组和角色等信息。请参阅here 了解更多信息。

在您的令牌中保留个人资料信息将强制您的应用程序在任何信息发生更改时获取新令牌。令牌通常会在其生命周期内被缓存,以防止必须比需要更频繁地重新发行它们。

【讨论】:

  • 对,但我的问题与 JWT 本身并没有太大关系,因为我可以处理通过客户端范围传输的声明。我只是在谈论用户数据,比如说“家乡”或从 Facebook 个人资料中挑选任何东西。我想知道他们是否有一个配置文件表来将非 FK 存储在每个用户的单个记录中,或者他们是否在声明表中添加了“家乡”作为实际声明。或者两者都有?
  • 我不知道FB是怎么做到的。我认为他们有类似用户表的东西,其中包含所有与用户相关的信息,但其他信息(例如角色)将来自不同的表。在 ADFS 中,您可以根据声明选择要从 AD 查询的属性或要针对 SQL 执行的查询。
猜你喜欢
  • 2016-01-08
  • 2016-06-14
  • 2011-03-19
  • 2011-09-24
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-02-27
相关资源
最近更新 更多