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