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?

  • ABAC doesn't introduce overhead. It's a generic platform that applies in many cases – David Brossard Jan 12 '18 at 6:53
  • I would define an additional request from a PEP to a PDP which would not otherwise be made as overhead. In addition to this, the way it is described, the PDP may access a resource which the the user is attempting to retrieve from the application. After sending a PERMIT back to an application, the application would then also retrieve the same resource. Multiple retrieval of the same resource on different servers (compared to once on a single server) seems to be to be quite a bit of overhead. – Goblinlord Jan 12 '18 at 7:02
  • Basically, just from the example described above it would, at the least, double the load on the databases used for resources. – Goblinlord Jan 12 '18 at 7:04
  • @DavidBrossard Interestingly enough, while looking up as much info I can about ABAC, I have actually run across much material which you were a speaker in. I am very curious as much of what I found seems to be either doesn't seem to address specific problems I "think" might exist as well as cases outside what might be provided by solutions available from Axiomatics. Is there any way I could speak to you directly to discuss any of this? – Goblinlord Jan 14 '18 at 4:41
  • 1
    You can always email me – David Brossard Jan 14 '18 at 10:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.