We are implementing federated identity management and have a scenario where users need to authenticate against uniquely identified items. For instance Bob might have read access to records 12345, 34444, 23443 and 23443 while Jane might have read/write access to records 12345, 34444, and 23443 and read access to record 56445.
I have two questions:
-
Let’s say someone has access to a hundred or a thousand separate and unique records. With claims based security I understand the incoming security token would contain all these claims. Is the size of the token going to be a problem?
-
I don’t see a lot of guidance on creating a management system for administering the authorizations, i.e. in our case assigning users to the authenticated records. I see a lot of advice about making the authorizations declarative whereever possible, but not a lot about what to do when that’s not possible.
Any advice or direction is much appreciated.
On #1: yes, you can potentially end up with a very large token if you are modeling entitlements as claims (e.g. a claim for each record a user has access to). If you have 100,000 records, then you can potentially end up with 100,000 claims.
The “granularity” of claims is one of those “it depends” topics. In general, the recommendation is to keep claims “coarse” (e.g. groups, roles, organizations, etc) and then associate those with fine grained permissions in the app (which can still be implemented declaratively).
Also, I would suggest you ask the question: “who is an authority on the information that will be conveyed in a token?” If the knowledge that “user x is entitled to read record 23455 and 2456” is application specific, then it belongs in the app, not the STS.