I am having trouble finding a scalable way to create a access control system which both follows best practices and can scale well. I have looked at various approaches like RBAC and ABAC.
For the uses cases I am concerned with, RBAC does not seem to be as fine-grained as necessary. ABAC (and other similar methods like CBAC) seem as they may be sufficient as far as control but look like they would introduce significant overhead in complex cases. Most examples and descriptions of these almost always seem to be applied broadly to an activity. For example, some activity (example: "org:activity") like CRUD based actions. For many applications I have had to manage over the years this rarely seems sufficient.
An example might be the following:
Resource Type tA:
- Has fields:
- fA
- fB
- fC - must be valid id of type tB
- fD
- fE
Resource Type tB:
- Has fields:
- fA - id
Role rA:
- Can read all fields of tA
- Can create tA
- Can write fields tA.fB, tA.fC, tA.fD with any valid value
Role rB:
- Can read fields fA, fB, fC, fD of tA
- Can create tA
- Can write fields tA.fB, tA.fC
- When writing tA.fC the value must be a value in some subset of all possible values
Role rC:
- Can read fields fA, fB, fD of tA
- Can create tA (tA.fC is automatically set to valid value)
- Can write fields tA.fB, tA.fD
- When writing tA.fD it must be valid value in a subset of all possible values
In the above example, a create and update type of activity would not seem to provide enough control. Only restricting access at this level would not provide the field restrictions. With ABAC it would seem that a single request to perform an activity like "create" or "update" would require both definition and validation of multiple policies. With multiple policies involved, should there be separate decision points for a single activity? For example, when we receive a request would we have a decision point for the activity as a whole, then later a decision point which would involve a Principal, Resource, and the individual value for the field which will be written to?
The way I have seen this done in the past is usually hard coded logic which usually involved checking a role and then running some related checks. Based on everything I have seen, these types of hard coded authorization decisions are considered anti-patterns but I am unsure how you could efficiently avoid such checks. Also, this logic must then be duplicated both where the data is accessed and in the presentation layer to provide the user with proper options for input. Is there something I am misunderstanding for these types of access control? Is there a method using ABAC, CBAC, PBAC, or any other access control type system that can deal with these type of access restrictions in a well designed method?
