Four diagrams show the relationship among users, permissions and tenants


1. The simplest user system

A most simple user system, only need to have user and authentication module is enough. As shown in the figure:

Here’s a hint: the upper level data depends on the lower level data. For example, authentication relies on user data.

2. User system with authority management

If you need permission management, then add resource and role modules. At the same time, authentication is needed after identity authentication.
Resources and users are the lowest level of data. Roles need to associate users and resources to complete the authorization of users. If you understand the RBAC model, you should be clear about this relationship.

3. Complex system with user group and organization

If we need to have user groups to assist user management, or we need to have an organization in the system and support the authorization of positions. We can add user group and organization module, which can establish many to many relationship with users. At the same time, roles can establish indirect relationships with user groups, organizations and users, thus simplifying authorization operations.

4. A multi tenant platform

Most of the time, we need to have the concept of tenants and use tenants to separate the business data of users. For example, nailing is a multi tenant system, in which every enterprise is a tenant.
We can add a tenant module on top of the users to establish a many to many relationship between the tenant and the user and the resource (application). At the same time, user groups, organizations and roles can be distinguished by tenant.

Assuming that every tenant has the role of “Administrator”, then 10000 tenants will have 10000 roles called administrator in the system, but each tenant can only see his own “Administrator” role. If tenant a establishes a “salesman” role, then tenant B does not have this role. If he wants to, he must create one himself.


In Figure 4, user groups, organizations, and tenants are all optional. There should be no coupling between modules, only data dependencies. You can achieve what you need, not all at first.

Please point a like to understand, so that more people can see.