Problems with RBAC permissions modeling

Question

I’m developing a system where your user permissions will be based on the RBAC model,

a user could be in several permissions rules that would give or not privileges to the system, when registering a new user the user to be registered would inherit the permissions of the user who is registering, how to prevent the user who is being registered cannot delete a user who is in a hierarchy above his (according to business) or remove this user from rules that influence his hierarchy in the system. For example

 João(Usuário)
    ->Diretoria(Regra)
       ->cadastrar usuários(Permissão)
       ->excluir usuários(Permissão)

 Fernando(Usuário)
    ->RH(Regra)
       ->cadastrar usuários(Permissão)
       ->excluir usuários(Permissão)

From the point of view of business(Real world) Board of directors this above RH in the hierarchy but in the RBAC model is an abstraction interpreted by the user who created them! how to prevent for example Fernando director John? simply because they both have the same permission(delete users)! a solution would be to write in the program that the user would only delete or modify users of the same rule, but in this case the director the company could not exclude anyone! or it would have to be in all the rules and if it were also could be deleted by another user, another solution would be to register a history for each user stating who is his father(user who created it) and so on in this case I would write in the program that the user can not take privileges from his parents, this would be a way to represent the hierarchy, but it still wouldn’t be perfect because a director could be registered alongside a regular user and this rule wouldn’t apply to him.

there is some model or solution that can be combined with this to give some hierarchy (from the business point of view) the rules, as could be represented in the relational database?

Answer 1

I think you’re mixing things up a little bit. RBAC was not made to manage permissions with this level of complexity, only to say whether such a user is allowed to perform the X action or not. Action X may have its own business rules, this is external to RBAC.

For example, if you have a system where each one has an email, each user would be allowed to read your emails, send new emails, etc. But each user can only access his own email, not that of the others. It is the responsibility of the "list emails" action to ensure that the returned list is restricted to that data the user has access to.

Thus, if a user is allowed to "delete users", he has access to the "delete users" functionality, and only. As this functionality will be implemented, this is on her account. And it is at this level that you should put the logic of "user at a lower hierarchical level cannot exclude users at a higher level". Or a different logic, if any. How to implement this, it depends on the case: it goes from hardcoded on your application layer, up to a database representation of the various hierarchical categories and their relations, or even an XML or similar configuration file (tip: go for it, do it the first way!) - or maybe a combination of the previous strategies.

P.S. Beware of too complex rules, or you may end up "trapped in a corner": for example, this idea of you "parent", if A created B and B created C, then A excluded B, what is the situation of C? etc.