Subsystem permission configuration method and processing method, device, equipment and medium

Abstract

The invention provides a sub-system permission configuration method, a sub-system permission processing method, a sub-system permission processing device, equipment and a medium. Whether an external permission function exists between each sub-system and other sub-systems in a target platform or not is determined; the method comprises the following steps: for each subsystem with an external permission function, acquiring an authorization object of the subsystem and basic information of the authorization object, and obtaining authorization object information; wherein the authorization object comprises an internal authorization object of the subsystem and an external authorization object of the subsystem; and based on the authorization object information, respectively configuring permissions about the corresponding subsystems for users corresponding to the authorization objects. According to the method and the device, the authority isolation among the subsystems in the platform is realized by decoupling the authority management mode of the subsystems, the independence among the subsystems in the platform is effectively improved, and the safety and the flexibility of the subsystems are effectively improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a subsystem permission configuration method and processing method, device, equipment and medium. Background Art

[0002] With the development of science and technology, the number of integrated platform products has gradually increased. A platform product often contains multiple subsystems, and the subsystems in the platform usually operate together in a combined form.

[0003] At present, the permission management of subsystems in the platform usually relies on the permission control of the platform as a whole, that is, the user permissions of the platform are uniformly set, and authorized users can share all subsystems. Since subsystems usually have their own independent functions and users, if they rely on the permission control of the platform as a whole, it will lead to the loss of independence of subsystems, making it difficult for a single subsystem to run independently in the platform, and it is easy to cause problems such as confusion in user access to subsystems.

[0004] Therefore, it is particularly important to propose a permission isolation solution that can achieve subsystem permission decoupling. Summary of the invention

[0005] The present application provides a subsystem permission configuration method and processing method, device, equipment and medium to solve problems such as the lack of independence of subsystems in platform products.

[0006] According to a first aspect of the present application, a method for configuring permissions of a subsystem is provided, comprising:

[0007] Determine whether each subsystem in the target platform has external permission functions with other subsystems;

[0008] For each subsystem with an external authority function, obtain the authorization object of the subsystem and its basic information to obtain the authorization object information; wherein the authorization object includes the internal authorization object of the subsystem and the external authorization object of the subsystem;

[0009] Based on the authorization object information, permissions on corresponding subsystems are respectively configured for users corresponding to the authorization objects.

[0010] In one implementation, the step of respectively determining whether each subsystem in the target platform has an external authority function with other subsystems includes:

[0011] Obtain the permission start flag and / or permission close flag of each subsystem regarding the external permission function between other subsystems;

[0012] Based on the permission start identifier and / or the permission close identifier, it is determined whether each subsystem in the target platform has an external permission function with other subsystems.

[0013] In one embodiment, when the authorization object is an internal authorization object of the subsystem, the basic information includes a role ID of the internal authorization object;

[0014] and / or,

[0015] When the authorization object is an external authorization object of the subsystem, the basic information includes the subsystem to which the external authorization object belongs, the role ID and the verification address;

[0016] The basic information is used to verify the permission request according to the basic information when the user initiates a permission request for the corresponding subsystem.

[0017] According to a second aspect of the present application, a method for handling permissions of a subsystem is provided, including:

[0018] In response to a user's permission request for any subsystem in the target platform, obtaining authorization object information of the requested subsystem; wherein the authorization object information includes an authorization object and its basic information, and the authorization object includes an internal authorization object of the requested subsystem and an external authorization object of the requested subsystem;

[0019] Based on the authorization object information, it is verified whether the user is the user corresponding to the authorization object of the requested subsystem. If so, it is determined that the user has the authority of the requested subsystem, and the user is authorized to operate the requested subsystem with the corresponding authority.

[0020] In one implementation, before obtaining the authorization object information of the requested subsystem, the method further includes:

[0021] Identifying the subsystem to which the user currently belongs;

[0022] The verifying, based on the authorization object information, whether the user is a user corresponding to the authorization object of the requested subsystem includes:

[0023] When the subsystem to which the user currently belongs is consistent with the requested subsystem, verifying whether the user is a user corresponding to the internal authorization object of the requested subsystem based on the authorization object information; or,

[0024] When the subsystem to which the user currently belongs is inconsistent with the requested subsystem, it is verified based on the authorization object information whether the user is a user corresponding to the external authorization object of the requested subsystem.

[0025] In one embodiment, when the authorization object of the requested subsystem is an internal authorization object, the basic information includes a role ID of the internal authorization object;

[0026] The verifying whether the user is a user corresponding to the internal authorization object of the requested subsystem based on the authorization object information includes: matching the role ID of the user with the role ID of the internal authorization object, and if the match is successful, determining that the user is the internal authorization object of the requested subsystem;

[0027] or,

[0028] When the authorization object of the requested subsystem is an external authorization object, the basic information includes the subsystem to which the external authorization object belongs, the role ID and the verification address;

[0029] The verifying, based on the authorization object information, whether the user is a user corresponding to the external authorization object of the requested subsystem includes:

[0030] Sending the role ID of the user to the subsystem to which the external authorization object belongs based on the verification address;

[0031] In the subsystem to which the external authorization object belongs, the role ID of the user is matched with the role ID of the external authorization object. If the match is successful, it is determined that the user is the external authorization object of the requested subsystem.

[0032] According to a third aspect of the present application, a subsystem permission configuration device is provided, including:

[0033] A function determination module, which is configured to respectively determine whether each subsystem in the target platform has an external authority function with other subsystems;

[0034] A first acquisition module is configured to acquire the authorization object and basic information of each subsystem with an external authority function, and obtain authorization object information; wherein the authorization object includes an internal authorization object of the subsystem and an external authorization object of the subsystem;

[0035] The permission configuration module is configured to configure the permissions of the corresponding subsystem for the corresponding user of the authorization object based on the authorization object information.

[0036] According to a fourth aspect of the present application, a subsystem permission processing device is provided, including:

[0037] A second acquisition module, which is configured to respond to a user's permission request for any subsystem in the target platform and acquire authorization object information of the requested subsystem; wherein the authorization object information includes an authorization object and its basic information, and the authorization object includes an internal authorization object of the requested subsystem and an external authorization object of the requested subsystem;

[0038] A verification module is configured to verify whether the user is the user corresponding to the authorization object of the requested subsystem based on the authorization object information. If so, it is determined that the user has the authority of the requested subsystem and the user is authorized to operate the requested subsystem with the corresponding authority.

[0039] According to a fifth aspect of the present application, there is provided an electronic device, comprising: a memory and a processor;

[0040] The memory stores computer-executable instructions;

[0041] The processor executes the computer-executable instructions stored in the memory, so that the electronic device executes the subsystem permission configuration method or the subsystem permission processing method.

[0042] According to the sixth aspect of the present application, a computer-readable storage medium is provided, in which computer-readable storage medium is stored computer execution instructions, and when the computer execution instructions are executed by a processor, they are used to implement the permission configuration method of the subsystem, or the permission processing method of the subsystem.

[0043] The subsystem permission configuration method and processing method, device, equipment and medium provided by the present application respectively determine whether each subsystem in the target platform has an external permission function with other subsystems, and for each subsystem with an external permission function, obtain the authorization object of the subsystem and its basic information, obtain the authorization object information, the authorization object includes the internal authorization object of the subsystem and the external authorization object of the subsystem, and configure the corresponding subsystem permissions for the corresponding user of the authorization object based on the authorization object information. In this process, by decoupling the permission management method of the subsystem, the permission isolation between the subsystems in the platform is realized, the independence between the subsystems in the platform is effectively improved, and the security and flexibility of the subsystem are effectively improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0045] Figure 1 A flowchart of a method for configuring permissions of a subsystem provided in an embodiment of the present application;

[0046] Figure 2 for Figure 1 Schematic diagram of the process of step S101;

[0047] Figure 3 A flowchart of a method for handling permissions of a subsystem provided in an embodiment of the present application;

[0048] Figure 4 An exemplary framework diagram provided for an embodiment of the present application;

[0049] Figure 5 A schematic diagram of the structure of a subsystem permission configuration device provided in an embodiment of the present application;

[0050] Figure 6 A schematic diagram of the structure of a permission processing device of a subsystem provided in an embodiment of the present application;

[0051] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0052] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0053] In an integrated platform product, such as the currently popular DevOps platform, a task is usually completed by multiple groups such as product, development, testing, and operation and maintenance. Each group promotes the workflow through independent internal work content and collaborative work content. The corresponding platform usually contains multiple subsystems such as product, development, and testing. Under normal circumstances, these subsystems are integrated into a work platform through the upstream and downstream relationships of the workflow. If the customer only needs some subsystems, they need to be deployed independently. Therefore, the independence of the subsystems of platform products has also become an issue of increasing concern in the industry. In order to improve the independence of subsystems, subsystems need to distinguish between internal users and other subsystem users (i.e., external users) and configure permissions differently.

[0054] Related technologies have also proposed a variety of permission management solutions. One is the role-based access control (RBAC) model, but the RBAC model is mainly used for single applications and can grant user functional permissions based on roles. Another is a permission isolation method based on structured query language (SQL) interception, which can integrate the permissions of multiple microservices. However, both of the above solutions cannot distinguish and process users inside and outside the subsystem of the platform, which will not achieve the purpose of differentiating permission configurations between subsystem users.

[0055] In view of this, the embodiment of the present application provides a subsystem permission configuration method and processing method, device, equipment and medium for the multi-subsystem characteristics of the platform, by respectively determining whether each subsystem in the target platform has an external permission function with other subsystems, for each subsystem with an external permission function, obtaining the authorization object of the subsystem and its basic information, obtaining the authorization object information, the authorization object includes the internal authorization object of the subsystem and the external authorization object of the subsystem, and based on the authorization object information, respectively configuring the permissions of the corresponding subsystem for the corresponding user of the authorization object. In this process, by determining the external permission function of the subsystem, the independent operation and combined operation modes of the subsystem in the platform are realized, and the independence of the subsystem is realized, and by distinguishing the permission configuration methods of the internal authorization object and the external authorization object, the permission isolation between the subsystems in the platform is realized, and the permission management of the subsystem is decoupled, which further enhances the independence of the subsystem and effectively improves the security and flexibility of the subsystem.

[0056] In order to make the purpose, technical solutions and advantages of the present application clearer, the technical solutions in the embodiments of the present application will be described in more detail below in conjunction with the drawings in the embodiments of the present application. In the drawings, the same or similar reference numerals throughout represent the same or similar parts or parts with the same or similar functions. The described embodiments are part of the embodiments of the present application, not all of the embodiments. The embodiments described below with reference to the drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limitations on the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0057] In a possible application scenario, a terminal device and a server are included, and the terminal device and the server are connected to each other via a wired or wireless network. Optionally, the user can use the terminal device to initiate a subsystem permission isolation instruction to the server, and the server configures the permissions of the subsystems in the platform separately according to the permission isolation instruction; optionally, the permission isolation instruction can also carry an opening or closing instruction of the external permission access function of each subsystem in the platform, and the server determines whether each subsystem has the external permission access function according to the opening or closing instruction; optionally, the terminal device can also be used to provide the server with authorization object information (authorization object and basic information) for configuring permissions, and the server is used to configure permissions for each subsystem based on the data provided by the terminal device. Optionally, in the process of permission configuration, the server undertakes the main computing work and the terminal device undertakes the secondary computing work; or, the server undertakes the secondary computing work and the terminal device undertakes the main computing work; or, the server or the terminal device can undertake the computing work separately.

[0058] Among them, the terminal devices may include but are not limited to computers, smart phones, tablet computers, e-book readers, Moving Picture experts group audio layer III (MP3) players, Moving Picture experts group audiolayer IV (MP4) players, portable computers, car computers, wearable devices, desktop computers, set-top boxes, smart TVs, etc.

[0059] The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), as well as big data and artificial intelligence platforms.

[0060] Optionally, the number of the above terminal devices or servers can be more or less, and the embodiments of the present application do not limit this. In some embodiments, the above terminal devices and servers can also serve as nodes in the blockchain system to synchronize the permission configuration information to other nodes of the blockchain to achieve subsequent tracing of the permission configuration information.

[0061] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0062] The above briefly describes the application scenarios of the present application. The following takes the application to a server as an example to describe in detail the permission configuration method of the subsystem provided in the embodiment of the present application.

[0063] Please refer to Figure 1 , Figure 1 A schematic flow chart of a method for configuring permissions of a subsystem is provided for an embodiment of the present application. The method includes steps S101-S103.

[0064] Step S101: Determine whether each subsystem in the target platform has an external authority function with other subsystems.

[0065] In this embodiment, the external permission function refers to the function of the subsystem accessing other subsystems in the platform. If the subsystem has the external permission function, other subsystems can access the subsystem. Correspondingly, if the subsystem does not have the external permission function, other subsystems cannot access the subsystem. In this case, the subsystem can run independently in the platform, which is equivalent to the independent deployment state of the subsystem.

[0066] In the related art, since the subsystems cooperate with each other and the permissions in each subsystem are uniformly configured by the platform, users in the platform can control the access between the subsystems. Based on the unified control of the platform, the independence of the subsystems is lost, and the management complexity and error risk of the platform permissions are increased. This embodiment adds a permission configuration method for the subsystem. First, the external permission function of each subsystem is determined. The determination method of the external permission function can be determined independently by the server or according to the instructions received from the terminal device. When the subsystem needs to be run independently, it will not cause problems such as confusion in access control of other systems, which effectively improves the independence and flexibility of the subsystem.

[0067] In one implementation, in order to further improve the flexibility of the independent operation of the subsystem, the administrator can enable and disable the external permission function of the subsystem by assigning corresponding permission identifiers to it. Figure 2 As shown, in step S101, determining whether each subsystem in the target platform has an external authority function with other subsystems may include the following steps S101a and S101b.

[0068] Step S101a, obtaining the permission start mark and / or permission stop mark of each subsystem regarding the external permission function between other subsystems;

[0069] Step S101b: Based on the permission start flag and / or the permission close flag, determine whether each subsystem in the target platform has an external permission function with other subsystems.

[0070] The external authority may be an external access authority or an external control authority, or other authority, which is not specifically limited in this embodiment.

[0071] In this embodiment, the permission start flag and the permission close flag are equivalent to the external switch of the subsystem's permission. The administrator (who may be the administrator of the subsystem) can set whether the permission is open to the outside to control the access ability or control ability of external users. In one implementation, if there are multiple permissions in the subsystem, such as access permission and control permission, the function of whether each permission is open to the outside can be set separately.

[0072] In this embodiment, the permission start-up identifier and permission close-up identifier assigned by the administrator to each subsystem regarding the external permission function with other subsystems can be set before the platform leaves the factory according to the actual application of the platform, or can be assigned in real time according to actual needs during the operation of the platform. This embodiment does not specifically limit the allocation method of the permission start-up identifier and the permission close-up identifier.

[0073] In some embodiments, the server can also determine whether each subsystem in the target platform has external permission functions with other subsystems through other means. For example, the administrator can send an external access permission opening instruction or an external access permission closing instruction to the server through a terminal device, and the server then determines the external permission function of the subsystem according to the corresponding instruction.

[0074] Step S102: for each subsystem with an external authority function, obtain the authorization object of the subsystem and its basic information to obtain the authorization object information; wherein the authorization object includes the internal authorization object of the subsystem and the external authorization object of the subsystem.

[0075] In this embodiment, the authorization object in this embodiment is an abstract concept, which represents an object to which authority can be granted. The object can be a user or role to be authorized, or a group of users or roles to be authorized.

[0076] In the related art, when performing permission configuration or permission request, it is impossible to distinguish between internal users and external users in the platform. This embodiment distinguishes the authorization objects into internal authorization objects and external authorization objects in the permission configuration stage to facilitate flexible configuration of permissions. When the corresponding permission request is received, different permission verification processes are performed according to the internal authorized users and external authorized users of the subsystem, thereby realizing flexible control of the permissions of internal and external users.

[0077] In some embodiments, permissions may include multiple permissions, such as separation of access permissions and control permissions. For different permissions, the authorization object and basic information corresponding to the subsystem can be obtained respectively, so as to realize flexible configuration of multiple permissions in the subsystem.

[0078] In this embodiment, the basic information is used to verify the permission request (eg, access request) according to the basic information when the user initiates a permission request (eg, access request) for the corresponding subsystem.

[0079] In one implementation, to improve the flexibility of permission verification, the basic information carries different information according to different authorization objects. In one example, when the authorization object is an internal authorization object of the subsystem, the basic information includes the role ID of the internal authorization object.

[0080] It can be understood that the role can be a user's role in a subsystem, such as a production role, an audit role, etc., and can include an authorized role and an unauthorized role. Each user has a unique role ID in the subsystem that distinguishes it from other roles in the subsystem.

[0081] When a user requests to access a subsystem, the user is an internal user of the subsystem being accessed. By matching the role ID of the internal authorization object with the role ID of the user, it can be determined whether the user is the user corresponding to the authorization object of the subsystem.

[0082] In another example, when the authorization object is an external authorization object of the subsystem, the basic information includes the subsystem to which the external authorization object belongs, a role ID, and a verification address.

[0083] When a user requests to access a subsystem, compared with the permission verification of internal users, the role ID information can be directly obtained from the subsystem. Since the subsystem may contain the access rights of multiple external users, if the verification is performed by directly querying the role ID, on the one hand, for the case where there are a large number of subsystems or a large number of roles, it is necessary to query the role ID in each subsystem (including the external subsystem with authorized users and the external subsystem without authorized users) in turn, resulting in very low efficiency of role ID query, thereby affecting the efficiency of permission verification; on the other hand, the role IDs in different subsystems may be the same or similar, resulting in confusion in the permission verification process, resulting in the query of the role ID in the wrong external subsystem, affecting the accuracy of permission verification. In this embodiment, for an external authorization object, its basic information carries the subsystem to which the external authorization object belongs and the verification address in addition to the role ID. The verification address can be used to send the role ID of the requesting user to the corresponding external subsystem, and the role ID verification is performed in the corresponding external subsystem. On the one hand, it solves the problem of low efficiency caused by traversing each external subsystem to query the role ID, and at the same time avoids the problem of confusion in the verification process when the role IDs in the external subsystems are the same or similar, thereby improving the accuracy of verification. In addition, the use of the verification address can effectively improve the security of calling the external subsystem information.

[0084] In other examples, the authorization object may include both an internal authorization object and an external authorization object. The verification methods for the internal authorization object and the external authorization object may be performed separately, which will not be described in detail here.

[0085] In some embodiments, for a subsystem that does not have an external permission function, that is, except for the internal users of the subsystem, users of other subsystems cannot access the subsystem. In a state with an external permission function, the subsystem can achieve effective independent operation and will not cause access confusion due to visits from external users.

[0086] Step S103: Based on the authorization object information, respectively configure the permissions of the corresponding subsystems for the corresponding users of the authorization objects.

[0087] Specifically, corresponding permission configurations may be performed for internal authorization objects and external authorization objects, respectively. It can be understood that an authorization object corresponds to a user, that is, an entity object corresponding to an abstract concept, and one authorization object may correspond to one or more users.

[0088] Compared with the related art, the subsystem relies on the user authority management of the platform, resulting in the lack of independence of the subsystem. A single subsystem cannot run independently in the platform, and it is easy to cause confusion in user access to the subsystem. This embodiment determines the external authority function of the subsystem to achieve independent operation and combined operation of the subsystem in the platform, thereby achieving the independence of the subsystem, and by distinguishing the authority configuration methods of internal authorization objects and external authorization objects, it achieves the authority isolation between subsystems in the platform, decouples the authority management of the subsystem, further enhances the independence of the subsystem, and effectively improves the security and flexibility of the subsystem.

[0089] Based on the same technical concept, the embodiment of the present application also provides a subsystem permission processing method, which can be applied to the target platform, such as Figure 3 As shown, Figure 3 It is a flowchart of the permission processing method of the subsystem, including step S301 and step S302.

[0090] Step S301, in response to a user's permission request for any subsystem in the target platform, obtain the authorization object information of the requested subsystem; wherein the authorization object information includes the authorization object and its basic information, and the authorization object includes the internal authorization object of the requested subsystem and the external authorization object of the requested subsystem.

[0091] The user is a user in the target platform, and may be a user in any subsystem in the target platform. The permission request may be an access request, a control request, or other permission requests.

[0092] Step S302: verify whether the user is the user corresponding to the authorization object of the requested subsystem based on the authorization object information; if so, determine that the user has the authority of the requested subsystem, and authorize the user to operate the requested subsystem with the corresponding authority.

[0093] Optionally, if there are multiple different permissions, it is necessary to verify the specific permission requested by the user. For example, if the user requests access rights, it is necessary to verify whether the authorization object corresponding to the access rights corresponds to the user.

[0094] In one implementation, before obtaining the authorization object information of the requested subsystem in step S301, the method further includes:

[0095] Identify the subsystem to which the user currently belongs.

[0096] In one possible implementation, the permission request may carry the name of the system to which the user belongs, and the subsystem to which the user currently belongs may be identified based on the system name.

[0097] In step S302, verifying whether the user is a user corresponding to the authorization object of the requested subsystem based on the authorization object information may include the following steps:

[0098] When the subsystem to which the user currently belongs is consistent with the requested subsystem, verifying whether the user is a user corresponding to the internal authorization object of the requested subsystem based on the authorization object information; or,

[0099] When the subsystem to which the user currently belongs is inconsistent with the requested subsystem, it is verified based on the authorization object information whether the user is a user corresponding to the external authorization object of the requested subsystem.

[0100] In one embodiment, when the authorization object of the requested subsystem is an internal authorization object, the basic information includes a role ID of the internal authorization object;

[0101] The verifying whether the user is a user corresponding to the internal authorization object of the requested subsystem based on the authorization object information includes: matching the role ID of the user with the role ID of the internal authorization object, and if the match is successful, determining that the user is the internal authorization object of the requested subsystem;

[0102] or,

[0103] When the authorization object of the requested subsystem is an external authorization object, the basic information includes the subsystem to which the external authorization object belongs, the role ID and the verification address;

[0104] The verifying, based on the authorization object information, whether the user is a user corresponding to the external authorization object of the requested subsystem includes:

[0105] Sending the role ID of the user to the subsystem to which the external authorization object belongs based on the verification address;

[0106] In the subsystem to which the external authorization object belongs, the role ID of the user is matched with the role ID of the external authorization object. If the match is successful, it is determined that the user is the external authorization object of the requested subsystem.

[0107] In one implementation, to improve the flexibility of permission verification, the basic information carries different information according to different authorization objects. In one example, when the authorization object is an internal authorization object of the subsystem, the basic information includes the role ID of the internal authorization object.

[0108] It can be understood that the role can be a user's role in a subsystem, such as a production role, an audit role, etc., and can include an authorized role and an unauthorized role. Each user has a unique role ID in the subsystem that distinguishes it from other roles in the subsystem.

[0109] When a user requests to access a subsystem, the user is an internal user of the subsystem being accessed. By matching the role ID of the internal authorization object with the role ID of the user, it can be determined whether the user is the user corresponding to the authorization object of the subsystem.

[0110] In another example, when the authorization object is an external authorization object of the subsystem, the basic information includes the subsystem to which the external authorization object belongs, a role ID, and a verification address.

[0111] When a user requests to access a subsystem, compared with the permission verification of internal users, the role ID information can be directly obtained from the subsystem. Since the subsystem may contain the access rights of multiple external users, if the verification is performed by directly querying the role ID, on the one hand, for the case where there are a large number of subsystems or a large number of roles, it is necessary to query the role ID in each subsystem in turn, resulting in very low efficiency of role ID query, which in turn affects the efficiency of permission verification; on the other hand, the role IDs in different subsystems may be the same or similar, resulting in confusion in the permission verification process, resulting in the query of the role ID in the wrong external subsystem, affecting the accuracy of permission verification. In this embodiment, for an external authorization object, its basic information carries the subsystem to which the external authorization object belongs and the verification address in addition to the role ID. The verification address can be used to send a role ID retrieval request to the subsystem to which it belongs. On the one hand, it solves the problem of low efficiency caused by traversing each external subsystem to query the role ID, while avoiding the problem of confusion in the verification process when the role IDs in the external subsystems are the same or similar, thereby improving the accuracy of verification. In addition, the use of the verification address can effectively improve the security of calling external subsystem information.

[0112] In other examples, if there are multiple users (for example, belonging to different subsystems) making permission requests at the same time, the verification methods for the internal authorization object and the external authorization object can be performed separately, which will not be elaborated here.

[0113] To facilitate understanding of the embodiments of the present application, a possible exemplary framework is further described, such as Figure 4As shown in the figure, the user is the user in the target platform. Users can establish a relationship with the authorization object through the system and role they belong to; the authorization object can be divided into internal authorization objects and external authorization objects, where the basic information of the external authorization object includes the subsystem to which it belongs, the role ID, and the external object verification address. The "subsystem to which it belongs" can be used as the system code to which the user belongs. By comparing it with the current subsystem, it can be determined whether the authorization object is used for external users. The external object verification address can be the API interface address used to verify the role information or identity information of the external user. If the authorization object belongs to an external authorization object, the "external object verification address" cannot be empty; permissions: include whether the attribute is open to the outside world. The administrator controls the access rights of external users by setting this attribute. Permissions establish a many-to-many relationship with authorization objects.

[0114] Users can initiate permission requests for the current subsystem (the subsystem to which the user belongs) or external subsystems. Taking access requests as an example, when a user initiates an access request to an external subsystem, the server sends the user's role ID to the (external) subsystem to which the external authorization object belongs according to the verification address corresponding to the external authorization object, and matches the role ID in the external subsystem. When the match is successful, it means that the user is the user corresponding to the external authorization object; when the user initiates an access request to the current subsystem, it only needs to directly query the role ID corresponding to the internal authorization object and match it.

[0115] In one implementation, internal and external authorization objects can be judged and verified: traverse all authorization objects owned by the user, compare the identifiers of the subsystem to which they belong and the current subsystem (for example, the subsystem name). If the identifiers are the same, the authorization object is an internal authorization object; if they are different, it is an external authorization object. If it is an authorization object of an internal user, the authorization object can be directly recorded as available. If it is an external authorization object, call the interface pointed to by the "external object verification address" of the authorization object, take the role ID as a parameter, and use the return value of the interface to verify the user identity. If the verification passes, the authorization object is recorded as available, otherwise it is discarded. Obtain permissions: traverse available authorization objects and obtain permissions. If it is an internal authorization object, all associated permissions are recorded as available. If it is an external authorization object, filter the permission list according to the "whether it is open to the outside world" attribute of the permission, and discard permissions with this attribute set to closed.

[0116] The present application also provides a subsystem permission configuration device. Figure 5 As shown, including:

[0117] A function determination module 51, which is configured to respectively determine whether each subsystem in the target platform has an external authority function with other subsystems;

[0118] A first acquisition module 52 is configured to acquire the authorization object and basic information of each subsystem with an external authority function, and obtain authorization object information; wherein the authorization object includes an internal authorization object of the subsystem and an external authorization object of the subsystem;

[0119] The authority configuration module 53 is configured to configure the authority of the corresponding subsystem for the corresponding user of the authorization object based on the authorization object information.

[0120] In one implementation, the function determination module 51 includes:

[0121] An identification acquisition unit, which is configured to acquire a permission start identification and / or a permission close identification of each subsystem regarding an external permission function between other subsystems;

[0122] A determination unit is configured to determine whether each subsystem in the target platform has an external permission function with other subsystems based on the permission start identifier and / or the permission close identifier.

[0123] In one embodiment, when the authorization object is an internal authorization object of the subsystem, the basic information includes a role ID of the internal authorization object;

[0124] and / or,

[0125] When the authorization object is an external authorization object of the subsystem, the basic information includes the subsystem to which the external authorization object belongs, the role ID and the verification address;

[0126] The basic information is used to verify the permission request according to the basic information when the user initiates a permission request for the corresponding subsystem.

[0127] It should be noted here that the above-mentioned device provided in the present application can correspondingly implement all the method steps implemented in the above-mentioned corresponding method (subsystem permission configuration method) embodiment, and can achieve the same technical effect. The parts and beneficial effects that are the same as the method embodiment in this embodiment will not be described in detail here.

[0128] The present application also provides a corresponding permission processing device for a subsystem. Figure 6 As shown, including:

[0129] A second acquisition module 61 is configured to, in response to a user's permission request for any subsystem in the target platform, acquire authorization object information of the requested subsystem; wherein the authorization object information includes an authorization object and its basic information, and the authorization object includes an internal authorization object of the requested subsystem and an external authorization object of the requested subsystem;

[0130] The verification module 62 is configured to verify whether the user is the user corresponding to the authorization object of the requested subsystem based on the authorization object information. If so, it is determined that the user has the authority of the requested subsystem and the user is authorized to operate the requested subsystem with the corresponding authority.

[0131] In one embodiment, the device further comprises:

[0132] an identification module, configured to identify the subsystem to which the user currently belongs;

[0133] The verification module 62 includes:

[0134] A first verification unit is configured to verify whether the user is a user corresponding to an internal authorization object of the requested subsystem based on the authorization object information when the subsystem to which the user currently belongs is consistent with the requested subsystem; or

[0135] The second verification unit is configured to verify whether the user is a user corresponding to an external authorization object of the requested subsystem based on the authorization object information when the subsystem to which the user currently belongs is inconsistent with the requested subsystem.

[0136] In one embodiment, when the authorization object of the requested subsystem is an internal authorization object, the basic information includes a role ID of the internal authorization object;

[0137] The first verification unit is specifically configured to match the role ID of the user with the role ID of the internal authorization object, and if the match succeeds, determine that the user is the internal authorization object of the requested subsystem;

[0138] or,

[0139] When the authorization object of the requested subsystem is an external authorization object, the basic information includes the subsystem to which the external authorization object belongs, the role ID and the verification address;

[0140] The second verification unit is specifically configured to send the role ID of the user to the subsystem to which the external authorization object belongs based on the verification address; in the subsystem to which the external authorization object belongs, the role ID of the user is matched with the role ID of the external authorization object, and if the match is successful, it is determined that the user is the external authorization object of the requested subsystem.

[0141] It should be noted here that the above-mentioned device provided in the present application can correspondingly implement all the method steps implemented by the above-mentioned corresponding method (subsystem permission processing method) embodiment, and can achieve the same technical effect. The parts and beneficial effects that are the same as the method embodiment in this embodiment will not be described in detail here.

[0142] The present application also provides an electronic device, such as Figure 7 As shown, it includes: a memory 71 and a processor 72;

[0143] The memory 71 stores computer-executable instructions;

[0144] The processor 72 executes the computer-executable instructions stored in the memory 71, so that the electronic device executes the subsystem permission configuration method or the subsystem permission processing method.

[0145] It should be noted here that the above-mentioned electronic device provided in the present application can correspondingly implement all the method steps implemented by the above-mentioned corresponding method embodiments, and can achieve the same technical effects. The parts and beneficial effects of this embodiment that are the same as the method embodiment will not be described in detail here.

[0146] The embodiment of the present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the subsystem permission configuration method or the subsystem permission processing method.

[0147] It should be noted here that the above-mentioned storage medium provided in the present application can correspondingly implement all the method steps implemented by the above-mentioned corresponding method embodiments, and can achieve the same technical effects. The parts and beneficial effects of this embodiment that are the same as the method embodiment will not be described in detail here.

[0148] It will be appreciated by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In a hardware implementation, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or may be implemented as hardware, or may be implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or a non-transitory medium) and a communication medium (or a temporary medium).

[0149] As is well known to those skilled in the art, the term computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer.

[0150] Furthermore, it is well known to those skilled in the art that communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0151] In the description of the embodiments of the present application, the term "and / or" merely represents an association relationship that describes associated objects, indicating that three relationships may exist. For example, A and / or B may represent three situations: A exists alone, A and B exist at the same time, and B exists alone. In addition, the term "at least one" represents any combination of at least two of any one or more of a plurality of. For example, at least one of A, B, may represent any one or more elements selected from a set that communicates A, B, and C. In addition, the term "plurality" means two or more, unless otherwise precisely and specifically specified.

[0152] In the description of the embodiment of the present application, the terms "first", "second", "third", "fourth", etc. (if present) are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0153] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for configuring permissions of a subsystem, characterized in that: include: Determine whether each subsystem in the target platform has external permission functions with other subsystems; For each subsystem with an external authority function, obtain the authorization object of the subsystem and its basic information to obtain the authorization object information; wherein the authorization object includes the internal authorization object of the subsystem and the external authorization object of the subsystem; Based on the authorization object information, permissions on corresponding subsystems are respectively configured for users corresponding to the authorization objects.

2. The method according to claim 1, characterized in that The step of respectively determining whether each subsystem in the target platform has external authority functions with other subsystems includes: Obtain the permission start flag and / or permission close flag of each subsystem regarding the external permission function between other subsystems; Based on the permission start identifier and / or the permission close identifier, it is determined whether each subsystem in the target platform has an external permission function with other subsystems.

3. The method according to claim 1 or 2, characterized in that: When the authorization object is an internal authorization object of the subsystem, the basic information includes a role ID of the internal authorization object; and / or, When the authorization object is an external authorization object of the subsystem, the basic information includes the subsystem to which the external authorization object belongs, the role ID and the verification address; The basic information is used to verify the permission request according to the basic information when the user initiates a permission request for the corresponding subsystem.

4. A method for handling permissions of a subsystem, characterized in that: include: In response to a user's permission request for any subsystem in the target platform, obtaining authorization object information of the requested subsystem; wherein the authorization object information includes an authorization object and its basic information, and the authorization object includes an internal authorization object of the requested subsystem and an external authorization object of the requested subsystem; Based on the authorization object information, it is verified whether the user is the user corresponding to the authorization object of the requested subsystem. If so, it is determined that the user has the authority of the requested subsystem, and the user is authorized to operate the requested subsystem with the corresponding authority.

5. The method according to claim 4, characterized in that Before obtaining the authorization object information of the requested subsystem, it also includes: Identifying the subsystem to which the user currently belongs; The verifying, based on the authorization object information, whether the user is a user corresponding to the authorization object of the requested subsystem includes: When the subsystem to which the user currently belongs is consistent with the requested subsystem, verifying whether the user is a user corresponding to the internal authorization object of the requested subsystem based on the authorization object information; or, When the subsystem to which the user currently belongs is inconsistent with the requested subsystem, it is verified based on the authorization object information whether the user is a user corresponding to the external authorization object of the requested subsystem.

6. The method according to claim 5, characterized in that When the authorization object of the requested subsystem is an internal authorization object, the basic information includes the role ID of the internal authorization object; The verifying whether the user is a user corresponding to the internal authorization object of the requested subsystem based on the authorization object information includes: matching the role ID of the user with the role ID of the internal authorization object, and if the match is successful, determining that the user is the internal authorization object of the requested subsystem; or, When the authorization object of the requested subsystem is an external authorization object, the basic information includes the subsystem to which the external authorization object belongs, the role ID and the verification address; The verifying, based on the authorization object information, whether the user is a user corresponding to the external authorization object of the requested subsystem includes: Sending the role ID of the user to the subsystem to which the external authorization object belongs based on the verification address; In the subsystem to which the external authorization object belongs, the role ID of the user is matched with the role ID of the external authorization object. If the match is successful, it is determined that the user is the external authorization object of the requested subsystem.

7. A subsystem authority configuration device, characterized in that: include: A function determination module, which is configured to respectively determine whether each subsystem in the target platform has an external authority function with other subsystems; A first acquisition module is configured to acquire the authorization object and basic information of each subsystem with an external authority function, and obtain authorization object information; wherein the authorization object includes an internal authorization object of the subsystem and an external authorization object of the subsystem; The permission configuration module is configured to configure the permissions of the corresponding subsystem for the corresponding user of the authorization object based on the authorization object information.

8. A subsystem authority processing device, characterized in that: include: A second acquisition module, which is configured to respond to a user's permission request for any subsystem in the target platform and acquire authorization object information of the requested subsystem; wherein the authorization object information includes an authorization object and its basic information, and the authorization object includes an internal authorization object of the requested subsystem and an external authorization object of the requested subsystem; A verification module is configured to verify whether the user is the user corresponding to the authorization object of the requested subsystem based on the authorization object information. If so, it is determined that the user has the authority of the requested subsystem and the user is authorized to operate the requested subsystem with the corresponding authority.

9. An electronic device, characterized in that: include: Memory and processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the electronic device executes the permission configuration method of the subsystem described in any one of claims 1 to 3, or the permission processing method of the subsystem described in any one of claims 4 to 6.

10. A computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the permission configuration method for the subsystem as described in any one of claims 1 to 3, or the permission processing method for the subsystem as described in any one of claims 4 to 6.

Images