Hierarchical access control example

In this chapter we'll discuss a fairly common access control pattern where there is a hierarchy in the object model and users can access these objects either if they own it or belong to it. Throughout this chapter, we'll use a data model with clients, projects, project users, and documents.

The three types users who can log in:

• administrators, have access to everything
• clients, have access to all the objects under them
• users, have access to the project objects they are assigned to and the client object

For example, if user1 is logged in, it should have access to these objects:

user3, belonging to a different project should access only that project:

Then client1 should have access to both projects but not any objects belonging to other clients:

Moreover, we'll also implement that all users can add project documents as well as documents to their own user, but they can't add documents to other users:

I found this a fairly common scenario as most business data models are organized in tree-based hierarchies where a user on one level can access objects going up and down only. In this example, the access control is scoped to a client or a project. and they form a hard boundary for users inside them.

Traversing up and down

Everybody should be allowed to go up in the hierarchy, for example, users should have access to the project and the client objects. This is useful as these objects can store configuration accessible for all users in that project/client. For example, a frontend for a user might want to show the client's and the project's name they are logged in to.