Role-based authority management method and device and storage medium

Abstract

The invention discloses a role-based authority management method and device and a storage medium, and the method comprises the steps: creating different roles for a target system resource, and generating role names corresponding to the different roles based on a preset naming format, the role names are composed of continuous character strings, and the continuous character strings correspond to the target system resource; the continuous character string carries identification information corresponding to the role; determining an association relationship between the tenant and a plurality of roles with different role names and an association relationship between the plurality of roles with different role names, and establishing and storing a list of role relationships; and constructing a relation tree of the roles according to the list of the role relations. By adopting the technical scheme provided by the invention, not only is the name of the role unique, but also the role is simple, easy to use and easy to memorize, the role can be conveniently circulated in a plurality of subsystems, and the process of constructing the role relation tree and managing the authority based on the role is simplified.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing platforms, and in particular to a method, device and storage medium based on role authority management. Background Art

[0002] With the development of Internet technology, cloud-based SaaS services have spread across various business scenarios. With the surge in business complexity, the use of the Role Based permission model has become a consensus among practitioners in the security field. In traditional single-tenant products, since all roles are in the same large organization, it is not difficult for organizational managers to name the role in a globally visible and unique way. For cloud product SaaS service providers, data between tenants is isolated, so in existing product models, the namespace of the role is generally identified by the attribute field when storing the role. This design concept meets the tenant's adaptability to cloud products, but also brings some inconveniences, because the combination of components and services in cloud products is complex and changeable. How to maintain consistent role naming rules and connect role data in multiple components is a difficult task for tenants.

[0003] Figure 1 A schematic diagram showing a role list of a multi-tenant data management platform in common technology.

[0004] like Figure 1 As shown in the figure, for example, in a Cloud SaaS service, there are three tenants, and the names of the roles defined in each tenant overlap. In traditional cloud vendors, the storage process of the role will carry attribute field identifiers, which contain tenant information for tenant isolation. If the region or service attributes are added, the storage process of the role will continue to expand the attribute fields.

[0005] In addition, according to Figure 1 The naming of the Role designed in the code will also result in only a simple user name when the Role is displayed, without the resource attributes associated with it. This will cause a disconnect between the user experience and product design when the Role is displayed across services.

[0006] Therefore, for cloud products, how to resolve the naming conflicts of Roles between different tenants and identify the source of each Role is a technical problem that needs to be solved urgently. Summary of the invention

[0007] In view of the above defects of the prior art and for the service scenarios of a multi-tenant data management platform, the present invention provides a method, device and storage medium based on role authority management.

[0008] To achieve the above object, the present invention provides a method for role-based permission management, which is applied to the server of a multi-tenant data management platform, and the method comprises:

[0009] Creating different roles for target system resources, and generating role names corresponding to different roles based on a preset naming format, wherein the role names are composed of a continuous string of characters carrying identification information corresponding to the roles;

[0010] Determine association relationships between a tenant and multiple roles with different role names, and between multiple roles with different role names, establish and store a list of role relationships; and construct a role relationship tree based on the list of role relationships;

[0011] By integrating the role relationship tree with the permission system, a role permission relationship tree is generated.

[0012] Furthermore, the identification information corresponding to the role and carried by the continuous character string is resource information bound to the role.

[0013] Furthermore, the step of creating different roles for the target system resources and generating role names corresponding to the different roles based on a preset naming format includes:

[0014] Each role is named according to the following naming format:

[0015] {ShortName}@{Resource},

[0016] Among them, {ShortName} represents the abbreviation of the role, @ is a separator, and {Resource} represents the resource identification information bound to the role.

[0017] Furthermore, in the naming format, {Resource} is a resource identifier in the system, and its presentation is named as follows:

[0018] {Token 1}>{Token 2}>{Token 3}…{Token n};

[0019] Among them, {Token x} is the identifier of a resource, x=1,...n, n is a positive integer, Token represents the field name, and the symbol '>' represents the symbol ".", which is used to indicate the resource dependency relationship on the left and right ends, wherein the left resource includes the right resource.

[0020] Furthermore, based on the presentation form of the resource identifier, the generation strategy of the resource identifier includes:

[0021] The symbol '>' is used as a resource identifier to connect multiple resources in the system, wherein the resource identifier is used to uniquely locate the resource path in the system.

[0022] Furthermore, during the creation and / or use of a role, the role name is displayed using a simplified format of {ShortName} according to the use scenario and the context of logical calculation.

[0023] Further, in response to receiving a character string input representing a role from a user of the tenant to which the client belongs, a complete role representation list associated with the character string in the completion system is recommended based on the {ShortName} portion.

[0024] Furthermore, the method further comprises:

[0025] A role relationship structured query language statement based on a restriction condition operator is constructed, wherein the restriction condition operator includes at least one or a combination of condition operators such as prefix matching, suffix matching, regular expression matching, and fuzzy search.

[0026] Furthermore, based on the complete representation of the roles, the role names of different roles are mutually referenced in multiple subsystems.

[0027] Furthermore, the method further comprises:

[0028] Based on the globally stored role data table, create a global role relationship tree;

[0029] The relationship tree of role permissions is generated by integrating the global role relationship tree with the permission system.

[0030] Furthermore, the method further comprises:

[0031] The service system receives a resource processing request sent by the tenant to the service system through the client software. When responding to the resource processing request, the service system queries the role information and permission information of the tenant through the tenant information carried in the resource processing request, thereby determining the tenant's permissions.

[0032] According to another aspect of the present invention, the present invention further provides a device based on role authority management, which is applied to a server of a multi-tenant data management platform, and the device comprises:

[0033] A role creation module, used to create a role name for a target system resource, and generate role names corresponding to different roles based on a preset naming format, wherein the role name is composed of a continuous string, and the continuous string carries identification information corresponding to the resource;

[0034] A tenant and role relationship building module, used to determine the association relationship between a tenant and multiple roles with different role names, and between multiple roles with different role names, establish and store a list of role relationships; and build a role relationship tree based on the list of role relationships;

[0035] The permission integration module is used to generate a relationship tree of role permissions by integrating the relationship tree of the role with the permission system.

[0036] Furthermore, the present invention also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, any of the above-mentioned role-based permission management methods is implemented.

[0037] The method, device and storage medium for role-based permission management provided in the present invention are intended to create different roles for target system resources and generate role names corresponding to different roles based on a preset naming format, so that tenants can play different roles according to rules and configurations, wherein the role name is composed of a continuous string, and the continuous string carries identification information corresponding to the role; determine the association between the tenant and multiple roles with different role names, and multiple roles with different role names, establish and store a list of role relationships; and construct a role relationship tree based on the list of role relationships. The technical solution provided by the present invention not only makes the role name unique, but also simple, easy to use and easy to remember, which facilitates the circulation of roles in multiple subsystems, but also simplifies the process of constructing a role relationship tree and role-based permission management.

[0038] Furthermore, based on the complete representation of the roles, the role names of different roles are mutually referenced in multiple subsystems, which can facilitate cross-system empowerment between different roles. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The technical solutions and other beneficial effects of the present invention will be made apparent by describing in detail the specific embodiments of the present invention in conjunction with the accompanying drawings.

[0040] Figure 1 A schematic diagram showing a role list in a multi-tenant scenario in common technologies.

[0041] Figure 2 The figure shows a schematic diagram of the architecture of permission management based on namespace permissions in common technologies.

[0042] Figure 3 A flow chart of a method for role-based authority management provided in an embodiment of the present application is shown.

[0043] Figure 4A schematic diagram of the architecture of role-based permission management provided by an embodiment of the present application is shown.

[0044] Figure 5 A schematic diagram of a role list in a multi-tenant scenario provided in an embodiment of the present application is shown.

[0045] Figure 6 A schematic diagram of a role list in a multi-tenant multi-service scenario provided by an embodiment of the present application is shown.

[0046] Fig. 7A A schematic diagram of a relationship tree of role permissions constructed according to an embodiment of the present application is shown.

[0047] Figure 7B A code example for querying a tenant role list provided in an embodiment of the present application is shown.

[0048] Figure 7C A code example for querying a list of roles that can be played provided by an embodiment of the present application is shown.

[0049] Fig.7D An example of determining whether a role can play another role provided by an embodiment of the present application is shown.

[0050] Fig. 7E An example of an SQL structured authorization statement provided in an embodiment of the present application is shown.

[0051] Figure 7F A code example of a database managing role scenarios in an SQL terminal provided by an embodiment of the present application is shown.

[0052] Figure 7G An example of authorization implementation in a tenant isolation scenario provided by an embodiment of the present application is shown.

[0053] Fig. 8A A schematic diagram showing a role center module provided in an embodiment of the present application and connections between the role center module and multiple components is shown.

[0054] Figure 8B An example of a role authorization statement in a tenant provided in an embodiment of the present application is shown.

[0055] Figure 8C The example code of the role search algorithm provided in the embodiment of the present application is shown.

[0056] Fig. 9 A schematic diagram of a global role relationship tree constructed in an embodiment of the present application is shown.

[0057] Fig.10 A structural block diagram of a device for role-based authority management provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0058] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0059] The terms "first", "second", "third", etc. (if any) in the specification and claims of the present invention and the drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the objects described in this way can be interchanged where appropriate. In the description of the present invention, the meaning of "multiple" is two or more, unless otherwise clearly and specifically defined. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. Some of the block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software form, or in one or more hardware circuits or integrated circuits, or in different networks and / or processor devices and / or micro-indicator devices.

[0060] In the description of the present invention, it should be noted that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection, an electrical connection, or mutual communication; it can be a direct connection, or an indirect connection through an intermediate medium, it can be the internal connection of two elements or the interaction relationship between two elements. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0061] In order to make the purpose, features and advantages of the present invention more obvious and easy to understand, the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments.

[0062] Figure 2 The figure shows a schematic diagram of the architecture of permission management based on namespace permissions in common technologies.

[0063] Create a tenant in the cloud platform, store the tenant information in the database, create multiple roles in the tenant, establish the association relationship between the tenant and the role, and obtain the corresponding association information through the tenant ID or role ID.

[0064] Table 1 is a configuration table of role ID, role and namespace under namespace-based management

[0065]

[0066] Table 2 is a table showing the relationship between role IDs under namespace-based management

[0067] Parent Member 1 2 2 3 2 4 2 5

[0068] The existing Name Space-based permission management method allocates a name space to each tenant, and all roles of each tenant are stored in his own name space, thus avoiding the naming conflicts and other problems mentioned above. At the same time, this namespace-based tenant management method can manage the information of each tenant separately, thereby further improving the degree of information isolation between tenants.

[0069] For example, as shown in Table 1, each role in a tenant can create multiple namespaces, record their associations when creating them, and bind the tenant to the namespace through the relationship between tenant->role->namespace. Namespace "assigns" objects within the system to different namespaces to form logically grouped projects, teams or user groups, so that different groups can be managed separately while sharing the resources of the entire cluster. The protocol stipulates that all actions authorized by roles within a tenant can only be performed within the same namespace.

[0070] As shown in Table 2, the parent-child relationship between multiple role IDs is stored. Only by using the joint query method of Table 1 and Table 2 can a Figure 2 The complete role tree (relationship tree) is shown.

[0071] For example, when building a role tree, if you want to query the role corresponding to the parent of role ID "2", you need to join these two tables together for query (i.e., joint query method). For example, first query in Table 2 that the parent of role ID "2" is role ID "1", and then query the detailed information corresponding to role ID "1" in the first table, that is, associate Table 1 with Table 2 through the role ID to build a complete role tree (relationship tree).

[0072] Figure 3 A flow chart of a method for role-based permission management provided in an embodiment of the present application is shown. The method is applied to a server of a multi-tenant data management platform.

[0073] refer to Figure 3 As shown, the method comprises the following steps:

[0074] Step S10, creating different roles for target system resources, and generating role names corresponding to different roles based on a preset naming format, wherein the role names are composed of a continuous string, and the continuous string carries resource identification information corresponding to the role;

[0075] Step S20, determining associations between the tenant and multiple roles with different role names, and between multiple roles with different role names, establishing and storing a list of role relationships; and constructing a role relationship tree based on the list of role relationships;

[0076] Step S30, generating a role-authority relationship tree by integrating the role-authority relationship tree with the authority system.

[0077] Steps S10 to S30 will be described in detail below.

[0078] In step S10, different roles are created for the target system resources, and role names corresponding to the different roles are generated based on a preset naming format, wherein the role name is composed of a continuous string carrying identification information corresponding to the role.

[0079] In the embodiment of the present application, there are generally multiple system resource objects on the cloud platform, but different roles are not created for each system resource object. Usually, critical system resources are selectively used as target system resources, and then different roles are created accordingly for each target system resource.

[0080] Create different roles for the target system resources on the cloud platform. Once you have a role, you only need to define permissions for the role. When tenants purchase the target system resources, they can play different roles based on rules and configurations to ultimately add tenants to the corresponding roles. Subsequently, you only need to modify the permissions of the role to automatically modify the permissions of all tenants within the role, so as to manage the application permissions of the database.

[0081] Regarding the problems encountered in the existing technology: In a cloud product, each tenant has to customize many role names. These role names may conflict, but if there is NameSpace attribute isolation between tenants, it doesn't matter if they conflict. However, when naming the role in different products (systems) under the same tenant, it is difficult to make the role names different between different products (systems). For example, an 'admin' role is defined in the human resources management system under the current tenant, and then an 'admin' role is defined in the resource management system under the current tenant. For these two 'admin' roles, their names are the same, both 'admin'; when it is necessary to connect the roles between multiple systems under the current tenant, for example, the 'admin' role in the human resources management system can be seen in the resource management system, then there will be a big problem in the display. How to display these two 'admin's and identify which system they are on or where they come from.

[0082] In view of the problems existing in the prior art, an object of the present invention is to enable the role name to be unique, simple, easy to use and easy to remember, thereby simplifying the process of building a role relationship tree and role-based permission management.

[0083] Exemplarily, based on a preset naming format, role names corresponding to different roles are generated, wherein the role names are composed of a continuous string, and the continuous string carries identification information corresponding to the role. Since a role template framework has been created for the target system resources on the cloud platform, when the tenant purchases the corresponding target system resources, role names corresponding to different roles will be generated for the target system resources, that is, the identification information corresponding to the role will be bound to its role name. For example, A purchased a server, and this server is bound to an 'admin' role, then A is about to play the 'admin' role, and the system will generate a continuous string corresponding to this 'admin' role based on the preset naming format, and the continuous string carries the identification information corresponding to the role, so that the 'admin' role has complete description information. In some embodiments, the identification information corresponding to the role carried by the continuous string is the resource information bound to the role. For example, system information and tenant information under the current tenant.

[0084] In some implementations, creating different roles for target system resources and generating role names corresponding to different roles based on a preset naming format include:

[0085] Each role is named according to the following naming format:

[0086] {ShortName}@{Resource},

[0087] Among them, {ShortName} represents the abbreviation of the role, @ is a separator, and {Resource} represents the resource identification information bound to the role.

[0088] Through the naming format of {RoleName}@{Resource}, since the Resource field is introduced in the role name, the Role naturally has the resource isolation attribute, and it is easier for tenants to understand the resource information bound to the Role. Even when the Role circulates between multiple service systems, there will be no naming conflict problem. Compared with the existing technology, the optimized Role does not need to carry its "namespace" attribute field when stored, thus replacing the original "namespace" as a means of resource isolation. And the improved role name: {RoleName}@domain naming format will not only represent a role, for example, representing the role of 'admin', but represents the complete expression information of a Role, where {Resource} after the @ separator is used to identify the object information to which the role belongs, and then circulates with the complete expression information of this Role.

[0089] Naming the role names corresponding to different roles of each tenant according to the above naming format is not only easy to remember but also easy to recognize.

[0090] Furthermore, in the naming format, {Resource} is a specific resource identifier in the system, and its presentation is named as follows:

[0091] {Token 1}>{Token 2}>{Token 3}……{Token n};

[0092] Among them, {Token x} is the identifier of a resource, x=1,...n, n is a positive integer, Token represents the field name, and the symbol '>' represents the symbol ".", which is used to indicate the resource dependency relationship on the left and right ends, wherein the left resource includes the right resource.

[0093] Based on the above-mentioned {Resource} resource identifier presentation format, in order to ensure that the resource identifier selected each time is independent (i.e., there will be no duplication), based on the resource identifier presentation format, the resource identifier generation strategy includes: using the symbol '>' as a resource identifier to connect multiple resources in the system, wherein the resource identifier is used to uniquely locate the resource path in the system.

[0094] In step S20, the association relationships between the tenant and multiple roles with different role names, and between multiple roles with different role names are determined, a list of role relationships is established and stored; and a role relationship tree is constructed based on the list of role relationships.

[0095] In order to implement tenant role-based access control, first, determine the association between the tenant and multiple roles with different role names, and determine the association between multiple roles with different role names, and then store the association between multiple roles with different role names in a list of role relationships. Since the naming format of Role already carries complete resource identification information, there is no need to join other tables to find the corresponding association, so that Role has a nested attribute, thereby constructing a role relationship tree based on the list of role relationships. That is, in the embodiment of the present application, the constructed role relationship tree has both the association between roles and tenants and the association between roles.

[0096] Table 3 is a list of role relationships in Example 1 of this application

[0097] Role Member admin@arp viewer@arp viewer@arp ops@arp

[0098] For example, as an improved solution of the embodiment of the present application, the association relationship between multiple roles with different role names is stored in Table 3. If you want to know the parent of the role viewer@arp, you can directly use this list of role relationships to query. Compared with the original query method of combining multiple tables, the query method becomes simpler.

[0099] Since each tenant has multiple roles with different role names and has its own object (resource) information, the attached Figure 4 The relationship tree of the roles shown.

[0100] In step S30, a role-authority relationship tree is generated by integrating the role-authority relationship tree with the authority system.

[0101] In the embodiment of the present application, regarding the integration of Role and the permission system, the permission theory has been widely accepted: in the role-based access control (RBAC) and attribute-based access control (ABAC) model systems, the reference to Role data is generally a unique ID. The Role format described in the embodiment of the present application carries the Resource field and is inherently unique. Therefore, the user only needs to ensure that the Role name is unique under the Resource.

[0102] The technical solution provided in the embodiment of the present application breaks the original concept of Name Space compared to the original Name Space-based management method. By creating different roles for target system resources and generating role names corresponding to different roles based on a preset naming format, tenants can play different roles according to rules and configurations, wherein the role name is composed of a continuous string, and the continuous string carries identification information corresponding to the role; determining the association relationship between the tenant and multiple roles with different role names, and multiple roles with different role names, establishing and storing a list of role relationships; and constructing a role relationship tree based on the list of role relationships; not only making the role name unique, but also simple, easy to use, easy to remember, and easy to circulate in multiple subsystems, but also simplifying the process of constructing a role relationship tree and role-based permission management.

[0103] Figure 5 A schematic diagram of a role list in a multi-tenant scenario provided in an embodiment of the present application is shown.

[0104] Regarding the resource source of multiple roles with different role names, in cloud products, Resource refers to a resource instance that can be uniquely identified and located. It generally contains the instance ID and resource type. For example, 1.tennant represents the tenant numbered 1. Apply the above pattern to the Role naming of the cloud product center, and get the names of each role in the role list (RoleList) as follows: Figure 5 As shown, there is no conflict between the role names in the role list between different tenants, and users can clearly understand the definition of each role in the role list, its source, and the bound resources.

[0105] Furthermore, the method also includes: during the creation and / or use of the role, the application can display the role name in a simplified format of {ShortName} according to the context of the use scenario and logical calculation.

[0106] Figure 6 A schematic diagram of a role list in a multi-tenant multi-service scenario provided by an embodiment of the present application is shown.

[0107] For example, Figure 6 As shown, the resource source of multiple roles with different role names can be the tenant ID or each service system under the current tenant. For example, 1.tennant represents the tenant numbered 1; 1.erp represents the erp service system numbered 1; the embodiments of this application are not repeated here.

[0108] Furthermore, the method also includes: in response to receiving a character string input representing a role from a client user, the system can recommend a complete list of character representation forms associated with the character in the system according to the {ShortName} portion.

[0109] For example, after the user enters the character string "admin", the system can recommend a relatively accurate and complete list of role expressions associated with it in the system based on the {admin} part for the user to choose from.

[0110] In addition, metadata storage about roles can be stored in a single-column table. In addition, since each role under the tenant and / or tenant service system has a simplified role name expression form, it has no other additional attribute fields, so when storing the nested relationship of roles, efficient KV storage (key-value storage) can be used.

[0111] Table 4 is a list of role relationships in Example 2 of this application

[0112] Role Member admin@1.tenant user1 viewer@1.tenant admin@1.tenant admin@1.tenant owner@1.tenant devops@1.tenant admin@1.tenant notifier@1.tenant admin@1.tenant owner@1.tenant user2 notifier@1.tenant user3 admin@1.Server admin@1.tenant admin@1.arp admin@1.tenant admin@1.Server user4 admin@1.Server user5 admin@1.hr user6

[0113] From the associations between different roles in Table 4, we can construct Fig. 7A The relationship tree of role permissions is shown.

[0114] For example, Fig. 7A The document describes a tenant ID of 1 and the relationship tree of all roles on a multi-tenant, multi-application cloud platform. Based on the complete representation of the roles, the role names of different roles can be referenced in multiple subsystems (APPs). Thus, users can maintain a relationship tree of multiple application roles isolated by tenant dimension in any application, satisfying the mutual authorization capability of multiple systems.

[0115] In some implementations, after a role relationship tree (search tree) is constructed, a combined query can be performed on the search tree. For example, the set of roles that can be played by the search user under the tenant to which the client belongs is: Figure 7B A code example of querying a tenant role list provided in an embodiment of the present application is shown, referring to Figure 7B As shown, querying the user role list is a recursive traversal algorithm toward the parent.

[0116] Then, search for all character collections that can play the character. Figure 7C A code example for querying a list of roles that can be played provided by an embodiment of the present application is shown.

[0117] For example, Figure 7C As shown, querying all roles that can play a role is a recursive traversal algorithm in the child direction.

[0118] Fig.7D An example of determining whether a role can play another role provided by an embodiment of the present application is shown.

[0119] In addition, if Fig.7D As shown, an algorithm can also be used to verify whether a role (Role) can play another role (Role).

[0120] It should be understood that since the above-constructed role relationship tree can fully describe all the information required for calculation, an efficient KV (key-value storage) database can be used for storage.

[0121] Exemplarily, the client's user role relationship structured query language statement (SQL) is determined based on the role list and the relationship tree of the role permissions under the current tenant. Fig. 7E The example of SQL structured authorization statement shown is used to grant permissions from Role OPS to Role viewer under the current tenant.

[0122] Figure 7F A code example of a database managing role scenarios in an SQL terminal provided by an embodiment of the present application is shown.

[0123] For database-based cloud providers, when users need to manage role scenarios in SQL terminals, they can use the following Figure 7F The SQL structured management statements shown.

[0124] For multi-tenant isolation scenarios, the tenant ID can be used as a component of the Resource field. In scenarios where isolation is required, this field can be used for verification. For example, when authorizing a role to be a member of another role, it is necessary to check whether the Tenant ID fields of the two roles are the same. Only when the Tenant ID fields of the two roles are the same can normal authorization be performed. Otherwise, the user's request will be rejected. For example, Figure 7G The following is an example of authorization implementation in a tenant isolation scenario.

[0125] That is, when adding calculation after Resource in multiple {RoleName}@{Resource}, the tenant IDs must be equal to ensure that they are from the same tenant, so as to achieve mutual reference within the tenant. In this way, there is no need to check whether the subsystem field is equal, which ensures that the role names of different roles under the same tenant can be referenced between multiple subsystems and realizes resource isolation between tenants.

[0126] In the embodiment of the present application, since the definition of each role name carries resource attributes, it is isolable. It is also possible to store the different role names containing all roles in the role center module (RoleCenter) in the form of a role data table, wherein the role center module communicates with each system component through an application interface and provides role-related services to each component based on the globally stored role data table. For example, the role center module uses a Restful API to provide role-related services to other components based on globally stored role data.

[0127] Fig. 8A A schematic diagram showing a role center module provided in an embodiment of the present application and connections between the role center module and multiple components is shown.

[0128] like Fig. 8A As shown in the figure, after the introduction of the Role Center module, all roles are named and defined according to the preset naming format and stored centrally, the roles defined in other sub-service systems can be seen in the sub-service system, making the relationship between roles globally visible and manageable. Since roles have the nestable attribute (a role can contain other roles), it also makes it possible for cloud product users to manage roles across services.

[0129] It should be understood that services based on the role center module can realize the circulation of Role data between multiple sub-service systems. For example, in the Notifier (notification system) service, a Role defined in other services can be queried or managed, and the nested attributes of the Role can be superimposed, so that a relationship tree about the Role can be easily created. Then, by integrating the role relationship tree with the permission system, a relationship tree of role permissions is generated, which can easily manage cross-service role management and user permission management functions.

[0130] In addition, according to the role list under the current tenant and the relationship tree of the role permissions, a role relationship structured query language statement based on the restriction operator is constructed, and the restriction operator includes: at least one or a combination of prefix matching, suffix matching, regular expression matching, and fuzzy search.

[0131] For example, Figure 8B The following is an example of a role authorization statement in a tenant. Figure 8C The role search algorithm example code shown.

[0132] For example, Fig. 9 As shown, users can maintain the global role relationship tree in any subsystem on the data management platform and manage permissions for other users or themselves.

[0133] In some implementations, the server receives a resource processing request sent by a tenant to a service system through a terminal, application interface or other client software. When responding to the resource processing request, the service system queries the role information and permission information of the tenant through the tenant information carried in the resource processing request, thereby determining the tenant's permissions.

[0134] According to another aspect of the present application, a device for role-based authority management is provided, which is applied to a server of a multi-tenant data management platform.

[0135] Fig.10 A structural block diagram of a device for role-based authority management provided in an embodiment of the present application is shown.

[0136] like Fig.10 As shown, the device 200 includes:

[0137] The role creation module 210 is used to create different roles for target system resources and generate role names corresponding to different roles based on a preset naming format, wherein the role name is composed of a continuous string carrying identification information corresponding to the user;

[0138] The tenant and role relationship building module 220 is used to determine the association relationship between the tenant and multiple roles with different role names, and between multiple roles with different role names, establish and store a list of role relationships; and build a role relationship tree based on the list of role relationships;

[0139] The permission integration module 230 is used to generate a role permission relationship tree by integrating the role relationship tree with the permission system.

[0140] It should be understood that other aspects and effects of the device can be found in the aforementioned method based on role authority management, which will not be described in detail here.

[0141] In another embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the method for role-based permission management applied to a server as described in any of the embodiments above is implemented.

[0142] The specific definition and implementation of the above steps can be found in the embodiment of the method based on role authority management, which will not be described in detail here.

[0143] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0144] The above is a detailed introduction to the method, device and storage medium based on role authority management provided in the embodiments of the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the technical scheme and core ideas of the present invention. Ordinary technical personnel in this field should understand that they can still modify the technical schemes recorded in the aforementioned embodiments, or replace some of the technical features therein with equivalents; and these modifications or replacements do not make the essence of the corresponding technical scheme deviate from the scope of the technical schemes of the embodiments of the present invention.

Claims

1. A method based on role authority management, applied to the server of a multi-tenant data management platform, characterized in that: The method comprises: Creating different roles for target system resources, and generating role names corresponding to different roles based on a preset naming format, wherein the role names are composed of a continuous string of characters carrying identification information corresponding to the roles; Determine association relationships between a tenant and multiple roles with different role names, and between multiple roles with different role names, establish and store a list of role relationships; and construct a role relationship tree based on the list of role relationships; By integrating the role relationship tree with the permission system, a role permission relationship tree is generated.

2. The method for role-based authority management according to claim 1, characterized in that: The identification information corresponding to the role and carried by the continuous character string is the resource information bound to the role.

3. The method for role-based authority management according to claim 1, characterized in that: The process of creating different roles for the target system resources and generating role names corresponding to different roles based on a preset naming format includes: Each role is named according to the following naming format: {ShortName}@{Resource}, Among them, {ShortName} represents the abbreviation of the role, @ is a separator, and {Resource} represents the resource identification information bound to the role.

4. The method for role-based authority management according to claim 3, characterized in that: In the naming format, {Resource} is the resource identifier in the system, and its presentation is named as follows: {Token 1}>{Token 2}>{Token 3}……{Token n}; Among them, {Token x} is the identifier of a resource, x=1,...n, n is a positive integer, Token represents the field name, and the symbol '>' represents the symbol ". ", which is used to indicate the resource dependency relationship at the left and right ends, wherein the left resource contains the right resource.

5. The method for role-based authority management according to claim 4, characterized in that: Based on the presentation form of the resource identifier, the generation strategy of the resource identifier includes: The symbol '>' is used as a resource identifier to connect multiple resources in the system, wherein the resource identifier is used to uniquely locate the resource path in the system.

6. The method for role-based authority management according to claim 3, characterized in that: The method further comprises: During the creation and / or use of a role, the role name is displayed in a simplified format of {ShortName} according to the usage scenario and the context of logical calculation.

7. The method for role-based authority management according to claim 3, characterized in that: The method further comprises: In response to receiving a character string input representing a role from a client user, a complete role representation list associated with the character string in the completion system is recommended according to the {ShortName} portion.

8. The method for role-based authority management according to claim 3, characterized in that: The method further comprises: A role relationship structured query language statement based on a restriction operator is constructed, wherein the restriction operator includes at least one or a combination of prefix matching, suffix matching, regular expression matching, and fuzzy search.

9. The method for role-based authority management according to claim 3, characterized in that: Based on the complete representation of the roles, the role names of different roles are referenced to each other in multiple subsystems.

10. The method for role-based authority management according to claim 1, characterized in that: The method further comprises: Based on the globally stored role data table, create a global role relationship tree; The relationship tree of role permissions is generated by integrating the global role relationship tree with the permission system.

11. The method for role-based authority management according to claim 10, characterized in that: The method further comprises: The service system receives a resource processing request sent by the tenant to the service system through the client software. When responding to the resource processing request, the service system queries the role information and permission information of the tenant through the tenant information carried in the resource processing request, thereby determining the tenant's permissions.

12. A device based on role authority management, applied to the server of a multi-tenant data management platform, characterized in that: The device comprises: A role creation module, used to create a role name for a target system resource, and generate role names corresponding to different roles based on a preset naming format, wherein the role name is composed of a continuous string carrying identification information corresponding to the resource; A tenant and role relationship building module, used to determine the association relationship between a tenant and multiple roles with different role names, and between multiple roles with different role names, establish and store a list of role relationships; and build a role relationship tree based on the list of role relationships; The permission integration module generates a relationship tree of role permissions by integrating the relationship tree of the role with the permission system.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method for role-based authority management according to any one of claims 1 to 11 is implemented.

Images