Rongyun | Design and Implementation of Enterprise Address Book

As the trigger point of other business functions in enterprise unified communications, the enterprise address book requires flexible and complete functions and an easy-to-use and convenient human-machine interface, so that users can successfully complete business collaboration, truly speed up the operation of the enterprise, and achieve cost reduction and efficiency improvement. Follow [RongCloud] to learn more about the collaborative office platform.

Previously, we have shared [In the blind spot of "corporate address book", the boundaries and dimensions of Rongyun] and [the era of cloud office, technology selection of enterprise address book]. This article will describe the design and implementation of enterprise-level address book.

---

demand analysis

The basic functions that the enterprise address book needs to provide are as follows:

1. Support enterprises to display in tree form according to the organizational structure.
2. View display is supported. Support administrators to view and change department, employee information and organizational structure in the management background.
3. Support administrators to add, delete, modify, and check operations on department nodes and employee nodes.
4. Supports fine-grained access control. Set different access rights for different employees, and enterprise managers have all operation rights.
5. Supports real-time synchronization of address book information. When employee or department information or even enterprise architecture changes, affected clients need to be notified in time to synchronize address book information.
6. Support clicking friends to trigger communication services such as voice conferences, instant messages, video conferences, and corporate live broadcasts.
7. Provide unified authentication service. Users only need to log in once and can use other services provided by the enterprise for a period of time.

Among them, real-time synchronization of address book information, fine-grained access control and unified authentication services are the core functions.

The real-time synchronization of address book information ensures the consistency of the user's local address book and the server address book; fine-grained access control ensures that users can obtain correct address book information; unified authentication service ensures that legitimate enterprise users can use without repeated authentication System authorization service.

---

Address book architecture design

Based on the functional requirements of the enterprise address book, the address book server architecture is designed as shown in Figure 1. The address book architecture layer is divided into application layer, interface access layer, unified authentication layer, service layer and database access layer . The communication between modules adopts The method of the message bus, that is, the modules do not directly send messages but send messages to the message queue. Using this communication method can reduce the coupling between the modules and facilitate the expansion and maintenance of the system modules.

Figure 1 - System Architecture Diagram

---

Functions and Modules

Business System Function Module

As shown in Figure 2, the functional module structure of the enterprise address book service, the client invokes the Webservice interface service provided by the server through the HTTP protocol.

According to the service object, it can be divided into three types of services.
One is to provide services for the Web side called Web-side services .
One type is the service provided for the mobile terminal, which is called the mobile terminal service .
Another category is the guaranteed service of the whole system, and the service provided for the Web side is called the basic service .

【Web Service】
Web-side services are mainly management , including role management, authority management, address book management, log management, enterprise management, and system management .

Figure 2 - Functional Block Diagram

√The role management and authority management modules are used to control the access rights of employees . √The address book management is used to add, delete, modify and check node information . The operation of adding, deleting, modifying and checking the enterprise √ System management mainly realizes the management of enterprise administrators

【Mobile service】
The main service provided for the mobile terminal is to obtain and update the address book.
The first login of the mobile terminal needs to obtain the address book of its corresponding role. If the server address book information changes, the address book of the local terminal needs to be updated synchronously, which is realized by the address book synchronization module.

【Basic services】
The basic services include unified authentication and security modules , and unified authentication includes identity authentication and single sign-on; the security module ensures that the data transmission of the address book service is safe and reliable.

Single sign- on means that when a user requests the address book service, the server needs to verify the legitimacy of the requesting user, and the system will provide the address book service for legitimate users, otherwise it will return a no-authority access prompt. The authentication process shown in Figure 3 will be involved in the user's service request.

Figure 3 - Permission Authentication Process

① The client sends an address book information synchronization request to the server. ② When the address book service receives the request message, it will call the verification module to verify the legitimacy of the user, that is, to determine whether the user is logged in. If you have logged in, go to step ⑤, and if you are not logged in, go to step ③
③ If the user is not logged in, the client returns to the identity authentication page ④ The user fills in the user name, password and other relevant authentication information on the identity authentication page for verification ⑤ If the user is logged in, the access rights are obtained according to the user role ⑥ Access the LDAP database to obtain the address book Information ⑦ The server returns the corresponding address book information

In order to increase the security of enterprise address book information transmission, the data transmission between the client and the server adopts SSL/TLS encryption, and the data stored in the database is encrypted and stored to prevent leakage.

Converged communication enterprise address book business related interfaces

The address book service needs to provide corresponding interface support for enterprise communication services, and also assist other services to obtain communication-related information. As shown in Figure 4, the enterprise address book service provides a wide range of interfaces to support enterprise communication services and other services.

【I1 interface】
It exists between the client and the server. The main functions are as follows:
√ Use RESTful to implement client-to-server query and update requests √ Use TLS security protocol to ensure secure transmission of information and data

Figure 4 - Schematic diagram of the address book interface

【I2 interface】
Located between the Web side and the server side, the main functions are as follows:
√ Realize operations such as adding, deleting, modifying, and querying the corporate address book through the Web √ Adopt TLS security protocol to ensure the secure transmission of information and data

【I3 interface】
It is located between the server and communication services such as IM or voice and video, so that the communication service can find relevant information of enterprises or individuals from the address book service for communication.

【I4 interface】
It is located between the address book service and the authority verification module. The message request of the client or other entity business to the address book service needs to be verified before legal users can use the address book service. This interface is used to provide authentication services.

【I5 interface】
The interface between the address book service and the user status presentation, the address book can obtain the user's status information through this interface.

【I6 interface】
Located between the address book service and other services, it is mainly used to provide address book query operations to other services.

Address Book Information Model

The address book information is stored in the LDAP database, and the description of each data element of the address book is shown in Table 1.

Table 1 - Data element descriptions

The attributes shown in the table above are the default attributes of the system, and administrators can add or delete attributes according to their needs when operating employee information.

Definition of Directory Schema (Schema)

The data of the enterprise address book in this article is described by the LDAP protocol, which abstracts the data in the database into a tree structure. Users only need to operate the nodes of this tree, which reduces the complexity of data operations. The data is stored in a relational database, MySQL is used in this article.

In addition, LDAP provides a rich language interface, which is beneficial to the operation of LDAP by different terminals. Schema (schema) is an important content of LDAP, which defines the storage format of data.

For example, define what attributes a node has. The openLDAP used in this paper contains some standard Schemas. Under the Schema folder of openLDAP, users can also expand according to their own needs, and only need to create a new Schema file under the Schema folder to define.

The enterprise address book is a contact list composed of all employees of the enterprise, and corresponds to the organizational structure set by the enterprise, and implements hierarchical management. According to the needs of the enterprise address book function, departments and employees and their information form a tree structure as shown in Figure 5.

Figure 5 - Organizational Chart of Corporate Contacts

The above is the Schema file defined by the extension in this paper. From the above, we can see that Schema is composed of four important elements: attribute, object class, several matching rules and grammar.

First, the attributes of department nodes are given, which are composed of department correspondence address, department name, department code, and the number of employees in the department. Then, the attributes of the employee node are given, including employee number, employee name, gender, age, mailing address, mobile phone number, SIP number, and the department to which they belong. Finally, the object types of the department node and employee node are given, and the attributes are added. into the object type.

Design of fine-grained permission access control based on RBAC model

Fine-grained is relatively coarse-grained. In the RBAC (Role-Based Access Control) model, fine-grained permission access control can be understood as controlling access to the object of the least privilege unit. The object of the least privilege unit is an object that cannot be further divided. The smallest unit of authority in the corporate address book is the employee's personal information such as phone numbers.

The enterprise address book implements fine-grained permission access control, optimizes system performance, reduces the amount of system code and reduces system complexity.

In the use of coarse-grained authority management system, in order to authorize access to the minimum authority unit, a large number of logic codes have to be written to control, which increases the difficulty of engineering and is inconvenient for authorization management.

Of course, it is difficult to minimize decomposition in practical engineering, and only fine-grained decomposition (R5) can be performed as much as possible. In this paper , based on the original "role-department-employee" rights management model, the "employee-information" management granularity is added to refine the rights and realize the control of the least-privileged access granularity.

The role-based access control RBAC model contains some basic concepts, including users, roles, permissions, subject and object, user-role assignment (URA), role-authority assignment (PRA), and session. In order to introduce the RBAC model, here are some basic concepts.

The subject <br>actively accesses the object, which is expressed as a system user or a process that operates on behalf of the user.

Object <br>The accessed object is a passive entity, represented as a file or directory in the operating system, or a database table, row, field, etc., or some peripherals such as projectors and printers.

User <br>The main body who accesses system data or resources, usually manifested as people, system processes or agents, etc. In most cases, it refers to people

Role <br>usually refers to a job position in a unit, this job position has specific rights and responsibilities, and the person who has this role has such rights and responsibilities.

Permission <br>refers to the entity that has been given an access mode. The access mode can also be said to be access rights, that is, which entities have the right to access. The rights include read, write, and execute. The accessed entities are related to specific application scenarios, which can be Database, address book, and peripherals, etc.

User-role assignment <br>Assign roles to users, a user can have multiple roles, and users have corresponding responsibilities and rights of roles after assignment.

Role-Permission Assignment <br>Assign permissions to roles. A role can be assigned multiple permissions. After assignment, the role has the ability to access system resources.

Session <br>refers to the process of user activation of roles. Participants have a user and a set of activated roles. Establishing a new session activates a new role.

A role intermediary is introduced between users and permissions, and the direct relationship between users and permissions is weakened into an indirect relationship, as shown in Figure 7; with roles as the intermediary, first create different system resource access permissions, and then create different roles , and assign corresponding permissions to them according to their different roles and responsibilities. After establishing a role-permission relationship, different roles will have different access permissions. According to the positions held by users, the corresponding roles are assigned to them, and the relationship between users and roles is established. This is the main idea of RBAC (Role-Based Access Control).

Figure 6 - Schematic diagram of RBAC authorization

The RBAC model decouples the direct relationship between users and permissions. Through roles and permissions association and user and role association, it realizes the assignment of permissions to users through roles; a user can have multiple roles, and a role can have multiple roles. kind of permissions. This design of RBAC greatly facilitates the management of authorization.

The RBAC model mainly involves the following elements:

Entity set <br>User set U (Users), role set R (Roles), permission set P (Permissions), session set S (Sessions)

entity relationship
PA (PxR) assigns permissions to roles: UA (UxR) assigns roles to users; RH (RxR) is role hierarchy. System administrators can create roles according to actual system requirements, assign permissions to roles and assign corresponding roles to different users. There is a many-to-many relationship between roles and permissions, and between users and roles, as shown in Figure 7.

The biggest feature of RBAC is that users obtain access rights through roles, which increases the flexibility of rights management and reduces management errors.

When the user's position in the company changes, it is only necessary to remove the original role of the employee and reassign the role corresponding to the new position to avoid reauthorization caused by the transfer of the employee's position. When the company's organizational structure changes, roles can also be reset according to the company's new organizational structure.

In addition, roles can also have an inheritance relationship like the hierarchical relationship of departments, and high-level roles can inherit the access rights of low-level roles. These are all manifestations of the flexibility of RBAC authorization, and of course, it also reduces the cost of authorization management for enterprises.

Figure 7 - RBAC association

Information model design based on "role-department-employee-information" fine-grained access control

grouping of nodes

Figure 8 - Schematic diagram of node grouping

Due to the large number of corporate departments and employees, it is impossible for administrators to set a role to access each department and each employee when creating permissions. In order to facilitate permission setting, this article regards departments and employees with similar functions and responsibilities as It is of the same type. When creating departments and employees, the system will assign them the inherent type attribute. Those with the same type can be regarded as the same group. When setting visibility, the administrator does not need to set the visibility for each department or employee. Visibility, you only need to set the visibility of department groups and employee groups, as shown in Figure 8.

third-level authority

Based on the fine-grained access control concept of "role-department-employee-information", the authority classification model of "role-department-employee-information" proposed in this paper consists of three levels of authority. The corporate address book consists of multiple departments, and each department contains multiple employees. Each employee has various personal information. These specific personal information can be considered as the smallest unit that cannot be decomposed.

In our "role-department-employee-information" model, these personal information of employees belong to the least level of permissions - the third- level permissions , and the individuals containing these information are their parent permissions - the second- level permissions , including the employee's The department has the highest authority level - first level authority .

assignment of permissions

Based on the concept of "role-department-employee-information" fine-grained access control, users with different roles have different access rights to the system. Therefore, after the user enters the system, the system queries the user's permission set according to the user's ID, returns the visible department to the client according to the first-level permission, and returns the visible employee according to the second-level permission, and the client can generate local communication after receiving the returned information. The department menu of the record and the employees included in each department, and then return the corresponding personal information to the client according to the three-level authority system. Finally, the client parses the received message to obtain the local address book.

According to the above analysis, when administrators manage access rights, they first need to set permissions at all levels, then assign permissions to roles, and finally assign roles to employees, so that employees can control the access permissions of the address book.

Figure 9 - Permission management model diagram

Through the above analysis, the authority grading model based on "role-department-employee-information" realizes fine-grained access control of authority, and minimizes the control of authority to the specific personal information of employees; and according to the access control model of RBAC, we obtain Figure 9 shows the authority management model diagram of "role-department-employee-information".

entity relationship model

The entity relationship model is based on the hierarchical and fine-grained permission control model of "role-department-employee-information", which effectively realizes the user's access permission control. The entity relationship diagram is shown in Figure 10.

Figure 10 - Entity Relationship Model

Several tables can be derived from the ER model diagram above:
①Department table: Define departments and their attributes ②User table: Define users and their attributes ③Role table: Define roles and their attributes ⑥Three-level permission table: Define the access authority to employee information ⑦ Department user table: Define the affiliation of employees to various departments Access relationship between departments, employees, and personal information

database design

The system's department information, user information and the subordinate relationship between them will be represented by the LDAP database. The design of the department and employee table given here is only to clarify the logical relationship between the involved entities.

The remaining tables are stored in MySQL, and the database design is shown in Figure 11.

Figure 11 - Privilege Database Design

According to the RBAC idea, users, roles, and permissions are independent of each other, and are associated with the user role table and the role permission table respectively. The primary key role ID is used as a foreign key to associate with the role table; the role permission table is associated with the role by referring to the primary key role ID in the role table as a foreign key, and by referring to the primary key permission ID in the permission table at all levels as a foreign key and permissions at all levels Table association; the department and user tables each have a type field, which is used for group management of departments and employees, which is convenient for administrators to control permissions.