in .net基于声明的身份框架
如果我想限制用户进行操作（查看或编辑），请说一个帐户，一个特定帐户＃123456。（我说的是商业实体，就像一个银行帐户。）这是一个好主意为他们可以查看或编辑的每个帐户创建一个声明？
在一套中拥有大量索赔的任何缺点？系统管理员可以访问系统中的所有帐户，从而创建数百个声明（每个帐户可能超过一个）
答案 0 :(得分：13)
大型索赔集的最直接后果是性能降低，因为令牌在网络中所有相关系统之间来回交换。默认情况下，WIF会将令牌序列化并将其放入cookie中。因此在实践中，您在那里可以存储的数据量也受到限制。还有其他方法可以解决这个问题，但潜在的问题仍然存在。
第二个考虑因素是您将在何处以及在何处管理用户与帐户之间的关联。如果这是特定于应用程序的事情，则您不太可能将这些关联推送到中央STS（索赔发布者）。您最终将获得2个STS：识别用户（和身份提供商：IdP）的应用程序以及将IdP发出的令牌转换为应用程序未记录的内容（包括特定用户的帐户列表）的应用程序特定STS
话虽如此，可能是用户和他的帐户之间的联系可以在许多应用程序之间重用，然后将它放在专门的STS之后可能是有意义的。
第三个考虑因素是潜在的不必要的信息披露。应用程序可能只需要知道用户X是否可以访问帐户123.通过提供用户X可以访问的所有帐户的列表，您将披露所需的更多信息。
作为一般指导原则，声称“粗粒度”属性更好。在应用程序内部可以更好地处理“细粒度”访问控制，您可以使用基础结构优化。
这是一个极端的例子：想象一个文件系统。您会将索引编码为用户有权访问的文件的名称吗？不太可能，因为你最终可能会有数百万......
另一个极端的例子：如果您想在数据库中实现行级安全性。你会为每个用户编写row_id的索赔吗？不太可能，因为可能会有很多，它是非常特定于应用程序的，也因为使用数据库查询解决行过滤可能更容易（并且效率更高）（这是基础结构优化的一个示例）