A saas software permission control method based on a double-layer role model

Abstract

The application belongs to the technical field of SaaS software permission management, and provides a SaaS software permission control method based on a double-layer role model, which comprises the following steps: S1: dividing the system permissions of the SaaS software into menu permissions, button permissions, list permissions, form permissions and data permissions, numbering and sorting the operation permissions under each type of system permission in sequence, and establishing a system permission subdivision matrix; S2: based on a business scenario, establishing a plurality of meta-roles, respectively corresponding to selecting a corresponding operation permission set, and establishing a meta-role system; S3: establishing a plurality of user roles, respectively corresponding to selecting a corresponding meta-role, and establishing a user role system. The application separates the strong coupling relationship between the user roles and the system permissions by means of a newly created intermediate meta-role layer and a mapping matrix of the meta-role layer and a tenant actual user role system, and establishes a weak coupling indirect corresponding relationship, thereby facilitating permission control.

Description

Technical Field

[0001] This invention relates to the field of SaaS software permission management technology, and specifically to a SaaS software permission control method based on a two-layer role model. Background Technology

[0002] SaaS, short for Software-as-a-Service, means providing software services over the internet. Due to its advantages such as low cost, rapid deployment, and simple upgrades and maintenance, SaaS software has entered a period of rapid development. However, in the process of development, the shortcomings of SaaS software have gradually surfaced, with access control being a typical example.

[0003] Software access control models have matured considerably, and for different access control strategies and business scenarios, there are models based on Discretionary Access Control (DAC), MAC, and the most widely used Role-Based Access Control (RBAC). However, for emerging SaaS software, traditional software access control models face significant challenges.

[0004] Because SaaS software emphasizes universality, the same access control mechanism must be used for different tenants. Therefore, when using the "user role-system permission" RBAC authorization mechanism, SaaS service providers need to establish a relatively universal role system, which different users can then select and assign roles to. For SaaS systems with simple business logic, this existing mechanism can adequately solve the access control problem. However, when dealing with more complex business scenarios, such as R&D management services for the R&D process or ERP for manufacturing, the existing mechanism cannot meet user needs. For non-SaaS software, a large number of personnel are typically deployed to the user company to customize a "system permission-user role" access control system based on the target company's individual needs. This challenge has led to the fact that the more successful SaaS software on the market is mainly concentrated in the C-end or some B-end system fields with simple business rules, such as recruitment management, which only involves roles such as HR, candidates, or some supervisors, and existing traditional methods can support this well. At the same time, the control of temporary authorization is also an important part of enterprise information management, and even users of simple administrative business have a strong demand for it. For example, temporary authorization of approval process permissions. The permission management method that establishes a set of general roles based on existing SaaS software and then uses the RBAC authorization mechanism of "user role-system permission" does not support temporary permission control, thus greatly limiting the development prospects of SaaS software. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a SaaS software permission control method based on a two-layer role model to solve or partially solve the above problems.

[0006] In a first aspect, embodiments of the present invention provide a SaaS software access control method based on a two-tier role model, comprising the following steps:

[0007] S1: Divide the system permissions of SaaS software into menu permissions, button permissions, list permissions, form permissions, and data permissions. Number and sort the operation permissions under each of the above-mentioned system permissions in turn to establish a system permission subdivision matrix.

[0008] S2: Based on business scenarios, establish several meta-roles, each corresponding to the selected set of operation permissions, to establish a meta-role system;

[0009] S3: Establish several user roles, and select the corresponding meta-roles to establish a user role system.

[0010] According to a specific implementation of an embodiment of the present invention, in step S2, the operation permission set includes a menu permission set, a button permission set, a list permission set, a form permission set, and a data permission set.

[0011] According to a specific implementation of an embodiment of the present invention, in step S2, after selecting the corresponding permissions, the system establishes a mapping matrix between meta-roles and several operation permissions.

[0012] According to a specific implementation of an embodiment of the present invention, step S3 includes the following steps:

[0013] S3.1: Establish several user roles and generate blank RASCI role correspondence matrices for each;

[0014] S3.2: In response to tenant operations, select the corresponding meta-role and define the actual RASCI role correspondence matrix;

[0015] S3.3: Establish a mapping matrix II between the user roles and several meta-roles, and establish the user role system.

[0016] According to a specific implementation of an embodiment of the present invention, step S3 further includes:

[0017] S3.4: Add function method judgment according to business rules, and associate several meta roles. If the function method is determined to be effective, grant the corresponding meta role operation permissions.

[0018] According to a specific implementation of an embodiment of the present invention, in step S3.4, the function method includes task variables, context variables, and temporal variables.

[0019] Secondly, embodiments of the present invention provide a SaaS software access control device based on a two-layer role model, comprising:

[0020] The permission division module is used to divide the system permissions of the SaaS software into menu permissions, button permissions, list permissions, form permissions, and data permissions, and to number and sort the operation permissions under the above-mentioned system permissions in turn to establish a system permission subdivision matrix.

[0021] The meta-role module is used to establish several meta-roles based on business scenarios, and to select the corresponding set of operation permissions to establish a meta-role system.

[0022] The user role module is used to create several user roles, each corresponding to a meta-role, to establish a user role system.

[0023] According to a specific implementation of an embodiment of the present invention, the user role module includes:

[0024] A module is established to create several user roles and generate blank RASCI role correspondence matrices for each role.

[0025] The selection module is used to respond to tenant operations, select the corresponding meta role, and define the actual RASCI role correspondence matrix;

[0026] The mapping module is used to establish a mapping matrix 2 between the user roles and several meta-roles, and to establish the user role system.

[0027] According to a specific implementation of an embodiment of the present invention, the user role module further includes:

[0028] The determination module is used to add function methods for determination based on business rules and associate them with several meta-roles. If the function method is determined to be effective, the corresponding meta-role is granted operation permissions.

[0029] The present invention provides a SaaS software access control method and apparatus based on a two-layer role model, which has at least the following technical effects:

[0030] First, this invention utilizes a two-layer role-based access control model. By establishing an intermediate meta-role layer and a mapping matrix between the meta-role layer and system permissions, as well as a mapping matrix between the meta-role layer and the tenant's actual user role system, it separates the strong coupling between user roles and system permissions in the original access control method and establishes a weakly coupled indirect mapping relationship. This indirect mapping relationship effectively solves the access control difficulties caused by factors such as the continuous improvement of system permissions with version upgrades, different tenants having different role systems, and even the dynamic changes in the role system of the same tenant. This allows tenants to complete customized access control simply by configuring the role mapping matrix.

[0031] Secondly, for SaaS software developers and operators, the system design and operation only need to target the meta-role system to meet the personalized needs of different tenants. This can greatly reduce the workload of relevant development and configuration personnel, and at the same time, it can better support temporary authorization control based on factors such as task, context, and temporality, breaking through the current bottleneck of SaaS software's inability to implement universal and complex permission management mechanisms. Attached Figure Description

[0032] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0033] Figure 1 The flowchart illustrates a SaaS software access control method based on a two-layer role model provided by an embodiment of the present invention.

[0034] Figure 2 A schematic diagram of a SaaS software access control method based on a two-layer role model is shown.

[0035] Figure 3 The diagram shows a structural block diagram of a SaaS software permission control device based on a two-layer role model provided by an embodiment of the present invention. Detailed Implementation

[0036] The embodiments of the technical solution of the present invention will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of the present invention and are therefore merely examples, and should not be construed as limiting the scope of protection of the present invention.

[0037] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application should have the ordinary meaning as understood by one of ordinary skill in the art to which this invention pertains.

[0038] Figure 1This invention provides a flowchart of the steps involved in a SaaS software access control method based on a two-layer role model. Figure 2 A schematic diagram of a SaaS software access control method based on a two-tier role model is shown. (See attached diagram) Figure 1 , Figure 2 The method includes the following steps:

[0039] S1: Divide the system permissions of the SaaS software into menu permissions, button permissions, list permissions, form permissions, and data permissions. Then, number and sort the operation permissions under each of the above system permissions to establish a system permission subdivision matrix.

[0040] Common permissions x in SaaS software systems are categorized into five types: menu permissions, button permissions, list permissions, form permissions, and data permissions, denoted as x. 1n x 2n x 3n x 4n , x5n .

[0041] Menu permissions restrict access to specific pages to authorized users, preventing unauthorized access. It's a coarse-grained control of permissions across the entire page. Since menus and pages are linked one-to-one, controlling the navigation menu effectively controls the page entry point, hence the name "menu permissions." Button permissions treat operation buttons as resources, such as the delete operation; some users may have access while others may not. For the backend, an operation is an interface. For the frontend, an operation is often a button; button permissions are fine-grained. A clear indication on the page is that the delete button will not be displayed or will be disabled for those without the necessary permissions. Similar fine-grained permissions include list permissions and form permissions, treating lists and forms on the page as resources for granular permission management. Data permissions primarily control row data, allowing different users different data viewing rules; for example, sales staff can only see their own data; sales managers can see data from all their subordinates; finance personnel can only see data with amounts greater than 5000, etc.

[0042] S2: Based on business scenarios, establish several meta-roles, each corresponding to a set of permissions for menus, buttons, lists, forms, and data, to create a meta-role system.

[0043] Meta-roles are mapped to several operation permissions. The system establishes a mapping matrix between meta-roles and several operation permissions, thereby establishing a complete meta-role layer T = [T1, T2, T3, ..., T...]. n ].

[0044] In the meta-role layer, the j-th meta-role can be denoted as T. jThe rules for establishing meta-roles are driven by business scenarios, based on functional implementation logic, and involve a mix of menus, buttons, lists, forms, and corresponding data. For example, if a meta-role T1 needs to report a problem, its processing function is implemented based on the problem feedback page x. 11 Problem identification page x 12 Problem handling page x 13 Several pages, feedback button x 21 Feedback on issues 31 Problem handling form x 41 and related question knowledge base data x 51 Human Resources Basic Information Database x 52 Therefore, the metarole T1 can be represented as {[x 11 x 12 x 13 x 1n ], [x 21 ], [x 31 ], [x 41 ], [x 51 x 52 This example demonstrates that meta-roles are closely related to business processes. They can be identified and addressed concurrently with the design of the information system, focusing on relevant pages, buttons, lists, forms, and data. This process is essential for information system development. Therefore, by simply reusing the process experience from the system design phase, the identification and construction of meta-roles can be completed. Based on the definition of meta-roles, it can be observed that they definitely exist... In scenarios where the permissions of two meta-roles overlap, due to software access control, duplicate authorization does not affect the logical control relationship between the operator and resources. Therefore, from a business perspective, meta-roles are not mutually exclusive. Establishing a meta-role layer is the core of this discovery. Through the configuration of the intermediate role layer, the strong coupling between system resources and actual user roles in the original control method is completely separated.

[0045] S3: Establish several user roles, and select corresponding meta-roles to establish a user role system. User roles and meta-roles have a mapping relationship.

[0046] Tenants obtain corresponding operation permissions based on the mapping matrix of corresponding user roles.

[0047] Actual tenant empowerment: The specific execution steps are as follows:

[0048] S3.1: Establish several user roles and generate blank RASCI role-correspondence matrices for each;

[0049] S3.2: Tenants select the corresponding meta-roles according to their actual needs and define the actual RASCI role correspondence matrix;

[0050] S3.3: The system establishes a mapping matrix between user roles and several meta-roles, and establishes a user role system.

[0051] Once a new tenant starts using the SaaS software system, roles can be configured for that tenant using meta-roles. For example, a tenant's internal role system y m This includes roles such as Chief Engineer, Deputy Chief Engineer, Product Manager, Business Manager, Project Supervisor, Project Accountant, and Designer. Tenants enter their roles into the system. m A blank RASCI role-to-role matrix can then be provided, supporting tenant-defined selections to establish a user role system. m He Yuan's character system T j The relationship. That is, the user role system of tenant m, role y. mn Its corresponding meta-role system [T1, T2, T3, ..., T n In this way, only a two-layer role system mapping matrix δ needs to be established. mn This completes the configuration of the standard user role system. Subsequent additions or changes to the standard user role system can be configured by maintaining the matrix table. For SaaS software, user permission management for different tenants becomes a matter of different mapping relationship matrices δ. mn Maintenance and upgrades are performed. Generally, user permission mapping operations can be delegated to tenant administrators for custom configuration. The system only needs to provide the definition of meta-roles and a list of related permissions, and does not support users to add, delete, modify, or query meta-role permissions.

[0052] S3.4: Add function method judgment based on business rules and associate it with several meta roles. If the judgment function method is effective, grant the corresponding meta role operation permissions.

[0053] Establish a function determination method based on business rules, and perform a dot product with the corresponding mapping matrix to achieve temporary authorization control.

[0054] For unconventional user permission controls such as temporary authorization control, including scenarios based on task, context, and temporal factors, the two-layer permission control method of this invention can also provide good support. For this type of temporary authorization control, factors such as task, context, and temporal can be considered as variables affecting meta-role permissions, and these can be integrated into the original mapping permission matrix δ. mn Based on this, add role correspondences related to these control factors. Simultaneously, when configuring the role system mapping table, add function-based determination methods for task, context, and temporal aspects; that is, the corresponding mapping matrix will evolve into: δ mn →Γ 任务 ·Γ 上下文 ·Γ 时态 ·δ mn When the determination function method takes effect, i.e., Γ 任务=Γ 上下文 =Γ 时态 =1, and the actual user role can be assigned the corresponding meta role to complete the corresponding temporary authorization.

[0055] It should be noted that the arrangement of the modules in a flow layout is only one embodiment of the present invention, and other arrangements may also be used, which are not limited in the present invention.

[0056] The embodiments of the present invention have the following technical effects:

[0057] First, this invention utilizes a two-layer role-based access control model. By establishing an intermediate meta-role layer and a mapping matrix between the meta-role layer and system permissions, as well as a mapping matrix between the meta-role layer and the tenant's actual user role system, it separates the strong coupling between user roles and system permissions in the original access control method and establishes a weakly coupled indirect mapping relationship. This indirect mapping relationship effectively solves the access control difficulties caused by factors such as the continuous improvement of system permissions with version upgrades, different tenants having different role systems, and even the dynamic changes in the role system of the same tenant. This allows tenants to complete customized access control simply by configuring the role mapping matrix.

[0058] Secondly, for SaaS software developers and operators, the system design and operation only need to target the meta-role system to meet the personalized needs of different tenants. This can greatly reduce the workload of relevant development and configuration personnel, and at the same time, it can better support temporary authorization control based on factors such as task, context, and temporality, breaking through the current bottleneck of SaaS software's inability to implement universal and complex permission management mechanisms.

[0059] Figure 3 This is a structural block diagram of a SaaS software access control device based on a two-layer role model, according to an embodiment of the present invention. The device includes:

[0060] The permission division module is used to divide the system permissions of the SaaS software into menu permissions, button permissions, list permissions, form permissions, and data permissions. The operation permissions under each of the above system permissions are numbered and sorted in turn to establish a system permission subdivision matrix.

[0061] The metarole module is used to create several metaroles based on business scenarios, each corresponding to a set of operation permissions, to establish a metarole system.

[0062] The User Roles module is used to create several user roles, each corresponding to a different meta-role, thus establishing a user role system.

[0063] The user role module includes:

[0064] The module is used to create several user roles and generate blank RASCI role correspondence matrices for each role.

[0065] The selection module is used to respond to tenant operations, select the corresponding meta-roles, and define the actual RASCI role correspondence matrix;

[0066] The mapping module is used to establish a mapping matrix between user roles and several meta-roles, thereby establishing a user role system.

[0067] The judgment module is used to add function methods for judgment based on business rules and associate them with several meta-roles. If the judgment function method is effective, the corresponding meta-role is granted the operation permission.

[0068] Figure 3 The functions of each module in the embodiments correspond to the contents of their respective method embodiments, and will not be repeated here.

[0069] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0070] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A SaaS software access control method based on a two-layer role model, characterized in that, Includes the following steps: S1: Divide the system permissions of SaaS software into menu permissions, button permissions, list permissions, form permissions, and data permissions. Number and sort the operation permissions under each of the above-mentioned system permissions in turn to establish a system permission subdivision matrix. S2: Based on business scenarios and functional implementation logic, several meta-roles are established. These meta-roles are created by combining corresponding menu permissions, button permissions, list permissions, form permissions, and data permissions, each corresponding to a set of operation permissions. The system establishes a mapping matrix between the meta-roles and the various operation permissions, thus establishing a meta-role layer. This establishes a meta-role system; S3: Establish several user roles, each corresponding to a specific meta-role, to build a user role system, including the following steps: S3.1: Establish several user roles and generate blank RASCI role correspondence matrices for each; S3.2: In response to tenant operations, select the corresponding meta-role and define the actual RASCI role correspondence matrix; S3.3: Establish a mapping matrix 2 between the user roles and several meta-roles, and establish the user role system, wherein the tenant establishes the user role system according to actual needs. y m The corresponding meta-role system is selected. Establish a two-layer role system mapping matrix This allows only the mapping matrix to be configured. Custom permission control can then be completed; S3.4: Add a function method for judgment based on business rules and associate it with several meta-roles. If the function method is determined to be effective, grant the corresponding meta-role the necessary operating permissions. The function method includes task variables, context variables, and temporal variables. Establish a function judgment method based on business rules and perform a dot product with the corresponding mapping matrix to achieve temporary authorization control. When configuring the role system mapping table, the corresponding mapping matrix will evolve into: When the determination function method takes effect, that is... The actual user role can then be assigned the corresponding meta-role, and the corresponding temporary authorization can be completed.

2. The access control method according to claim 1, characterized in that: In step S2, the operation permission set includes menu permission set, button permission set, list permission set, form permission set, and data permission set.

3. A SaaS software access control device based on a two-layer role model, characterized in that, The access control method described in any one of claims 1-2 includes: The permission division module is used to divide the system permissions of the SaaS software into menu permissions, button permissions, list permissions, form permissions, and data permissions, and to number and sort the operation permissions under the above-mentioned system permissions in turn to establish a system permission subdivision matrix. The meta-role module is used to establish several meta-roles based on business scenarios, and to select the corresponding set of operation permissions to establish a meta-role system. A user role module is used to establish several user roles, each corresponding to a specific meta-role, to create a user role system. The user role module includes: A module is established to create several user roles and generate blank RASCI role correspondence matrices for each role. The selection module is used to respond to tenant operations, select the corresponding meta role, and define the actual RASCI role correspondence matrix; The mapping module is used to establish a mapping matrix 2 between the user roles and several meta-roles, and to establish the user role system; The determination module is used to add function methods for determination based on business rules and associate them with several meta-roles. If the function method is determined to be effective, the corresponding meta-role is granted operation permissions.

Images