Inherit / modularity in Application roles to allow for better hierarchy?
0
In most applications, security is probably set up in a similar way, with hierarchy-level roles (Employee(S), Manager(M), Admin(L)) or company-role matching roles (ProductOwner(A) or ScrumMaster(B)). You probably have your module roles set up the exact same way. Now I'm wondering if it's possible to set it up a third way, with a bit of modularity/inheritance of roles and rights. For example, you have two roles in your company: (regular) Employee and TeamLead. Now the TeamLead is basically the same as Employee, but is allowed to edit some data the employee can, and view additional information. In such way, I would assign the account of a TeamLead, the Employee as well as the TeamLead role. The TeamLead role, security wise, is an addition on top of the employee. The TeamLead role does not have access to microflows specifically the employee by default already has access to ("Don't repeat yourself"). The TeamLead basically inherits the access via the second role (employee) assigned to its account. The idea of modularity/inheritance of access seems to be a great way to configure the security in your application. In addition, this might lower the requirement of access per role, less duplication, because a lot can be inherited from a 'lower' level role. The big issue here, however, is that it seems (for now in my exploration), Mendix doesn't support this way of security setup. If you've got a page that contains entities that are readable (by default) for employees, on a page that is accessible by the TeamLead role, without specifically configuring read access on said entity for the Team Lead, Mendix presents you an error "No read access to Entity X for role TeamLead on page X". Even though you'd configure in your database that all TeamLead accounts will have the employee role, Mendix Studio doesn't know this and will prompt you to specifically configure entity access for each role and module. Right now I'm unsure whether an modular inheritance security setup is a great idea, if I'm implementing it wrong or whether I should just revert to the regular "One role per account for each purpose" system, as explained in the beginning of this post. Anyone care to elaborate on this thought?
asked
Sander Schaeffer
1 answers
0
We have built several apps with similar role distribution.
The modeler does not know that everyone has the Employee role by default (unless you select both module roles for the User Role), so yes, you do have to give the team lead access rights to the entity attributes. I don't feel you would be repeating yourself if you gave the TeamLead the same access rights to entity attrubutes that the employee already has. If anything, a team lead should always have its own set of access rules, even in this type of role setup. It is the difference between 'can do additional things' and 'can do other things', from a database point of view, and from your post I believe you want this role to be 'can do additional things'.
But in your example, why would a team lead need access to a page that is readable by employees? Wouldn't in that case access for only the employee be sufficient?