Managing permissions in hierarchical groups

Question

I'm currently writing a web application for our small company which was originally just planned to organize appointments more efficiently by displaying our customer structure and automatically plan tours which originally just meant that our staff needs access to it.

However, since we then have our structure built we could then also use it to provide customers with information (e.g. upload files for them to download/read or fill out some forms). This also means we have to give them logins and permissions.

Our customer structure is like displayed here (simplified):

One problem is that not all of the employees of some of our customers have e-mail addresses (I know, unbelieveable in 2016 but I can't change that so I have to work with it) so I can't use e-mail as a unique identifier for a login.

So my idea was to connect logins to groups in this tree and give each entry in this tree a unique identifier (e.g. customer 1 gets CUST1) which has to be entered in an extra input field on the login form which then allows us to use usernames multiple times (once per customer instead of once in total).

This means each login is connected to one fixed group. Customers must not see each other, so I build the tree for each login, so a member of "customer 3" sees only branch 1 and branch 2 and everything below.

However, now the real problem: today I got told that there cases where you want a user to see office 3 and office 2 but not office 1 and 4 and even different permissions for each group they have access to (e.g.: see appointments in office 3 and see appointments and files in office 2).

I originally had planned something like this: put users with permissions "read files" and "fill out forms" in "office 1" and that's it.

One idea I have is to split those groups and permissions completely. For example, all employees of customer 1 will be members of customer 1 without any permissions, no matter what branch or office they belong to and then in a second step they are assigned the permissions for each group/node inside that customer. But I'm pretty unsure on how to handle cases like "a new office gets added to branch 1".

Is there any good advice? I mean normally groups are flat but hierarchical groups with possible different permissions seems kinda complicated.

Answer 1

As noted in the comments, it is likely you would want Role Based Access Control. It gets a little more complicated when roles can be granted at different levels of a hierarchy.

Some things to consider:

• Use an internal user identifier abstracted from external identifiers protects against changes in email address, user id, name, etc.
• Limit administrative privileges to the same level or below.
• Avoid requiring multiple roles to perform an action; someone with the privilege to schedule an appointment should get view appointments without an additional role.
• People in your company will need access to all companies' data; consider a superviewer role for your staff.
• Privilege administration will require some planning. A clear understanding of who can grant what roles is important.
• Will you want users to be able to temporarily grant their roles to someone else? What restrictions apply?
• Timely removal of privileges is also important.
• It doesn't seem it will apply in your case, but are there mutually exclusive privileges?
• Consider expiring unused roles and users? \This will up your security but may require more support.
• Try to limit the number of roles; grant all the permissions required by the role rather than adding additional roles.

Standard privileges tend to be hierarchical: Read, +update/create, +delete, or read/approve. Approval roles are usually at least partially exclusive with update/create/delete. None is not a privilege. Using increasing values to code for the increasing privilege usually works. Approval roles are problematic and may come with limits like approving < $250.

Roles are a collection of privileges, possibly only one. They may simplify privilege management and ensure users get all the privileges required to do their job.

Privileges may relate to modules. Consider the roles that will require privileges above read by module. Modules often correspond to (organizational) roles. However, it is common that a module-based role implies at least read access to other modules' data.

Don't worry about roles granting access to modules not contracted by a customer. Control module access by customer/client as appropriate not by user. This builds depth in your security framework. (It also becomes a selling point if security doesn't create a long setup/stabilization period when adding new modules.)