限制访问记录。索赔是基于权限的好主意 [英] Restricting access to records. Is claim-based permissions a good idea

问题描述

在.NET要求为基础的身份架构

in .net Claim-based identity framework

如果我想限制用户做的，让我们说，一个账户，特定账户＃123456的操作（查看或编辑）。（我说的商业实体，就像一个银行账户。）这是个好主意为每个帐户，他们可以查看或编辑索赔？

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)

推荐答案

的一个大claimset最直接的结果是较低的性能作为令牌交换来回通过网络所有涉及的系统之间。默认情况下，WIF，例如，序列化令牌并将它们放在饼干。因此，在实际应用中，也仅限于数据可以存储在那里的​​量。有处理这个其他的方法，但根本问题依然存在。

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.

第二个要考虑的是谁，你会管理用户和帐户之间的关联。如果这是一个专用的事情，但是您可能会推动这些协会的中央STS（债权的发行人）。您将结束，然后用2 STS：识别用户的一个（身份提供：IDP）和一个特殊应用的STS，将改变由IDP发出令牌弄成该应用undertsands（包括特定用户帐户列表）

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)

说了这么多，这可能是介乎用户和他的帐户关联的东西是在许多应用程序可重复使用的，那么它可能是有意义的把它放在后面一个专门的STS。

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.

还有第三个考虑是潜在的unnecesary披露的信息。该应用程序可能只需要知道，如果用户X访问帐户123通过提供所有的帐户列表用户X访问您披露所需要的更多信息。

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.

下面是一个极端的例子：假设一个文件系统。请问你恩code作为债权用户可以访问文件的名称？可能性不大，因为你可能最终以百万计......

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...

另外一个极端的例子是：如果你想实现一个数据库行级安全性。请问你恩code作为索赔ROW_ID的每个用户？又不太可能，因为可能有很多，这是非常特殊应用，还因为它只是可能更容易（和更高效的），以解决该行与数据库查询过滤（这是基础结构优化的一个例子）

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)

这篇关于限制访问记录。索赔是基于权限的好主意的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！