Implement RBAC for my application

Question

I'm beginning to work on a new web app for which I require implementing Role-Based Access Control.

I've identified three Roles for my application which will be Role 1, Role 2 and an Role 3. Each user will be in one of these groups or can be in multiple groups as well.

Going down further, each role has 2 functionalities associated with them, say (D1, D2), (T1, T2) and (A1, A2) respectively.

Implementing access control up to this point seems fairly straightforward to me.

However, there are further drill downs for each role based on say geographical locations and another category called Accounts(S1, S2 and S3). For example, a Role 1 user will be having access to D1 and D2 but he should have access to only North America data and Accounts S1 and S2 but not S3.

This is the place where I'm at an impasse. I'm not able to put these sub-categories in my access control permissions because the permutations would be huge.

Any suggestions to implement this would be of great help.

Answer 1

I can suggest the following options based on provided information:

1. Define data domain (North America, Europe, etc.) according to your criteria and grant roles within that domain only. E.g., grant Role 1 within data domain A or account S1. Simple enough, but depends on your data structure.
2. Add additional conditions in ABAC style, i.e. grant or deny access to specific role if case some conditions are true (e.g., if user allowed Regions = current resource Region) This approach adds complexity to the solution and its security matrix, but ABAC policies are very powerful and can cover variety of cases.

Answer 2

This is a common problem for global solution providers.

Accounts and geographic regions are not further "drill-downs" in the context of permissions and RBAC, but instead constitute larger areas of governance within which RBAC schemes take effect.

Accounts and geographic regions are more important than any specific roles/capabilities in any specific application. Accounts often imply a custodial relationship, violation of which can subject the company to lawsuits or fines, and access rules in which may be distinctive and uniquely differentiated from those in other accounts.

Similarly, geographic regions imply different legal regimes, with special rules to which one has to adhere that supercede any particular corporate policy or approach.

Since companies usually (though not always) span regions, the usual model is to consider accounts to be highest level. Any given customer account may have multiple regions in which the customer has a legal presence. In each of those regions, then, within the account, may a specific RBAC scheme be assigned to the users of relevance to the account.

In other words, an individual user should have unique, explicitly enumerated roles for each region in each account. User X may have Role 1 (with functionality D1 and A1) for Account S1 in Region Z, but Role 2 with functionality D2, T2 and A2 for Account S1 in Region Y, and a whole different set for Account S2 in Regions Z and Y.

Answer 3

Access functionality := roles Roles:=attributes Attributes:= account owner, Account Type, Region, Business unit, *

OK so where is the issue when you use exact matches on the set of attributes? I.e. all in region C can use functionality FA. Well, it depends on whether the business is fine with unintended but legitimate access, and accountability with its use. If you set up role based access where you don't explicitly white list account holders, then be sure to have an accounting trail that logs all use by account holders. Also if inappropriate but legitimate use results in damage, highlight the program is working to specification, and has adequate logs to determine user attribution. Also have a chain of who allows access to what.