1. Introduction

In product design, permission design is often hastily taken as “technical details” or “configuration trivia” until the system has a problem, only to find that it is an indispensable underlying mechanism of the entire product. From cloud computing platforms to enterprise middle office system construction, I have seen too many permission systems: either too complex for anyone to move, or so simple that they are useless.The most typical failure is that the business side does not use it at all, and the product manager has to manually configure permissions for them every time they go online.

From the perspective of product managers, permission design hides too many hidden costs, such as blurring role boundaries can directly lead to data leakage risks, and even become a time bomb for compliance audits. In addition, if the permission system is not well designed, the product cannot be stably expanded, such as security, operational transparency, and collaboration efficiency. At a small level, it is the premise that the system can be trusted, which determines whether users can find functions smoothly, and is the embodiment of role boundaries. Therefore, the quality of the authority not only affects the product itself, but also directly affects the subsequent operation.

This article mainly talks about some insights after being “beaten” by permission design, I hope you will understand “permission” a little more and be less passive after reading it.

2. Some basic knowledge related to authority

2.1 Core concepts of permission design

Before talking about design solutions, we need to clarify some basic concepts. The core of the authority system revolves around “Who (the subject) can do what to what (the object).“Expand, here are the three elements of authority:Subject, Object, and ActionI see that some articles call the three elements of authority user, role and authority, which can only be said to be a bit misleading (including me).

1. Subject: The “owner” or “executor” of the permission, that is, “who” is using the permission. Common manifestations such as users (user groups), roles (role groups), and organizational units (departments/ranks/project groups) are all one entity. Avoid duplicate configuration of permissions through the association of “user→role→organization”.
2. Object：The “object” of the permission, that is, “what resources” need to be controlled. Manifestations such as the operation qualification of system function modules, the access and operation scope of data, and the ability to call system interfaces/services are all objects. Solve the question of “what needs to be controlled by permissions”.
3. Permission Action：The subject’s “specific behavior” towards the object, that is, “what can be done”. Common types include CRUD operations, including Create, Delete, Update, and Read. There are also special operation approvals (Approve), export (Export), grant (Grant), etc

In the book “Information Security System”, access control is also referred to as the subject, object and policy, but I still think that the operation may be more vivid. Object and Action are the two core elements of the authority system, but they are sometimes easily confused. In simple terms, there can be many different operations on the same object, and the operation must be dependent on the existence of the specific object.The object is the “goal” and the operation is the “action”, and the combination of the two forms a complete authority, such as “User A can export financial statements”.

B-end product manager’s ability model and learning improvement
The first challenge faced by B-end product managers is how to correctly analyze and diagnose business problems. This is also the most difficult part, product design knowledge is basically not helpful for this part of the work, if you want to do a good job in business analysis and diagnosis, you must have a solid …

View details >

In addition, there are also means to further refine the permission boundary, such as permission granularity, permission verification, inheritance recycling, data row permission, data column permission, etc. Understanding these concepts is a prerequisite for building a clear permissions model. Only by sorting out these basic elements can we talk about the maintainability, scalability and configurability of the permission system.

2.2 Three classic authority models

Understanding the permission model is the most critical step in permission design. The essence of the permission model is a rule engine that defines “who can operate what under what conditions”, and the software system has evolved for decades. After decades of product evolution, the industry has developed mature model systems such as ACL, RBAC, and ABAC, which can help us avoid reinventing wheels and directly build a permission system that meets business needs on mature frameworks.

Three common models include:RBAC (Role-Based Access Control)、ABAC (Attribute-Based Access Control)andACL (Access Control List), each of which is suitable for different business complexities and control needs.

RBAC (Role-Based Access Control) is the most mainstream model, and the core ideas are:Users are given roles, and roles have a set of permissions。

Its advantage is that it has a clear structure and is easy to manage, which is very suitable for scenarios with a clear division of labor such as enterprise backend and B-end management systems. RBAC can be further divided into RBAC0, RBAC1 and RBAC2:

• RBAC0 (basic model): Users obtain permissions through roles, which are statically bound to permissions.
• RBAC1 (role hierarchy): Increases role inheritance on the base model, and high-privilege roles automatically have the privileges of low-privilege roles.
• RBAC2 (Constraint Model): Introduces constraint rules, such as separation of duties and mutually exclusive roles, to enhance the security control capabilities of the system
• RBAC2 (extended model): To simplify configuration and improve reusability, user groups and permission groups are introduced, similar users are associated with roles in batches, and high-frequency permissions are combined to roles.

These concepts don’t need to be memorized, just know the relationship between user roles and permissions.

ABAC (Attribute-Based Access Control)Breaks through the static authorization restrictions and dynamically determines the permissions of multi-dimensional attributes (user attributes, resource attributes, and environment attributes) to dynamically determine whether the subject is allowed to access. For example, the rule “Only allow sales employees to access customer data on the intranet during working hours”.

ACL (Access Control List)is the most basic “flat model”，A list of users or roles is maintained on the resource that records which users or roles have access, such as “User A can edit documents, User B can only view them”. It is also commonly used to control some independent resources or file systems in microservice architectures, such as the read and write permission settings of Linux file systems (e.g.,-rw-r--r--）。

In addition to the above three models, there is also a resource access management (RAM) model that is also common in China but is not directly touched by most product managers, which is mainly used in public cloud platforms (such as Alibaba Cloud, Huawei Cloud, Tencent Cloud) to achieve multi-tenant isolation and control access at the resource level. Unless you are in charge of a resource service system, it is rarely used in daily product design, so I will not expand it here.

It’s important to note that these permission models are not either/or. In actual projects, mixing is more common:Manage functional permissions with RBAC and quickly assign operational qualifications through roles. Use ABAC to dynamically control data permissions and flexibly adjust access scope according to user attributes and environmental conditions. Finally, ACLs are used to supplement the personalized needs of special scenarios, such as temporarily opening a certain permission for a specific user。 Reasonable combination of models according to business complexity can not only avoid cost waste caused by over-design, but also ensure that the permission system adapts to long-term business development.

3. Design process from 0 to 1: a practical guide for all stages

Product design is a systematic project from demand to implementation, and a high-quality permission system is not built in one step, but is designed in stages from abstraction to concrete, and gradually iteratively implemented. Especially in middle and back-office products, the permission design from 0 to 1 can be roughly broken down into five key stages:Goal definition, permission modeling, rule formulation, technology implementation, and online verification。 One advantage of structuring the process is that it can quickly align directions and reduce trial and error costs.

Step 1: Define requirements and clear goals

For products, clichéd topics:Before doing it, you must be clear about what you want to do.。 The form of research includes but is not limited to user interviews, questionnaire surveys, and competitor analysis, which need to identify user pain points and unmet needs.

For permission design, it is necessary to clarify why the permission system is needed and what problems the permission design solves. In the survey, non-urgent needs can be deprioritized and the core functions of the minimum viable product (MVP) can be clarified first. It is also necessary to confirm the objects and scenarios that require permissions in the system (such as function access, data isolation, etc.), and clarify the basic requirements of security, flexibility, and operability. To get this content and information, you can use a three-step interview method:

• (1) Decision maker: Permission stuck points in core business processes (such as approval flow node control)
• (2) Client: Pain points of function usage for different roles (e.g., whether customer service needs to check the order amount)
• (3) Technical side: Permission compatibility evaluation of existing systems (historical data migration scheme, congratulations if it is a new system)

Through the research, you can analyze the role boundaries and usage behavior, and finally output a deliverable: “Permission Requirements Matrix Table”. The format reference is as follows:

Step 2: Scheme design, permission modeling

Permissions modeling is a core process for defining the relationship between users, roles, and resource access in a structured way. On the one hand, it is necessary to choose the appropriate three permission control models mentioned above, such as RBAC (role-based access control), ABAC (attribute-based access control) or hybrid model (RBAC + ABAC / ACL, etc.) based on actual business scenarios. On the other handPermission design is more abstract than business functions, and it is often difficult to form intuitive cognition in the early stage, and it is extremely tiring to explain and review in pure text.Therefore, in order to improve collaboration efficiency, it is recommended to use permission logic diagrams, permission flow charts, etc. to visualize the form, as long as it can help understand. The following image is an example of a simple permission model for an order.

Step 3: Clear details and rules

After completing the permission modeling, only the basic structure and direction are determined, and the actual implementation needs to further formulate detailed rules to clarify the granularity, conflict handling methods and operation mechanisms of permissions.

Taking “game order data” as an example, permission refinement needs to be distinguishedFunctional permissionsandData permissionsTwo categories. Functional permissions can be split by page level and operation level: for example, ordinary customer service can only click “View order details”, while game administrators (GMs) have an additional “Export order” button. For example, customer service can only view orders for the channel/authorized project, and some sensitive fields (such as user mobile phone number, payment amount) may require secondary authentication or direct field desensitization.

Regarding conflicts of authority and priority, the following three rules should be clarified：

• (1) Explicit permissions take precedence over inherited permissions, for example, users are given the “export” permission alone, which should be higher than the default limit of the role;
• (2) Roles support hierarchical inheritance, and the superior role automatically includes all the permissions of the subordinate, reducing redundancy configuration costs.
• (3) When a user has multiple roles, the principle of “merging permissions” is adopted to merge all available operations.

If it is a permission design for an internal system, it also involves assignment and recycling. For example, the permission allocation process should be approvable and auditable (life-saving function), and some key permissions (such as export, deletion, etc.) are recommended to be bound to the existing internal approval process, which needs to be approved by the person in charge before it can take effect, even if it is an email. The permission recovery mechanism needs to cover scenarios such as personnel resignation and job transfer, and automatically strip the original authority when triggered to avoid potential safety hazards.

While completing the above background logic design, it also needs to be definedFront-end interaction specifications with insufficient permissions。 Common methods include: hiding or disabling buttons for unauthorized operations, and only displaying the “Submit Application” guidance; If an override request is attempted, a structured error code is returned and the page jumps to a 403 error page with a clear explanation.

At this point, through the refinement of rules at this stage, the permission system can achieve “operation, control, and evolution”, and truly have product-level availability and maintainability.

Step 4: Development and technical collaboration

Permission design goes to the development stage, focusing on transforming abstract models into system-recognizable data structures and authentication logic. Product managers need to participate in the development review on the one hand, and on the other hand, they also need to deal with problems in a timely manner. Collaboration between products and technologies is particularly critical and needs to be focusedThe permission data structure is implemented, the interface authentication logic is clear, and the front-end dynamic rendering rules are implementedto ensure that the model is transformed from theory to executable technical solutions.

Taking the RBAC model as an example, the permissions data structure typically includes three core relationships: users and roles, roles and permissions, and permissions and resource actions. The product needs to clarify the field design of each permission granularity with the backend, such as functional permissionspermission_code, data permissions associated with business dimension fields, such asgame_idorchannel_id。

The interface layer needs to verify the access permissions of the middleware, and the backend determines whether the requesting user has the permission to access the target interface based on the role. For example, when accessing the “Export Order Data” interface, you need to bind permissions, and if you are not authorized, you will directly intercept the return error message.

Step 5：Test online and validate the scheme

After the design of the permission system is completed, the testing process before going live is crucial. When participating in the review of test cases, it is necessary to clearly cover the positive scenario, negative scenario, and boundary scenario.

• (1) Forward scenario: Whether the operation within the scope of normal role permissions is smooth
• (2) Negative scenario: whether unauthorized access (function/data) is properly intercepted
• (3) Boundary scenario: Permission inheritance and recycling logic when changing roles (e.g., employee transfer/resignation)

In the product acceptance after the test is completed, the product also needs to ensure that the main line can be verified. Only through multi-dimensional verification can the permission system truly have the stability that can be launched and maintained, and can be delivered online.

4. Practical case library: two product cases in charge

Product 1: X project management software

X is a project management software for medium and large enterprises, supporting key functions such as parallel collaboration on multiple projects, task assignment, progress tracking, and member permission control. System users mainly include:System administrator, project administrator, project member, covering the multi-level permission requirements from configuration management to actual execution.

When it comes to permission design, typical requirements for X include:

• Functional permissions: For example, creating tasks, viewing projects, and exporting reports;
• Data permissions: Limit users to access only the data of the projects they participate in or are responsible for;
• Iterate over management permissions: Whether members have the right to create, modify or delete project iterations;
• Work item permissions: This is the most complex part of the permissions system, work items include types such as requirements, defects, tasks, etc., and support fine-grained control of these objects, including whether or not to allow themNew, view, edit, deleteand other operations. It also supports pairsWork item attribute levelpermission controls (e.g., whether the Priority field can be edited).

Due to the diverse roles, rich operation particles, and complex permission combinations, X project management software has become a typical case of permission model selection and practice. The system supports multiple subject types such as users, user groups, departments, and roles, and the data permissions are refined into four dimensions: projects, modules, work item columns (attributes), and work item rows (types).

For example, module permissions, such as iteration modules and defective modules, can be directly bound to roles or batch authorization by user group or department, such as assigning module permissions to product groups and development groups. At the same time, the system supports configuring corresponding operational permission combinations according to different data permission ranges to achieve flexible and refined access control policies.

Ultimately, the X system adopts a hybrid model with RBAC (Role-Based Access Control) at its core, supplemented by ACL (Access Control List) mechanisms:RBAC provides a unified permission framework and role management capabilities, and ACLs are used to handle special cases of individual usersto strike a balance between versatility and flexibility.

Product 2: YContinuous integration and continuous delivery of software

Y is an enterprise-deployed CI/CD tool that serves internal R&D processes and supports automatic code build, testing, and deployment to ensure the efficiency and stability of continuous delivery. The system supports the creation of multiple projects, each of which is configuredProject Administratorandproject memberTwo types of basic roles, and allow custom roles to meet the differentiated management needs of different teams.

The permission model is based onRBAC is the foundational framework, supplemented by ACL controls, realizes a compound authority system of role-driven, scope inheritance, and fine-grained authorization. Various roles can be directly bound to functional permissions, such as creating pipelines, triggering builds, viewing logs, etc. The core resources of the system areassembly lineIt not only involves functional operation control, but also needs to be finely managed for its data access rights, which is mainly reflected in the followingTeam levelandIndividual levelDual layer control.

By default, each pipeline belongs to the creator, but the system allows it to be transferred to the team name and passedgroupingandlabelCarry out further classification management. Grouping allows you to configure access rights (e.g., read-only, editable, and triggerable), and tags serve as auxiliary dimensions for permission filtering and display optimization.

The permission inheritance logic follows the hierarchical relationship of Project > Grouping > Pipeline, with smaller granularity and higher priority. By default, the pipeline inherits project permissions, and after you customize a group, you inherit the group permissions. If you need to have higher control accuracy, you can also configure exclusive permissions for a single pipeline, such as independent authorization for viewing, editing, and executing operations.

Therefore, the permission system of the Y system not only ensures the unity of role management through RBAC-based and ACL-supplemented design, but also takes into account the refined control at the assembly line level to meet the requirements of CI/CD tool permission design.

epilogue

Permission design is not a technical subsidiary, but a controllable, scalable infrastructure for the product. From model selection and rule formulation to development collaboration and testing and validation, every step is about the long-term maintainability of the system. This guide hopes to build a clear framework for permission awareness, avoid common pitfalls, and reduce rework. If you are facing design challenges related to permissions, I hope this article can be a reference in your implementation practice.