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.

  • You'll probably need some programmatic access control. What Web app framework are you using? Commented Jun 6, 2016 at 3:37
  • You don't say what web app language. You don't say what database. You haven't really given us any of the tools to help you and also I'm not even sure this question is "on-topic" for this part of stack exchange ? Its more about app development. Commented Jun 6, 2016 at 9:05
  • Are you asking how to implement the UI (in which case, look at ux.se), or whether there is a better structure to use instead (in which case, probably better on stackoverflow)?
    – Matthew
    Commented Jun 6, 2016 at 13:36
  • 1
    I apologize for not providing this information earlier. I guess I was looking for a more high-level logical solution for my problem(on the lines of what Salamander has provided below). Hence, I thought that these details may not be necessary. Anyways, I'll be using the Spring Web MVC framework and a MySQL database. Commented Jun 7, 2016 at 22:48

3 Answers 3


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.

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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .