【问题标题】:How to Store / Retrieve a Large Number of User Identity Claims如何存储/检索大量用户身份声明
【发布时间】:2018-03-09 19:13:42
【问题描述】:

我有一个发布到 Web 服务器场的 ASPNET CORE 2.0 网站。我正在使用身份角色/用户声明进行授权。我有大量与登录用户相关的声明,这使应用程序 cookie 的大小膨胀。我看到了一些处理这种情况的技术,但不确定该采取什么途径。

  • 使用自定义ClaimsTransformer:在身份角色/用户声明表之外创建自定义数据库存储,并在TransformAsync 上加载声明。我不确定是否有更好的解决方案不涉及每次往返服务器的数据库调用。
  • 在指定ApplicationCookie 时指定分布式缓存会话存储。我不确定这是否能解决臃肿的 cookie 问题。
  • 使用粘性会话来存储用户声明。我认为这不适用于索赔授权 ([Authorize])

当用户有大量声明时,如何跨多个 Web 服务器使用基于声明的身份?

【问题讨论】:

    标签: c# asp.net-core asp.net-core-2.0 claims-based-identity amazon-elastic-beanstalk


    【解决方案1】:

    Cookie 大小基本上是反对“一切都作为声明”的最有力论据,这很不幸,因为该模型运行良好,否则(我一直站在你的立场上)。正如您所怀疑的,最好的方法是将您的声明限制在最低限度,并根据需要使用身份(主题 ID)从数据库中检索更详细的应用特定信息。

    如果数据库响应时间是一个问题,您基本上会回到有状态会话数据。 Microsoft 可能会引导您使用 Redis 内存缓存。不确定这是否是亚马逊上的一个选项,我使用 Azure。

    我尝试了ClaimsTransformer 例程,但不断解决“这真的是索赔还是我们将其视为索赔?”变得更大的麻烦。而不是仅仅将真实 IDP 声明的持久性/检索与内部应用程序级用户数据分开。

    【讨论】:

    • 为了确认我理解您的建议,您已经放弃使用基于声明的授权,而是使用数据库或 Redis 根据需要查找授权?
    • 不,我使用基于声明的授权,但我在 cookie 级别保留和/或共享的唯一声明是来自身份提供者 (IDP) 的原始基本声明列表。这里我说的是 IdentityServer4 的 OAuth2 类型的情况,但它通常适用于基于声明的身份验证。将其限制为用户的唯一标识符,可能还有一些有用的值,例如电子邮件地址和电话号码。其他所有内容都以相关方式存储。
    • 我想换一种说法,我的用户存储与我的声明存储是分开的(但依赖于)。用户身份(作为“主题 ID”)是两者的关键值。对于第三方 IDP(如 Google 或 Microsoft),保留并跟踪 IDP 主题 ID,但生成您自己的内部主题 ID 以链接到您的用户存储和其他用户数据。这样您的用户就可以轻松迁移到其他 IDP。
    • 您使用什么技术在商店中查找声明以获得授权?您是否有自定义授权属性来执行工作,而不是使用 ClaimsTransformer 注入声明?
    • 我正在使用IdentityServer4,所以就声明而言,我只是将商店注册为具有IS4定义的持久性接口的服务,并且IS4使用它。在客户端,只要我使用内置的登录/注销方法,声明就会通过 ASP.NET Core 的 OIDC 中间件自动加载,因此我只需检查 User 以确定它们是否是经过身份验证以及声明是什么等等。这样就很自动了。
    猜你喜欢
    • 1970-01-01
    • 2016-02-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-11-30
    • 2022-12-11
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多