Problems with RBAC permissions modeling

Question

Problems with RBAC permissions modeling

Navigation

#1 by (4 votes)

2

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 grant privileges to the system, when registering a new user the user to be registered would inherit the permissions of the user that is registering, how to prevent the user that is being registered can not delete a user who is in a hierarchy above his (according to the 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 a business (Real World) standpoint this is RH in the hierarchy but in the RBAC template is an abstraction interpreted by the user who created them! how to prevent for example that Fernando excludes the director John? simply because they both have the same permission (delete users)! one solution would be to write in the program that the user only exclude or modify users of the same rule, but in this case the company director 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 informing who is their parent (user that created it) and so in this case I would write in the program that the user can not take privileges from their parents, this would be a way to represent the hierarchy, but still would not be perfect because a director could be registered in parallel to a common user and this rule does not would apply to it.

Is there a template or solution that can be combined with this to give some hierarchy (from a business perspective) rules, how could it be represented in the relational database?

modelagem

asked by anonymous 14.10.2014 / 23:53

1 answer

Error customizing a menu using actionLayout Post in Facebook timeline

score 4 · Accepted Answer

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

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

That way, if a user has "delete users" permission, he has access to the "delete users" feature, 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 can not delete users at a higher level". Or a different logic, if that's the case. How to implement this depends on the case: going from hardcoded in your application layer , until a representation in the bank of the various hierarchical categories and their relations, or even an XML configuration file or similar (hint: it goes by me, it does the first way!) - or maybe a combination of the previous strategies.

P.S. Beware of too complex rules, or you may end up "cornered in a corner": for example, your idea of the "parent" user, if A created B and B created C, then A deleted B, what's the situation of C? Etc.