User Group Management – How to Manage Permissions in Hierarchical Groups

hierarchypermissionsuser-group

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.

Best Answer

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 of 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 increasing privileges usually works. Approval roles are problematic in this case, but my come with limits like approve < $250.

Roles are a collection of privileges, possibly only one. They may privilege management much simpler 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 build 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.)

Related Solutions

Object-oriented – Filesystem like permissions for C++ type-members

Rephrasing the problem a bit:

I have an instance of MySpecialObject
an instance of JLP wants to call the methods of MySpecialObject
an instance of BEV wants to read the public data of MySpecialObject
the instance of JLP shouldn't be able to read public data and the BEV shouldn't be able to call member functions

This should be as type-safe as possible.

A solution I see involves wrappers :)

you write the code for MySpecialObject as you would normally, ignoring this extra requirement
you write a wrapper for each aspect of your class you wish to restrict. Say, MySpecialObject_Read and MySpecialObject_Execute.
these wrappers forward the requests (method calls, getter/setters) to an underlying shared_ptr of MySpecialObject
your MySpecialObject, MySpecialObject_Read and MySpecialObject_Execute classes each have (as needed) a "convert to ..." method. This method returns an appropriate wrapper over the underlying MySpecialObject

This solution provides a type-safe accessor with the desired limitations.

Each client class can choose what kind of access it needs. (And since you write these classes, you know what access you need.) If that is not acceptable, you could add factories that only create wrappers with certain limitations depending on a "token". That token might be the RTTI information of the calling class instance, although this could be abused.

Does this solve the original problem?

EDIT:

Remember that since you are the programmer you can instantiate an A whenever you want. By adding your class to a friend list or whatever...

What this solution provides is a clearer interface. Removing the explicit conversions probably makes it safer but less flexible. But, since they are explicit, you can easily look for them in the code and treat them as signs your architecture has a flaw somewhere.

Specifically, you can have code like this:

shared_ptr<A> * a = new A(parameters);

A_read aRead(a);
A_execute aExec(a);
A_write aWrite(aExec);

logger->Log(aRead);
view->SetUserData(aWrite);
controller->Execute(aExec);

Here there is an explicit conversion between an execute wrapper and a write wrapper, but you can decide on this based on your specific requirements.

But, with little effort (knowing which conversions are valid), just by looking at the call locations you can see that (with confidence!):

the logger will not change the state of your A
the view will not call methods on your A (other than setters)

This is true even if those particular method calls end up calling hundreds of other methods, more than you'd like to examine by hand.

At the cost of a few thin wrappers you gain the ability to see at a glance what a particular function call will do with the parameters you send. This may help a lot during debugging by helping you eliminate some branches from your investigation and, in general, would help people trying to understand the program.

I couldn't really find other reasons for using this ACL idea, at least ones where the costs don't outweigh the benefits. However, it does seem more intuitive than the visitor solution mentioned in the other answer.

Web-development – How should I implement permissions

My recommendation: think about how many

implementation exist currently in this world for access management? I would bet some millions.
man-hours are built into this field already? I can't even guess, and most of them are totally parallel...
open source solutions are there, ready to use in your system?

So, it is very good that you started thinking about it, created a simple implementation, identified the core components and their functions.

But now you should focus on the task you have to do, and don't waste time on access management. It will surely be worse (less features, weaker structure, less tested, has several vulnerabilities caused by the problems of your platform you haven't even known) than anything that is available for you right now to integrate and use (well, I have assumed that you are not Superman and not pioneering on an esoteric field, both are very likely).

Imagine your application in its full size, collect the features and assumed counts (user, feature, role, requests per second, ...). Use Google to narrow your search to like five solutions, compare them by their reflection on forums, blogs, etc., select one and use it. On the other hand: separate you actual choice from your code with a custom interface that you create by your feature list. This will be a bless if you have to switch to another solution because of something that you don't know today.

I think this approach has more benefits even if you write this system in order to learn. You should adapt to formalize your requirements, evaluate available solutions and learn from other coders' good solutions instead of making the same beginner mistakes from which those solutions have evolved. To become a reliable programmer, you have to find the right balance between writing and using components, and learn to objectively value your time, and the quality of your code compared to what is available (background knowledge, coding perfection, available amount of man-hours to bug fix and maintain, for development and real-life test).

You don't write your word processor to edit a text file. Why? Then why should you write an access control component (and copy-paste it to other systems that you make)?

In some cases, there is an objective reason for both. In most cases, there is none. Sadly enough, programmers tend to think that a word processor is more serious task (so they use one) than a writing a truly reliable access management (so they write one). Last note: contrary to all above, it is very likely that I will write an access manager - but I have a good reason to do it. :-)

Best Answer

Related Solutions

Object-oriented – Filesystem like permissions for C++ type-members

Web-development – How should I implement permissions

Related Topic