Permission System of B2B Platforms: Technical Realization of the RBAC Model
The RBAC model introduces ‘roles’ between users and permissions. Find out how B2B platforms can utilize this model to make a difference.
Data middle platform is a system capability that allows the assembling of independent tools into one integrated environment, shared with various business units through interfaces and components. Large-scale data middle platforms require product managers and developers, especially back-end developers, to be familiar with the permission system before entering product development projects.
The Role-based Access Control (RBAC) model is an easily understood permission system for B2B products. Focusing on the actual technical implementation process of RBAC will allow you to avoid unnecessary detours and facilitate the communication between B2B product managers and developers.
1. Introduction to permission systems
The permission system includes six components: business organizations, roles, users, permissions, interfaces and views. Users gain permission according to the roles they play in the business organization. When roles differ, the permissions differ, and the interfaces and views presented to them will also be different.
Specifically, organizations, roles, and users are real-time adjustable based on business changes. Permissions are fundamental attributes developed and implemented based on business requirements. There are functional permissions (including menu permissions), organizational permissions and data permissions. Interface and visualization are contents presented by the system to corresponding users according to the system configuration.
2. Deep understanding of the RBAC model
At the core of the RBAC model is the introduction of roles between users and permissions. It eliminates the direct relationship between users and permissions. Instead, it gives users permissions indirectly through user-role correspondence in which each role corresponds to a customed set of permissions (as shown in the figure below). Such a model decouples users and permissions.
RBAC model emphasizes the relationship between users, roles, and permissions. Applying the RBAC model in the B2B sector requires an additional component for business departments. Together, these four components establish a new relationship. The back-end office needs to record the relationships of users, business departments and roles, as shown in the figure below:
3. Basic requirements of business records in mature platforms
The permission systems of mature Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM) platforms are stringent, and the same applies to requirements for business records. Each business record must contain its owner and the owner’s business department. In general, business records must fulfil seven primary fields: the creator, creation date, last modifier, last modified time, the owner, the owner’s business department, and corresponding status (enabled/deactivated). When the owner changes, his business department will update simultaneously.
According to the data scope of the current user’s organization and role, the system will retrieve relative data from their owner’s organization and then set the front-end permission button (highlighted/greyed) for the current user according to his role and permission.
For example, Jack is the sales manager. His access permission is viewing customer data of all sales consultants in the department, and his modification permission is personal. When getting the list of customers, the permission buttons for some customers are highlighted (his customers), while the others are greyed (not his customers).
4. The configuration and implementation of a permission system
Permission configuration is part of the basic settings. Generally, it is the assigned manager who sets the permissions of different roles. Take the image below for reference.
Permission configuration also requires the agreement between the front-end and back-end office regarding two aspects. First, use standardized permission codes for coordination; second, use Excel or other tools to set menu/functional permissions, data permissions, and corresponding permission codes. For example:
Here are three questions for you to ponder:
- Are organizational permissions handled the same way at the individual and headquarter levels and levels below the headquarter?
- What can be done if someone has multiple roles with different levels of organization permission?
- Will functional permissions always allow access to business records?
5. Complex application: business organization and project organization in real estate sales
In real estate sales, there will be business organization, project organization and project-related data. Let us take the example of a real estate project — the leads generated belong to the project, but the customers and developed company channels belong to the entire system. An employee can take up business roles and project roles. A more complex case would be when an employee takes up multiple business and project roles simultaneously. To have a better understanding, see the example below for Tom’s roles and the corresponding list of leads he has access to.
Due to such complexity, both the business organization ID and the project organization ID are necessary for the business records.
6. Extension knowledge: organizations in platforms
Administrative organization: used by Human Resource (HR), Office Automation (OA) and other administrative organizations with a clear organizational structure.
Financial organization: organization for financial budget and financial statements. While the administrative organization has five levels, the financial organization only has three levels. The third level of financial organization will respond to the fourth and fifth level of administrative organizations.
Business organization: the organizational structure of business operations is similar yet different from the administrative and financial organizations. For example: in a typical business structure, the Chief Executive Officer (CEO) reports to the director, while the Chief Marketing Officer (CMO) and Chief Financial Officer (CFO) reports to the CEO. However, in the system, business organizations will place the chairman, CEO, CMO and CFO in the top-level organization of the company, which includes even the financial accountant and Business Partners (BP).
Virtual organization: often used in regional management organizations or functional organizations. For example, in the South China virtual organization, there will be financial, HR and other functions with sharing organizations, together with procurement specialists who are responsible for the centralized procurement of market materials. The same financial organization is in charge of supervising two regions, which are virtual organizations. Its data scope corresponds to the permission of business organization in the South China region.
7. Conclusion
RBAC introduces the concept of role as a general permission model, which facilitates permission allocation and the separation between authority and responsibility. In addition, it is flexible to changes in the enterprise business and security policies. However, the RBAC model does not provide an operational sequence control mechanism, making it unusable for physical systems with similar requirements, such as shopping control systems.
