在 .net 基于声明的身份框架中
如果我想限制用户对某个帐户（特定帐户#123456）执行操作（查看或编辑）。（我说的是商业实体，例如银行帐户。）创建索赔是个好主意吗对于他们可以查看或编辑的每个帐户？
一组中有很多索赔有什么缺点吗？系统管理员可能有权访问系统中的所有帐户，从而创建数百个声明（每个帐户可能不止一个）
大型索赔集最直接的后果是性能下降，因为令牌在网络上所有涉及的系统之间来回交换。例如，默认情况下，WIF 会序列化令牌并将其放入 cookie 中。因此，在实践中，您可以存储的数据量也受到限制。还有其他方法可以解决这个问题，但根本问题仍然存在。
第二个考虑因素是您将由谁以及在哪里管理用户和帐户之间的关联。如果这是一个特定于应用程序的事情，您不太可能将这些关联推送到中央 STS（声明发布者）。然后，您最终将得到 2 个 STS：一个用于识别用户（和身份提供商：IdP）的一个，另一个是应用程序特定的 STS，该 STS 会将 IdP 颁发的令牌转换为应用程序所支持的内容（包括特定用户的帐户列表）
话虽如此，用户与其帐户之间的关联可能是可以在许多应用程序中重复使用的东西，那么将其放在专门的 STS 后面可能是有意义的。
第三个考虑因素是潜在的不必要的信息披露。应用程序可能只需要知道用户 X 是否有权访问帐户 123。通过提供用户 X 有权访问的所有帐户的列表，您将公开更多所需的信息。
作为一般准则，声明更适合“粗粒度”属性。 “细粒度”访问控制可能在应用程序内部得到更好的处理，您可以在其中使用基础设施优化。
这是一个极端的例子：想象一个文件系统。您会将用户有权访问的文件的名称编码为声明吗？不太可能，因为你最终可能会拥有数百万......
另一个极端的例子：如果您想在数据库中实现行级安全性。您会将每个用户的 row_id 编码为声明吗？再次不太可能，因为可能有很多，它是非常特定于应用程序的，而且还因为使用数据库查询解决行过滤可能更容易（而且更有效）（这是基础设施优化的示例）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
