EA044265B1 - METHOD OF SETTING USER POWERS IN THE INFORMATION EXCHANGE BLOCK IN THE SYSTEM - Google Patents

Description

Field of technology

The invention relates to management software systems, such as ERP (Enterprise Resource Planning), and, in particular, to a method for setting user permissions in a communication unit in the system.

Prior Art

Role-Based Access Control (RBAC) is one of the most studied and developed permission management mechanisms for databases in recent years. It is considered an ideal option to replace the conventional Mandatory Access Control (MAC) and Discretionary Access Control (DAC). The basic idea of role-based access control (RBAC) is to separate different roles according to different functional positions within an enterprise organization, encapsulate access permission to database resources in roles, and allow users indirect access to database resources by assigning different roles for users.

Large-scale application systems often have a large number of tables and views built into them, making database resource management and authorization significantly more complex. It is very difficult for the user to directly control access and permissions of database resources. This requires the user to have a deep understanding of the database structure and knowledge of the SQL language. As application system design or security requirements change, a large number of complex and extensive permission changes are required, which is very likely to result in information security vulnerabilities caused by unexpected authorization errors. Therefore, developing a simple and effective way to manage permissions for large-scale application systems has become a common requirement for systems and system users.

The role-based permission management mechanism makes it easy and efficient to manage system permissions, which greatly reduces the burden and cost of system rights management, and makes system rights management more compatible with the technical requirements of application system business management.

However, the traditional way of managing user permissions based on roles uses a one-to-many role-to-user relationship mechanism, where the role represents a group/class. This means that one role can simultaneously correspond to or be associated with multiple users, and the role is similar to a position/title/type of work or other concepts. According to this communication mechanism, authority authorization for a user is mainly performed in the following three ways: 1. As shown in FIG. 1, direct user authorization has the disadvantage of high workload and frequency and volume of operations. 2. As shown in FIG. 2, a role (representing a class/group/position/job type) is authorized (one role can be associated with multiple users), and the user gains authority through his role. 3. As shown in FIG. 3, The above two methods are combined.

In the above descriptions 2 and 3, it is necessary to carry out authorization of the class/group type role. The authorization method through a class/group/position/job type role has the following disadvantages:

1. Difficulties in performing operations if user permissions change. During actual use of the system, user permissions are subject to frequent changes. For example, when processing changes to an employee's permissions, when the employee's permissions associated with a role change, it is not practical to change the permissions of the entire role because an individual employee's permissions change because that role is also associated with other employees whose permissions remain the same. As a result, either a new role is created corresponding to the employee whose permissions were changed, or the permissions are directly granted to the employee (not associated with the role) based on the permission requirements. The above two processing methods are not only time-consuming, but also easily lead to errors in role authorization in case the role has high authority. The user has to do a lot of work, which results in errors that lead to losses for the system user.

2. It is difficult to retain the specific powers contained in the role in memory for a long time. If a role has many functional authorities, over time it is difficult to remember the role's specific authorities, and even more difficult to remember the differences in authority between roles with similar authorities. If you need to associate a new user, it is not possible to know exactly how to select an association.

3. As user permissions change, more roles will be created (if new roles are not created, the immediate authorization for the user will increase significantly), and it will be more difficult to find specific differences between role permissions.

4. When transferring a user to another position and the need to assign a large number of powers of the transferred user to other users, it is necessary to separate the powers of the transferred user and create roles for communication with other users, respectively, necessary for processing. Such operations are not only complex and time-consuming, but also prone to

- 1 044265 errors.

There are many sections installed in the information exchange unit (such as the knowledge base) of existing management software. Each section contains information about a different area or a different department. If the user's authority in the information section of the system communication unit cannot be effectively managed over time, the information section of the system communication unit easily stops working normally and efficiently. Setting permissions is done using the following existing methods. The first way is to directly set permissions for the user. If the method is used to directly set the user's authority when the user's work content, position or other information has changed, information leakage will occur if the user's authority in the information section of the information exchange block is not changed in a timely manner. For example, research and development data section, sales data section, financial data section, etc. are set in the knowledge base block. If employee A in the finance department can load data from the financial data section, and employee A's permissions in the knowledge base block do not change over time after employee A moves from the finance department to the sales department, employee A will still be able to load data from the financial data section after transfer to the sales department, and may also perform operations on data that is subsequently added to the financial data section, resulting in financial data leakage. In addition, Employee A is also prohibited from downloading data from the sales data section, which affects his normal work.

However, in practical application, there may be many users in one system, and the work content and positions of users change frequently. Thus, it is difficult to ensure that all the permissions of these users in the information section of the information exchange block change over time, which leads to hidden risks of information leakage. In addition, whenever the job content, position, etc. of the user changes, the user's authority in the information section of the information exchange unit must be set again, resulting in a huge workload for setting authority.

The second way is to set permissions based on the type of work. This way of setting permissions depending on the type of work can also cause information leakage. For example, when an information exchange unit contains a sales section for an aviation division and a sales section for a furniture division. If the permissions are set based on the sales job type (the above two sections are set as available to employees belonging to the sales job type), a salesperson in the furniture division can view the aviation division's sales section information, resulting in information leakage.

The third way is to set authority on a department basis. This method of setting authority on a department basis can also cause information leakage. For example, there may be several types of work in each department. For example, a sales department includes the following jobs, such as a sales engineer and a clerk who assists the sales engineer in preparing data; and the production department includes the following types of work such as assemblers and testers. If permissions are set on a department basis, employees belonging to different types of work can have the same permissions in the information exchange block, making information leakage easier. In another example, when a department includes the following types of work, such as employees and a manager, it is not possible to allow a manager to participate in only one section in the information exchange block.

In addition, some existing information exchange blocks are not further divided into sections. Therefore, any person who is allowed to enter the information exchange unit can perform operations on the information in the information exchange unit, such as viewing information, which increases the likelihood of information leakage. For example, a salesperson may view research and development information, etc., which is not related to the content of his work, in the information sharing unit, resulting in leakage of research and development information.

Installation of management personnel: In case the subject is appointed directly as management personnel, assuming that Zhang San is currently a sales management job type and is in charge of managing the sales department, after Zhang San is transferred to a production position, another employee must take the place Zhang San to manage the sales department. If the authority is not set in a timely manner, Zhang San may not only view the company's subsequent sales data or market information, but also download/modify/delete data, resulting in information leakage and other losses for the company. On the other hand, if the moderator of this department needs to verify the uploaded data because Zhang San has been transferred from this position and has ceased to be responsible for this position, then Zhang San does not need to verify the data to be verified, and therefore the data submitted for verification, cannot be checked in time. Even if a new moderator takes over the work of this department in the future, the new moderator is deprived of the ability to verify the data previously uploaded for verification, since the task of verification remains with Zhang San.

- 2 044265

Disclosure of the invention

Technical tasks.

The present invention is aimed at overcoming the disadvantages of the prior art and providing a method for setting user permissions in a communication unit in a system. When changing the content of an employee's work or position, there is no need to separately set the employee's permissions in the information section of the information exchange block.

Problem solving. Technical solutions.

The purpose of the present invention is realized using the following technical solutions.

The method for setting user permissions in the information exchange block in the system includes:

(1) setting up one or more information sections for the information exchange unit;

(2) setting participant roles respectively for each information section, said participant role including one or more roles in the system; and setting the authority of each of the participation roles in the information section, with each role representing an independent subject rather than a group/class, one role can only be associated with a unique user for one period, and one user is associated with one or more roles; and (3) creating connections between users and roles in the system.

Step (1) and step (2) are performed sequentially, and step (3) may be performed before step (1), after step (1), before step (2), or after step (2).

Preferably, the authority of said role in the information section includes participation authority and/or control authority.

Preferably, said participation credentials include one or more types of verifiable data (content/information), downloadable data (content/information), uploadable data (content/information), and evaluated data (content/information).

Preferably, said control authority includes one or more types of evaluation of viewed data (content/information), downloaded data (content/information), modified data (content/information), uploaded data (content/information), evaluated data (content/information). information), archived data (content/information), unarchived data (content/information), verifiable data (content/information) and deleted data (content/information).

Preferably, said control authority includes at least one level.

Preferably, if a department is selected for a role, when the role is created or after it is created, the role is owned by the department, the role is authorized according to the role's job content, the role name is unique within the department, and the role number is unique within the system.

Preferably, when the specified user is transferred from a position, the user's association with the role corresponding to the original position is canceled, and the user is associated with the role corresponding to the new position.

Preferably, one employee matches one user, one user matches one employee, and the employee determines (gets) his authority in the information exchange block based on the role associated with the user matching the employee; after an employee leaves his position, the user matching the employee is frozen; and when an employee is rehired, the user previously matched with that employee is unfrozen and serves as the current user matched with that employee. During the freeze period, the user cannot serve as a user matching with an employee.

Preferably, when an employee who is the same as a user associated with a role assigned management authority reviews the data, the data transfer rate over a given time is obtained by dividing the number of persons who submitted the results of the review and passed the test by the total number of persons who submitted the results of the review . The verification method described above can also be a verification and approval method.

A method for setting user permissions in an information exchange block in a system includes: setting up one or more information sections for an information exchange block; setting the permissions of a role in each information section in the system, with each role representing an independent subject rather than a group/class, where one role can only be associated with a unique user for one period, and one user is associated with one or more roles; and creating connections between users and roles in the system.

Positive effects of the invention. Positive effects.

The present invention has the following beneficial effects.

(1) In the present invention, the user's authority in the information section of the communication block is set based on role. When a user is transferred from a position, the user's association with the role corresponding to the original position is unassigned, and the user is associated with the role corresponding to the new position. User permissions in the information section of the block

- 3 044265 information exchanges change when the user's operating permissions change, and the permissions in the information section of the information exchange block do not require a separate change for the user. This not only ensures that the user permissions in the information section of the communication unit are updated in time, but also greatly reduces the burden for setting the user permissions in the information section of the communication unit.

For example, Employee A's job content includes product development and product sales. The work content for role 1 is product development, and role 1 has the authority to view data, load data, and upload data in the research and development data section. The job content for role 2 is selling a product, and role 2 has the authority to view data, load data, and upload data in the sales data section. The work content for role 3 is product manufacturing, and role 3 has the authority to view data, load data, and upload data in the product manufacturing data section. By associating Role 1 and Role 2 with only the user matching Employee A, not only is Employee A's work content authorized, but Employee A is also allowed to view data, download data, and upload data in the R&D data section and the sales data section . To configure the content of the work of employee A only for product development, you only need to cancel the connection of user 2 with the user that matches employee A, and at the same time, the content of the work of employee A and his powers in the information section of the information exchange block are configured. To configure the work content of employee A to produce a product, you only need to unlink role 1 and role 2 from the user matching employee A, and associate the user matching employee A with role 3, and at the same time setting up the work content of employee A and his powers in the information section of the information exchange block.

(2) The information exchange section of the present invention includes a plurality of information sections. The role permissions in each information section are set accordingly to limit the participation roles in each information section and further limit the user's participation authority in each information section, and prevent information in each information section from leaking to unrelated persons.

(3) The traditional authority management mechanism defines a role as the nature of a group, job, class, or the like. A role is in a one-to-many relationship with a user. During actual use of the system, user permissions are subject to frequent changes. For example, during the process of processing a change in employee permissions, when the employee permissions associated with a role change, it is not practical to change the permissions of the entire role because of a change in the permissions of an individual employee because the role is also associated with other employees whose permissions remain the same. As a result, either a new role is created corresponding to the employee whose permissions were changed, or the permissions are directly granted to the employee (not associated with the role) based on the permission requirements. The above two processing methods are not only time-consuming, but also easily lead to errors in role authorization in case the role has high authority. The user has to do a lot of work, which results in errors that lead to losses for the system user.

However, according to the method proposed in this application, since the role is an independent entity, the goal can be achieved by changing the authority of the role. Although the method of the present application appears to increase the workload during system initialization, by copying or the like, a role can be created or authorized more efficiently than conventional roles having a group nature. Since there is no need to consider the commonality of roles having a group nature when satisfying associated users, the solutions proposed in this application make the setting of permissions clear and unambiguous. In particular, after using the system for a certain period of time (after dynamically changing the user/role permissions), the solutions according to the present application can significantly improve the efficiency of authority management for the system user when using the system, make dynamic authorization simpler, more convenient, clearer and more understandable, and also improve the efficiency and reliability of setting permissions.

(4) The usual way of authorizing a role with the nature of a group is prone to error. The method provided by the present application significantly reduces the likelihood of authorization errors, since the method described in this application must consider the role only as an independent entity, without taking into account the commonality of multiple users associated with the role having a group nature in the conventional method. Even if authorization errors occur, only the user associated with the role is affected. However, in the case of a generic role that is in the nature of a group, all users associated with that role are affected. Even if authorization errors occur, the correction method according to the present application is simple and takes little time, while in the case of a normal role having the nature of a group, the commonality of authority of all users related to the needs of the role must be taken into account when correcting errors. With a large number of function points, modification is cumbersome, complex and error-prone, and in many cases the problem

- 4 044265 cannot be resolved without creating a new role.

(5) In the traditional group-based role authorization method, if a role has many functional powers, over time it is difficult to remember the specific powers of the role, and even more difficult to remember the differences in powers between roles with similar powers. If you need to associate a new user, it is not possible to know exactly how to select an association. In the method of the present application, the role itself has the character of a position number/station number so that the selection can be made easily.

(6) When transferring a user to another position and need to assign a large number of powers of the transferred user to other users, during processing it is necessary to separate the powers of the transferred user and create roles to communicate with other users accordingly. Such operations are complex, time-consuming, and prone to errors.

The method according to the present application is as follows: the transferred user is associated with several roles. When a user is transferred from a position, the user's association with roles in the original department is first unassigned (unselected roles may be associated with other users), and then the user is associated with a role in the new department. The operation is simple and not prone to errors.

(7) When creating a role or after it, you must select a department, and then the department to which the role belongs cannot be changed. The reasons why the department that owns the role cannot be replaced are as follows. Reason 1: Since the role of this application is essentially equivalent to a workstation number or job number, different station numbers or job numbers have different job content or authority. For example, sales role 1 in the sales department and developer role 1 in the technical department have two completely different station numbers or job numbers, and have different authorities. Reason 2: If the department (sales department) that owns the role of salesperson 1 is replaced by the technical department without changing the authority of the salesperson 1 role, then a role exists in the technical department that owns the sales department authority. This leads to management confusion and security vulnerabilities.

Brief description of graphic materials

Description of graphic materials.

In fig. 1 is a schematic representation of direct user authorization by the system in the prior art.

In fig. 2 shows a schematic representation of authorization in a system of a group or class role in the prior art.

In fig. 3 shows a schematic representation of direct authorization in the system of both the user and the role of a group or class nature in the prior art.

In fig. 4 shows a sequence of operations according to the present invention.

In fig. 5 shows a schematic diagram of user authorization in the system based on a role having the nature of an independent subject, according to the present invention.

In fig. 6 is a flowchart of another embodiment according to the present invention.

Carrying out the invention

Description of embodiments of the invention.

The technical solutions of the present invention will be described below in more detail with reference to the accompanying figures, but the scope of protection of the present invention is not limited to the following description.

[Embodiment 1]

As shown in FIG. 4, the method for setting the user authority in the communication unit in the system includes: setting a plurality of information sections (or information categories) for the communication unit, such as setting the electrical section, mechanical section, chemical industry section, financial section, management section, etc. item in the knowledge base; and setting participation roles for each information section, respectively, wherein the participation role includes one or more roles in the system; and setting the authority of each of the participation roles in the information section, with each role representing an independent subject rather than a group/class, one role can only be associated with a unique user for one period, and one user is associated with one or more roles; that is, for each information topic, select one or more roles from the roles in the system as the information topic participation roles, and set the permissions for each of the information topic participation roles.

As shown in FIG. 5, the role represents an independent entity, not a group/class. One role can only be associated with a unique user for one period, and one user can be associated with one or more roles. When or after a role is created, a department is selected for the role, so the role belongs to the department. Authorization of a role is done according to its work content, the role name is unique in the department, and the role number is unique in the system.

Role Definition: A role is not inherently a group/class/category/position/position/job type or the like, but is not collective in nature. The role is unique and

- 5 044265 is an independent entity. When used in an enterprise or institution, a role is equivalent to a position number (a position number is not a position, and one position can have several employees at the same time, but one position number can correspond to only one employee during one period).

For example, the following roles can be created in the company's system: General Manager, Deputy General Manager 1, Deputy General Manager 2, Beijing Sales Manager I, Beijing Sales Manager II, Beijing Sales Manager III, Shanghai Sales Engineer 1, Shanghai Engineer Sales 2, Shanghai Sales Engineer 3, Shanghai Sales Engineer 4, Shanghai Sales Engineer 5 and so on. The relationship between users and roles is as follows: if Zhang San, an employee of a company, acts as deputy general manager 2 and at the same time acts as a manager of Beijing Sales Department I, then Zhang San should be associated with the role of deputy general manager 2 and the role of Beijing Sales Department Manager I, that is, Zhang San has the authority of two roles.

The concept of traditional roles is essentially a group/class/position/position/job type, and one role can correspond to multiple users. However, in this application, the concept of a role is equivalent to a job number/job number, and is also similar to a role in film and television drama: one role (in childhood, adolescence, middle age...) can only be performed by one actor or actress at a time, but one actor or an actress can play several roles.

When a user is transferred from a position, the user's association with the role in the original department is unassigned, and the user is associated with the role in the new department. Once a role is created, a user can be associated with the role during the user creation process, or can be associated with a role at any time after the user is created. Once a user is associated with a role, the user can be released from the role's association at any time, and an association between the user and another role can be created at any time.

The role permissions in the information section include participation authority and/or management authority, so that users in the information section can be divided into participants and managers in the information section of the information exchange block. Different authorities are assigned to members and managers respectively (participation authority is assigned to the participant and management authority is assigned to the manager), which helps maintain the normal operation of the information section of the information exchange block.

Said participation rights include one or more types of viewing data, loading data, uploading data, evaluating data, etc. In addition, the participation rights include at least rights to view data.

Said management permissions include one or more types of view data, download downloadable data, modify data, upload data, evaluate data, archive data, unarchive data, validate data, delete data evaluation, etc.

One employee matches one user, one user matches one employee, and the employee assigns (gains) permissions based on the role associated with the user matched to the employee.

Said control authority includes at least one level. For example, management authority includes two levels, one of which is ordinary management authority and the other is special management authority. An employee with normal management authority manages the relevant information section (eg, verifies data), and an employee with special management authority monitors the quality of management performed by the employee with normal management authority in the corresponding information section.

When a person corresponding to a role assigned management authority reviews data (for example, downloaded data), the data transfer rate within a specified time (the specified time is user defined) is obtained by dividing the number of persons who submitted the results of the review and passed the review by the total number persons who presented the results of the inspection. When the data transfer rate is greater than or equal to the specified value, the test is passed. Otherwise the check failed. This significantly reduces the data verification period.

In addition, the contents of ordinary management authority include one or more types of data viewing, data checking, data deletion, and data evaluation deletion, as well as one or more types of data loading, data uploading, and data evaluation. The contents of special management permissions include one or more types of view data, archive data, unarchive data, load data, upload data, evaluate data, validate data, delete data, and delete data evaluation. Data archiving is intended to conceal data (including related data evaluation information, etc.). Once data is archived, only employees with special management authority can perform such

- 6 044265 operations such as viewing data, and employees with normal management and participation permissions cannot view archived data. Unarchiving data restores display of archived data, and the unarchived data is restored to its last state before archiving.

The method further includes the step of creating relationships between users and roles in the system.

[Embodiment 2]

As shown in FIG. 6, the method for setting the user authority in the communication unit in the system includes: setting a plurality of information sections (or information categories) for the communication unit, such as setting the electrical section, mechanical section, chemical industry section, financial section, management section, etc. item in the knowledge base; and setting the authority of a role in the system in each information section, with each role representing an independent subject rather than a group/class, where one role can only be associated with a unique user for one period, and one user is associated with one or more roles .

The role represents an independent entity, not a group/class. One role can only be associated with a unique user for one period, and one user can be associated with one or more roles. When or after a role is created, a department is selected for the role, so the role belongs to the department. The authorization of a role is done according to the scope of its work, the role name is unique in the department, and the role number is unique in the system.

When a user is transferred from a position, the user's association with the role in the original department is unassigned, and the user is associated with the role in the new department. After a role is created, a user can be associated with the role during the user creation process, or can be associated with a role at any time after the user is created. Once a user is associated with a role, the user can be released from the role's association at any time, and an association between the user and another role can be created at any time.

The role permissions in the information section include participation authority and/or management authority, so that users in the information section can be divided into participants and managers in the information section of the information exchange block. Different/corresponding authorities are assigned to members and managers respectively (participation authority is assigned to the participant and management authority is assigned to the manager), which helps to maintain the normal operation of the information section of the information exchange block.

Specified participation permissions include one or more of the types of viewing data, loading data, uploading data, and evaluating data. In addition, the participation authority includes at least the authority to view the data.

The specified management permissions include one or more of the types of view data, load downloadable data, modify data, upload data, evaluate data, archive data, unarchive data, validate data, and delete data evaluation.

One employee matches one user, one user matches one employee, and the employee assigns (gains) permissions based on the role associated with the user matched to the employee.

Said control authority includes at least one level. For example, management authority includes two levels, one of which is ordinary management authority and the other is special management authority. An employee corresponding to the normal management authority manages the corresponding information section, and an employee corresponding to the special management authority monitors the quality of management performed by the employee corresponding to the normal management authority in the corresponding information section.

The contents of normal management permissions include one or more types of view data, load data, upload data, evaluate data, validate data, delete data, and delete data evaluation. The contents of special management permissions include one or more types of view data, load data, upload data, evaluate data, archive data, unarchive data, validate data, delete data, and delete data evaluation. Archived data serves to hide data. Once data is archived, only employees with special management permissions can perform operations such as viewing the data, and employees with regular management and participation permissions cannot view the archived data. Unarchive data is used to resume display of archived data, and the unarchived data is restored to its last state before archiving.

The method further includes the step of creating relationships between users and roles in the system.

The foregoing represents only the preferred embodiments of this

-

Claims (9)

inventions. It should be understood that the invention is not limited to the embodiments disclosed herein and should not be construed to exclude other embodiments, but may be used in various other combinations, modifications and environments. It can also be modified through the above principles or technologies and knowledge in related fields. All changes and modifications made by those skilled in the art without departing from the spirit and scope of the present invention are intended to be within the scope of the appended claims. CLAIM 1. A method for setting user permissions in the information exchange block in the system, including: installing one or more information sections for the information exchange unit; setting participant roles respectively for each information section, said participant role including one or more roles in the system; and setting the authority of each of the participation roles in the information section, with each role representing an independent subject rather than a group/class, one role can only be associated with a unique user for one period, and one user is associated with one or more roles; and creating connections between users and roles in the system; however, when the specified user is transferred from a position, the user's association with the role corresponding to the original position is canceled, and the user is associated with the role corresponding to the new position. 2. A method for setting user permissions in the information exchange block in the system according to claim 1, wherein the permissions of the specified role in the information section include permissions to participate and/or authority to manage. 3. A method for setting user permissions in a system information exchange block according to claim 2, wherein said participation permissions include one or more types of data viewing, data loading, data uploading, and data evaluation. 4. A method for setting user permissions in the information exchange block in the system according to claim 2, wherein said participation permissions include one or more types of viewing data, loading data, changing data, uploading data, evaluating data, archiving data, unarchiving data , data verification and deletion of data assessment. 5. A method for setting user permissions in an information exchange unit in a system according to claim 2, wherein said control permissions comprise at least one level. 6. A method for setting user permissions in the information exchange block in the system according to claim 1, in which, if a department is selected for a role when creating the role or after it, the role belongs to the department, the role is authorized in accordance with the work content of the role, the name of the role is unique in the department , and the role number is unique in the system. 7. A method for setting user permissions in an information exchange block in a system according to claim 1, wherein one employee matches one user, one user matches one employee, wherein the employee determines the powers based on the role associated with the user matching the employee. 8. The method for setting user authority in a system communication unit as set forth in claim 4, wherein when an employee matching a user associated with a role to which control authority is assigned checks the data, the data transmission rate for a specified time is obtained by dividing the number of persons who submitted the results of the inspection and passed the inspection, per the total number of persons who submitted the results of the inspection. 9. A method for setting user permissions in the information exchange block in the system, including: installing one or more information sections for the information exchange unit; setting the authority of a role in the system in each information section, with each role representing an independent subject rather than a group/class, where one role can only be associated with a unique user for one period, and one user is associated with one or more roles, and creating connections between users and roles in the system; however, when the specified user is transferred from a position, the user's association with the role corresponding to the original position is canceled, and the user is associated with the role corresponding to the new position. -