Article | Mao Chengguang, ma pure on retail

As a merchant service company, Youzan helps businessmen succeed in the Internet era through its products and services. Under the tide of new retail, Youzan Retail provides merchants with different sizes of stores and online store management solutions, helping retailers to quickly enter the new retail era. Different from the traditional online shopping mall scene, retail is facing new business scenarios and problems. A mature new retail store usually needs to divide and match more than ten roles with different abilities, including boss, store manager, customer service, cashier, verification, warehouse management, finance and so on. One of the biggest challenges facing retailers is how to manage employees gracefully, allocate roles freely, and solve the problem of employee role management painlessly and smoothly. After the full analysis of retail business scenarios and the continuous exploration and discussion of employee role management solutions, the Security Access Manager (SAM) came into being. SAM is a milestone in the exploration of employee role permission management by Youzan Retail. It supports the permission business of retail PC, App and Pad products. Any retail store that uses Youzan Retail can flexibly assign roles and responsibilities to employees through the service provided by SAM’s permission system, so as to improve the operation efficiency of the store. While supporting retail business, it abstracts out a set of authority management framework to support other business line products (micro mall).

Before introducing the SAM system, I will first understand the concept and design of the permission system with several cases.

Many things in the computer world are a shadow of the real world, and many patterns/concepts seen in the real world can be found in the computer world. Ever remember, QQ stealth to her visible, afraid she can not see, offline and online, but still be ignored; Ever remember, intimate lovers, after breaking up into the most familiar strangers, sad sad, wechat, telephone, QQ shielding. These cases are all a mapping of the computer permission system to the real world. You are invisible to the goddess, in fact, you give her the permission to see your invisible state (real state), of course, you also give others the permission to harm you; Lovers put each other on the blacklist, so they can’t see each other’s movements and become the most familiar strangers. From now on, pass by your world.

RBAC

In the example above, we can abstract the pattern: “Who performs How on What(Which)”. For example, in the case of lovers, after you block the other person, you will not see the other person’s messages in your moments (Who). This is a classic RBAC (role-based permission access Control) permission model. RBAC believes that authorization is really a Who, What, How issue. In the RBAC model, Who, What and How constitute the access triplet, that is, “Who (the owner or subject of the access) performs How (specific access) operations on What(Which) (the object or resource targeted by the access)”.

The RBAC model introduces the concept of “roles”. The so-called “role” is a set of operations that one or a group of users can perform in the system. It is a set of users and an authorization set. By assigning roles to users and assigning rights to roles, users are indirectly related to rights through roles. The basic RBAC model is shown in the figure below:

In RBAC, the relationship between users and roles and between roles and permissions is many-to-many. A session is a mapping of a user to multiple roles. In this case, the user permission can be the union of the rights of the active role. RBAC’s resource authorization management process is divided into two parts. First, access permissions are associated with roles, and then roles are associated with users. In this way, users and access permissions are logically separated.

Permission System SAM

SAM authority system model design

RBAC model is different from mandatory access control and discretionary access control that directly grant user permissions, but assign permissions to roles. In RBAC, permissions are associated with roles, and users gain permissions for these roles by becoming members of appropriate roles. Roles can be granted new permissions based on new requirements and system consolidation, and permissions can be withdrawn from a role as needed. RBAC is a more neutral and flexible access control technology than traditional access control. From the perspective of employee role management in a retail store, roles are created for completing various jobs, and employees are assigned corresponding roles according to their responsibilities and qualifications. Employees should be easily assigned from one role to another. Therefore, retail chooses RBAC model to implement the authority system to solve the problem of managing employees’ roles.

According to the IDEA of RBAC model, SAM authority system business model is designed into two parts: employee management and authority management. Employee management mainly refers to managing employees and assigning roles to employees. Authority management mainly refers to managing menu, page, button, API and other resources. The user – role – permission – resource authorization model is made up of the management roles’ requests to resource subjects.

Here are some common languages in the SAM permission system model:

  • Employee: carrier of role and executor of authority
  • Role: A role is further mapped to a permission set. The service system can dynamically manage roles. A default role list can be provided for each service to facilitate user use and meet different employee rights
  • Permission point: globally unique status used to represent the permission corresponding to a function point
  • Function point: logically defined minimum basic unit used to describe system resources, each function point corresponds to a unique permission point
  • Feature set (permission set) : A set of feature points that are grouped in a specific format
  • API: Channels and actions that request system resources, with feature set properties
  • Menu: An entry point for organizing system resources and presenting them to requesters, with feature set properties
  • Page: Treated as a special menu with URL attributes
  • Button: A more fine-grained entry to a resource on a page, used as a special menu

Implementation of SAM authority system model

In the traditional RBAC model, a relational table is usually used to store the corresponding relationship between roles and permission sets, so that permissions are associated with roles. Predictably, with the continuous development of retail business, countless function points will be accumulated, resulting in extremely difficult to maintain and use the data of associated table. SAM permission system solves this problem by using the base conversion strategy, and improves storage efficiency and permission determination efficiency. A decimal number of base type Long, which can also be viewed as a binary of 64-bit zeros or ones. In the design of SAM system model, each function point is defined as a permission point, which is guaranteed to be a globally unique permission point by idX and POS attributes. Idx represents the number of longs, pos represents the position in the binary number corresponding to Long, and the 64-bit length can represent 64 different function points. When the 64 bits are full and no more function points can be held, the IDX property increases and a new Long space is applied. Such a 64-bit Long number, with a combination of zeros and ones, can represent state descriptions of permissions for up to 64 different function points.

For example, permission set {1} means the permission of idx=0,pos =0, and permission set {-1,1} means the permission of IDx =0,pos∈[0,1,2,..,63] and IDx =1,pos=0.

SAM authority system manages the relation between resources and the function points represented by the way of base, uses the idea of computer base, abstracts the function set conversion formula to complete the mapping between resources and binary, as well as the mapping between roles and binary.

Permission set conversion formula: {(IDx0, POS0),(IDx0, POS1)… (idxN, posM)} = > {Long0 Long1… LongN}

SAM permission system also realizes “Who performs How operations on What” through the base concept. When a role requests a resource (menu /API), the role can determine whether it has the permission to access the resource based on the calculation formula of permission verification — the concept of “and” operation in the base (see below). Using the base to realize the operation, the efficiency of authority determination will become more efficient. For example, a warehouse when click an inventory menu, the authority behind the check formula, in fact is the role of permissions set and bitwise and computing resource permissions set, any number of independence idx pair of Long is not 0, namely two collection has the function of the public collection, think the role has permissions to access to resources.

Permission verification calculation formula: {Long0,Long1… LongN} and {Long0 Long1… LongM}

The implementation of SAM authority system model follows three principles of RBAC model: the principle of minimum authority, the principle of responsibility separation and the principle of data abstraction. The principle of separation of responsibilities can be embodied by invoking separate and mutually exclusive roles to accomplish sensitive tasks, such as requiring a warehouse and commodity manager to participate in a commodity. Data abstraction can be reflected through the abstraction of permissions, such as warehouse operation goods delivery, inventory management and other abstract permissions, without the typical read, write, execute permissions provided by the operating system.

SAM Authority System architecture

Retail uses PC, App, and Pad to meet terminal requirements of different merchants. Therefore, SAM permission system needs to meet different client permission scenarios of retail and support product permission services of micro-mall. The SAM permission system provides external services in the form of microservices and adopts a distributed hierarchical architecture. The SAM permission system consists of two parts: the client and the server. The client is embedded in the service system in a lightweight way to control the access to resources for different service systems. The server interacts with the client by providing Dubbo and Nova services. The server mainly manages data for employees, menus, roles, APIS and function points. SAM as the basic service, daily request volume is huge, through Redis cache to solve performance problems, select Druid as the database connection pool, manage the database connection and release. At the same time, the system is observed by docking with the sky network monitoring platform to improve the stability of the system.

Menu apply colours to a drawing

The SAM accesses the system through the client, and menu rendering is performed on the client. Currently, SAM has provided two sets of PHP/Node JS clients for web layer access and rendering. The menu rendering process can be divided into three parts:

1. Node positioning

Menus are usually presented in the form of a tree according to system functions. Take retail PC background as an example, all elements displayed in the page are considered to be a menu, such menu elements include: menu, page, button. In background access, the user stays on the menu is usually a page, the page has a global unique attribute: URL, up: you can find the root node through the parent menu, down, the page may contain some sub-menus – buttons. Therefore, SAM only needs to locate the unique page menu in the background menu tree according to the currently requested URL, and obtain the node path of the menu and the button it owns.

2. Permission calculation

We have obtained the user’s role permissions and a complete menu tree. According to the permission set of each menu node, we can calculate the current user’s access rights to the node. According to the calculation results, the client can distinguish the menu rendering. For example, when a user accesses a page without permission through a URL, the message will be invalid, and the menu and button without permission will be automatically gray and cannot be clicked.

3. Attribute transfer

The default menu does not have URL properties. The URL attribute of the menu is generated through the URL transfer of the submenu. SAM selects the URL of the first submenu with permission as the attribute of the parent node and passes the URL to the first-level menu step by step.

API permission verification

In addition to menus, apis are another type of resource that is requested in a retail system. API validation is another guarantee of permission control in addition to menu rendering. When an API request from Carmen (API gateway) is forwarded to a specific service system, the SAM API verification client embedded in the service system determines whether the role has the permission to access the API based on the above permission verification calculation formula. If the role passes the permission verification, the following service logic is executed.

The specific process is shown in the figure below

API permission verification pseudo-code implementation:

AUTHPERM_ERROR(231000401," You do not have permission to perform this operation!" @ #) woven into point Before (" @ the annotation (com.youzan.sam.com mon. Auth) ") # def plane processing method handle (JoinPoint PJP) : # this switch can be enabled at startup or runtime to verify permissions on the API. Def pass=checkPermission() # if (pass.issuccess ()): If (pass.getdata ().get("isSuccess")): return else: throw new BusinessException(AUTHPERM_ERROR.getCode,AUTHPERM_ERROR.getMessage()); Else: throw BusinessException(pass.getCode(), pass.getMessage())) # check whether the permission check is required, for some internal calls can be directly skipped {... } # def kdt_id= rpcContext.getContext ().getAttachment(Constants.KDT_ID_KEY) def kdt_id= rpcContext.getContext () admin_id=RpcContext.getContext().getAttachment(Constants.ADMIN_ID_KEY) def service = RpcContext.getContext().getAttachment(Constants.SERVICE_KEY) def method = RpcContext.getContext().getAttachment(Constants.METHOD_KEY) def version = Rpccontext.getattachment ().GetAttachment (Constants.VERSION_KEY) # Verification of the above parameters {... } # through StaffPermServiceProxy access permissions set for the role of def staffPerm = StaffPermServiceProxy. GetStaffPerms (adminId, KdtId) # API obtained through APIPermServiceProxy permissions set def apiPerm = APIPermServiceProxy. GetServicePerms (service, version, Method () # check whether the role can access the API. } # return return passCopy the code

The API permission verification process can be summarized as follows:

  1. When the business side annotates the @Auth annotation on the CORRESPONDING API that requires permission verification, the Spring framework will scan the bean to see if it has the @Auth annotation annotation method when initializing the creation of the business bean. For the @Auth annotation annotation, the proxy class will be created. This permission slice is then woven into the proxy class;
  2. When a service calls a method annotated with @Auth annotation, the permission verification section logic will be executed. First, check the permission verification switch to determine whether permission verification is required. The switch can be set dynamically at run time.
  3. If necessary, then call the AuthService’s permission verification method. The AuthService will obtain the employee role permission information from the SAM server based on the store ID and user ID. Version Obtains the corresponding API permission from the SAM server (this method is more flexible than directly marking the permission point on the corresponding API. In addition, the service API version can be easily upgraded. At the same time, the API can be distributed with the Carmen (API gateway). Different vendors can verify permissions of different apis.
  4. After obtaining the role permission set and API permission set, perform permission verification based on the above role and permission verification logic. If the verification succeeds, the API request is formally initiated. If the verification fails, no permission is displayed.

SAM Authority system Abstract model

After analyzing the requirements, the product turns over the requirements to the development to complete. SAM authority system supports retail business as well as micro mall business. Retail each module has different products to support, in order to better meet the needs of service businesses, as well as facilitate the analysis of products. The SAM permission system can be abstracted into the following model. Merchants and products can connect to the SAM permission system from different perspectives. For example, as shown in the figure below, a merchant wants an operational role with the ability to create new items and view orders, and a cashier with only the ability to view orders. Product design analysis from its own point of view, the corresponding is commodity management, order management module, corresponding module under the corresponding commodity, order menu, finally reflected in the role of the page elements and API, for example, the button to create a new commodity, and the button to view the order will present different rendering styles; Button triggers correspond to different apis that interact with the back end, and different roles have different execution capabilities of the API.

future

Custom Role

After understanding the merchant’s needs, retail provides eight default roles to support the single-store version of the employee role problem. The retail business is complex, and default roles often don’t work for all scenarios, but some custom roles are now used in some retail stores. In the future, custom roles will be fully supported by various businesses, and any role with any permission can be customized.

Multiple roles

In order to reduce labor costs, some retailers often need to provide one employee with the ability to perform multiple roles. Retail businesses are already using multi-role capabilities.

Retail center support

Zhongtai retail is a flagship product of Youzan Retail, which aims to provide an omni-channel solution for merchants covering multiple online channels and multiple offline stores, and help merchants to attract new customers and improve re-purchase by using data-oriented operation ideas. Its business is very complex, involving the combination of multiple roles and permissions, and each vendor may have some personalized requirements. How to provide flexible adaptation capabilities is a challenge for SAM system.

Custom menu

In the past, the release of background functions online, is often controlled by the release system, release the function immediately online, once found fault immediately rolled back. Through menu management, SAM can control the rendering status of any menu, page, and button on the line in real time, and gracefully remove pages and functions.

Technical renovation

As a common infrastructure component for retail and other services, SAM needs to be a highly available, high-performance, scalable, and secure system. With the continuous access of services, the system is constantly reformed to support the continuous development of services.

conclusion

The access system belongs to the retail technical team of Youzan, which opens access to the outside world and staff servitization ability. At present, the team’s business is developing rapidly and HC is still open. We are looking forward to more people with lofty ideals to join us.