Restricting access to records. Is claim-based permissions a good idea

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 开发者_JAVA技巧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)

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)