Questions related to RBAC implementation

Question

I have some questions related to RBAC (hirearchy model). Following are the scenarios

Assume i have three roles, one parent role and three different types of permission

Parent Role: branch manager. Child roles: savings manager, loan manager and accountant. Permissions: persist, delete, view

Q1: Can a child role be inherited by two or more roles I.e. Assume the role accountant reports to both savings manager and loan manager with different duties - E.g. saving manager gets report from accountant role on high valued savings account customer and loan manager get report from accountant role on high valued loans taken by customers

Is this model is allowed or do we need to have something like savings accountant and loan accountant based on their duties

Q2: if Q1 is valid, then how do i deny loan related permissions (persisting loan, deleting loan, viewing loan details) to savings manager but allow to loan manager and vice-versa for savings related permission.

Q3: assume,

Accountant has no permission to delete savings record Savings manager has permission to delete savings record Loan manager has no permission to delete savings record

now what happens to bank manager role (delete savings record is not defined). will bank manager gets permission to delete savings record. does allow get precedence over deny or vice-versa or do i need to write rules (which to be precedeing) for the same.

There are some more questions which i will ask later

Thanks Albert Arul Prakash

Answer 1

Is this model allowed?

In role-based authentication, an actor is acting in one or more roles. You can slice things up into roles however you like -- modeling roles based on inheritance or not.

The criteria you should use to decide who has what roles is whatever

1. gives good actors the power they need to do their job while leaving bad actors with the minimum amount of excess abusable authority.
2. fits well with logging so that abuse of authority can be investigated
3. is easily enough understood so that bad actors cannot plausibly deny responsibility for abuse of authority
4. allows enough delegation so that managers are not tempted to share credentials to get the job done

The only rule when designing an RBAC system that you should never violate (besides assigning permissions to roles not users) is this: an actor cannot escalate privileges by assuming fewer roles than they are allowed. A person who is allowed to act as a bank manager and as an accountant should not be able to exercise more authority if they can convince a system that they are an accountant but not a bank manager or vice-versa. Negative permissions make things very difficult to reason about and introduce weird corner cases -- just avoid them.