限制对记录的访问。基于声明的权限是个好主意吗
在.net 基于声明的身份框架中
如果我想限制用户对一个帐户（特定帐户）执行操作（查看或编辑）#123456。（我说的是商业实体，例如银行帐户。）是为他们可以查看或编辑的每个帐户创建一个声明是个好主意吗？
一组中有很多索赔有什么缺点吗？系统管理员可能有权访问系统中的所有帐户，从而创建数百个声明（每个帐户可能不止一个）
in .net Claim-based identity framework
If i wanted to restrict users to do an operation (view or edit) on let's say an account, a particular account #123456.(i am talking about business entity, like a bank account.) Is it a good idea to create a claim for each account they can view or edit?
Any disadvantages of having a lot of claims in a set? a system admin might have access to all accounts in the system thus creating hundreds of claims (maybe more than one for each account)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
大型索赔集最直接的后果是性能下降，因为令牌在网络上所有涉及的系统之间来回交换。例如，默认情况下，WIF 会序列化令牌并将其放入 cookie 中。因此，在实践中，您可以存储的数据量也受到限制。还有其他方法可以解决这个问题，但根本问题仍然存在。
第二个考虑因素是您将由谁以及在哪里管理用户和帐户之间的关联。如果这是一个特定于应用程序的事情，您不太可能将这些关联推送到中央 STS（声明发布者）。然后，您最终将得到 2 个 STS：一个用于识别用户（以及身份提供商：IdP）的一个，另一个是应用程序特定的 STS，该 STS 将把 IdP 颁发的令牌转换为应用程序所支持的内容（包括特定用户的帐户列表）
话虽如此，用户与其帐户之间的关联可能可以在许多应用程序中重用，那么将其放在专门的 STS 后面可能是有意义的。
第三个考虑因素是潜在的不必要的信息披露。应用程序可能只需要知道用户 X 是否有权访问帐户 123。通过提供用户 X 有权访问的所有帐户的列表，您将公开更多所需的信息。
作为一般准则，声明更适合“粗粒度”属性。 “细粒度”访问控制可能在应用程序内部得到更好的处理，您可以在其中使用基础设施优化。
这是一个极端的例子：想象一个文件系统。您会将用户有权访问的文件的名称编码为声明吗？不太可能，因为您最终可能会拥有数百万...
另一个极端的例子：如果您想在数据库中实现行级安全性。您会将每个用户的 row_id 编码为声明吗？再次不太可能，因为可能有很多，它是非常特定于应用程序的，而且还因为使用数据库查询解决行过滤可能更容易（并且更有效）（这是基础设施优化的示例）
The most immediate consequence of a big claimset is lower performance as the token is exchanged back and forth between all involved systems across the network. By default, WIF, for example, serializes the token and puts them in cookies. So in practice, you are also limited in the amount of data you can store there. There are other ways of dealing with this, but the underlying problem persists.
The second consideration is who and where will you manage the association between the user and the account. If that's an application specific thing, it is unlikely you will push those associations to a central STS (issuer of claims). You will end up then with 2 STS: the one that identifies users (and Identity provider: IdP) and an application specific STS that will transform the token issued by the IdP into something the app undertsands (including the account list for a particular user)
Having said that, it might be that the association betwen a user and his accounts is something that is reusable among many applications, then it might make sense to put it behind a specialized STS.
There's a third consideration which is the potential unnecesary disclosure of information. The application might only need to know if user X has access to account 123. By providing a list of all accounts user X has access to you are disclosing more information that is needed.
As a general guideline claims are better for "coarse grained" attributes. "Fine grained" access control is probably better handled inside the app where you can use infrastructure optimizations.
Here's an extreme example: imagine a file system. Would you encode as claims the names of the files a user has access to? Unlikely, because you might end up with millions...
Another extreme example: if you wanted to implement row level security in a database. Would you encode as claims the row_id's for each user? Unlikely again, because there could be a lot, it is very application specific and also because it is just probably easier (and far more efficient) to solve the row filtering with a database query (this is an example of infrastructure optimization)