Cross-system access method and device, equipment, storage medium and program product

Abstract

The invention discloses a cross-system access method and device, equipment, a storage medium and a program product, and belongs to the technical field of security access. The method is applied to a first system and comprises the steps that in response to an access request of a target user of a second system to the first system, a first target permission category label sent by the second system is received, and the first target permission category label is a permission category label of the target user in the second system; verifying the first target permission category label; determining a target permission range of the first system corresponding to the first target permission category label under the condition that the verification is passed; and returning access resources corresponding to the target permission range to the second system. According to the embodiment of the invention, while the conciseness of cross-system access can be improved, the cross-system access has relatively high security.

Description

Technical Field

[0001] The present application belongs to the field of secure access technology, and in particular, relates to a cross-system access method, device, equipment, storage medium and program product. Background Art

[0002] In the current multi-system architecture, there are often application scenarios where different systems, platforms, and components access each other. In these application scenarios, permission verification and permission control must be performed on cross-system access.

[0003] Currently, permission verification and permission control are usually performed based on the role of the user's logged-in account. Therefore, in the scenario of two different systems authenticating, each system will synchronize a copy of the other's user role to authenticate cross-system access. This method requires that the user and permission changes of the accessing system must be synchronized to the accessed system, otherwise accurate authentication cannot be performed. The accessed system must also undergo corresponding permission modifications to adapt to the accessing system.

[0004] In cross-system access between lightweight systems, the scenarios that require authentication are relatively simple. However, the above method requires major changes to the system and is not suitable for authentication scenarios of lightweight systems. Therefore, it is urgent to provide a cross-system access authentication solution that is both simple and secure. Summary of the invention

[0005] The embodiments of the present application provide a cross-system access method, apparatus, device and computer storage medium, which can improve the simplicity of cross-system access while making the cross-system access more secure.

[0006] In a first aspect, an embodiment of the present application provides a cross-system access method, which is applied to a first system, and the method includes:

[0007] In response to an access request from a target user of the second system to the first system, receiving a first target permission category label sent by the second system, where the first target permission category label is a permission category label of the target user in the second system;

[0008] Verifying the first target permission category label;

[0009] If the verification is successful, determining the target permission range of the first system corresponding to the first target permission category label;

[0010] Return the access resources corresponding to the target permission range to the second system.

[0011] In an optional implementation, verifying the first target permission category label includes:

[0012] According to the preset correspondence between the first permission category label and the second permission category label, searching for the second target permission category label corresponding to the first target permission category label in the second permission category label set of the first system, the first permission category label is the permission category label of the second system, the second permission category label is the permission category label of the first system, and the second permission category label set includes multiple second permission category labels;

[0013] In a case where the second permission category tag set includes a second target permission category tag corresponding to the first target permission category tag, determining that the verification is passed;

[0014] In the case that the second permission category tag set does not include the second target category tag corresponding to the first target permission category tag, it is determined that the verification fails.

[0015] In an optional implementation, when the verification is passed, determining the target permission range of the first system corresponding to the first target permission category label includes:

[0016] If the verification is successful, determine the preset permission range corresponding to the second target permission category label in the first system;

[0017] Determine the preset permission scope as the target permission scope.

[0018] In an optional implementation, before receiving the first target permission category label sent by the second system, the method further includes:

[0019] Acquire multiple pieces of permission information sent by the second system, where the permission information includes a first permission category label and first permission category information corresponding to the first permission category label;

[0020] When the first permission category information meets the preset condition, assigning a corresponding second permission category label to the permission information corresponding to the first permission category;

[0021] The corresponding relationship between the first permission category label and the second permission category label is determined according to the allocation result.

[0022] In an optional implementation, after assigning a corresponding second permission category label to the permission information corresponding to the first permission category, the method further includes:

[0023] According to the preset permission configuration rule, the second permission category label corresponding to each permission information is configured in the permission range of the first system according to the first permission category information of each permission information.

[0024] In a second aspect, an embodiment of the present application provides a cross-system access method, which is applied to a second system, and the method includes:

[0025] In response to a target user of the second system's access request to the first system, obtaining a first target permission category label of the target user in the second system;

[0026] Sending the first target permission category tag to the first system so that the first system verifies the first target permission category tag;

[0027] When the verification is successful, the access resources corresponding to the target authority range returned by the first system are received, where the target authority range is the target authority range of the first system corresponding to the first target authority category tag.

[0028] In an optional implementation, before sending the first target permission category label to the first system, the method further includes:

[0029] Verifying the first target permission category label;

[0030] Sending a first target permission category label to the first system includes:

[0031] When the first target permission category tag passes the verification, the first target permission category tag is sent to the first system.

[0032] In an optional implementation, the first system verifies the first target permission category label, including: the first system verifies the first target permission category label according to a preset correspondence between the first permission category label and the second permission category label, the first permission category label is the permission category label of the second system, and the second permission category label is the permission category label of the first system;

[0033] In response to an access request from a target user of the second system to the first system, before obtaining a first target permission category label of the target user in the second system, the method further includes:

[0034] Classify the permission range of the second system according to a preset permission classification rule to obtain a plurality of permission information, wherein the permission information includes a first permission category label and first permission category information corresponding to the first permission category label;

[0035] Determine the correspondence between the user and the first permission category label according to the identity information of the user in the second system;

[0036] The plurality of permission information is sent to the first system, so that the first system determines the corresponding relationship between the first permission category label and the second permission category label according to the plurality of permission information.

[0037] In a third aspect, an embodiment of the present application provides a cross-system access device, which is applied to a first system, and the device includes:

[0038] A receiving module, configured to receive a first target permission category label sent by the second system in response to an access request from a target user of the second system to the first system, wherein the first target permission category label is a permission category label of the target user in the second system;

[0039] A verification module, used to verify the first target permission category label;

[0040] A determination module, used to determine the target permission range of the first system corresponding to the first target permission category label when the verification is passed;

[0041] The return module is used to return the access resources corresponding to the target permission range to the second system.

[0042] In a fourth aspect, an embodiment of the present application provides a cross-system access device, which is applied to a second system, and the device includes:

[0043] An acquisition module, configured to acquire a first target permission category label of the target user in the second system in response to an access request from the target user of the second system to the first system;

[0044] A sending module, used for sending the first target permission category label to the first system, so that the first system can verify the first target permission category label;

[0045] The receiving module is used to receive access resources corresponding to the target authority range returned by the first system when the verification is passed, and the target authority range is the target authority range of the first system corresponding to the first target authority category label.

[0046] In a fifth aspect, an embodiment of the present application provides a cross-system access device, the device comprising:

[0047] A processor and a memory storing computer program instructions; when the processor executes the computer program instructions, any one of the above cross-system access methods is implemented.

[0048] In a sixth aspect, an embodiment of the present application provides a computer storage medium, on which computer program instructions are stored. When the computer program instructions are executed by a processor, any one of the above-mentioned cross-system access methods is implemented.

[0049] In a seventh aspect, an embodiment of the present application provides a computer program product. When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device can execute any one of the above-mentioned cross-system access methods.

[0050] The cross-system access method, device, equipment and computer storage medium of the embodiment of the present application are applied to the first system, and can respond to the access request of the target user of the second system to the first system, and receive the first target permission category label sent by the second system, and the first target permission category label is the permission category label of the target user in the second system. Then, the first target permission category label is verified. In this way, the first system only needs to synchronize and store the permission category label of the second system, and does not need to synchronize all user information of the second system, and can verify the access request of the second system. In this way, it can be applied to the authentication scenario of lightweight systems, and the simplicity of cross-system access authentication is improved. Then, when the verification is passed, the target permission range of the first system corresponding to the first target permission category label is determined, and the access resources corresponding to the target permission range are returned to the second system. In this way, the permission range of the user in the first system can be determined according to the permission category label of the user in the second system. In this way, the first system can perform permission control on the access request of the user of the second system, and improve the security of cross-system access. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the technical solution of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0052] Figure 1 It is a flowchart of a cross-system access method provided by an embodiment of the present application;

[0053] Figure 2 is a flowchart of a cross-system access method provided by another embodiment of the present application;

[0054] Figure 3 is a structural diagram of a cross-system access device provided by another embodiment of the present application;

[0055] Figure 4 is a schematic diagram of the structure of a cross-system access device provided by yet another embodiment of the present application;

[0056] Figure 5 It is a structural diagram of a cross-system access device provided by yet another embodiment of the present application. DETAILED DESCRIPTION

[0057] The features and exemplary embodiments of various aspects of the present application will be described in detail below. In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than to limit the present application. For those skilled in the art, the present application can be implemented without the need for some of these specific details. The following description of the embodiments is only to provide a better understanding of the present application by illustrating the examples of the present application.

[0058] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "include..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0059] It should be noted that the acquisition, storage, use and processing of data in the embodiments of the present application are in compliance with the relevant provisions of national laws and regulations.

[0060] It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, and they should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0061] As described in the background technology, in the current cross-system access authentication scenario, permission verification and permission control are usually performed based on the role of the user's logged-in account. Therefore, in the scenario of two different system authentications, each system will synchronize a copy of the other's user role to authenticate cross-system access. This method requires that changes in users and permissions of the accessing system must be synchronized to the accessed system, otherwise authentication cannot be performed accurately. The accessed system must also undergo corresponding permission modifications to adapt to the accessing system.

[0062] In cross-system access between lightweight systems, the scenarios that require authentication are relatively simple. However, the above methods require major changes to the system and are not suitable for authentication scenarios of lightweight systems. Therefore, an authentication method is needed that can identify permissions without requiring too much modification to the system. This method can also be called remote authentication.

[0063] In the related art, the off-site authentication scheme involves that after the user who actively accesses the system logs in successfully, when he clicks to access the relevant content of the accessed system, the system will jump to the accessed system with a fixed access account. After receiving the access request, the accessed system generally only performs a general access verification to verify whether the access request comes from the active access system. After the verification is passed, the accessed system opens fixed access rights to allow users to access across systems. Since users who actively access the system all use the same access account to access, and each user needs to access different content, the access account usually has higher access rights. In this way, on the one hand, it will lead to centralized permissions and it will be impossible to distinguish user access. On the other hand, since the access account has higher access rights, the accessed system cannot judge and control the access request of the active access system. Once the access account is intercepted by a third party, the accessed system will open higher access rights to the third party, which will increase the possibility of the accessed system being attacked.

[0064] In order to solve the problems of the prior art, embodiments of the present application provide a cross-system access method, apparatus, device and computer storage medium.

[0065] The following first introduces the cross-system access method provided by the embodiment of the present application in conjunction with the accompanying drawings.

[0066] Figure 1 FIG. 1 is a flow chart of a cross-system access method provided by an embodiment of the present application. Figure 1 As shown, the method may include the following steps S110 to S150.

[0067] S110, the second system obtains a first target permission category label of the target user in the second system in response to an access request of the target user of the second system to the first system.

[0068] In step S110, the second system may be the active access system, and the first system may be the accessed system. The first target permission category label may be used to characterize the permission category of the target user in the second system. Exemplarily, the second system may classify its own permission range, generate different first permission category labels, and assign corresponding first permission category labels to users of the second system.

[0069] S120: The second system sends the first target permission category label to the first system, so that the first system verifies the first target permission category label.

[0070] Accordingly, the first system receives a first target permission category label sent by the second system in response to an access request from a target user of the second system to the first system, where the first target permission category label is a permission category label of the target user in the second system.

[0071] S130: The first system verifies the first target permission category label.

[0072] In step S130, the verification of the first target permission category label can be implemented by methods known in the art, which are not limited here. Exemplarily, the source of the first target permission category label can be verified. Exemplarily, the first target permission category label can also be verified based on the permission category information of the second system pre-synchronized in the first system.

[0073] S140: When the verification is passed, the first system determines a target authority range of the first system corresponding to the first target authority category label.

[0074] In step S140, the target permission range may include the permission range of the first target permission category label in the first system. As an example, the target permission range may be determined according to the permission category corresponding to the first target permission category label and the permission matching rule of the first system. As another example, the correspondence between the first permission category label and the permission range of the first system may be pre-set, and the target permission range corresponding to the first target permission category label may be directly determined according to the correspondence between the first permission category label and the permission range of the first system.

[0075] S150: The first system returns access resources corresponding to the target permission range to the second system.

[0076] Correspondingly, when the verification is passed, the second system receives the access resources corresponding to the target authority range returned by the first system, where the target authority range is the target authority range of the first system corresponding to the first target authority category label.

[0077] In the cross-system access method of the embodiment of the present application, the second system can respond to the target user of the second system's access request to the first system, obtain the target user's first target permission category label in the second system, and send the first target permission category label to the first system. Correspondingly, the first system can respond to the target user of the second system's access request to the first system and receive the first target permission category label sent by the second system. Then, the first target permission category label is verified. In this way, the first system only needs to synchronize and store the permission category label of the second system, and does not need to synchronize all user information of the second system to verify the access request of the second system. In this way, it can be applied to the authentication scenario of lightweight systems and improve the simplicity of cross-system access authentication. Then, if the verification is passed, the first system can determine the target permission range of the first system corresponding to the first target permission category label, and return the access resource corresponding to the target permission range to the second system. In this way, the first system can determine the permission range of the user in the first system according to the permission category label of the second system. In this way, the first system can perform permission control on the access request of the second system user and improve the security of cross-system access.

[0078] In one embodiment, the first system verifies the first target permission category label, which may specifically include:

[0079] The first system searches for a second target permission category tag corresponding to the first target permission category tag in the second permission category tag set of the first system based on a preset correspondence between the first permission category tag and the second permission category tag, the first permission category tag is the permission category tag of the second system, the second permission category tag is the permission category tag of the first system, and the second permission category tag set includes multiple second permission category tags.

[0080] The first system determines that the verification is successful if the second permission category tag set includes the second target permission category tag corresponding to the first target permission category tag.

[0081] The first system determines that the verification fails when the second permission category tag set does not include the second target category tag corresponding to the first target permission category tag.

[0082] In the above implementation, based on the preset correspondence between the first permission category label and the second permission category label, it can be determined whether the first system has a second permission category label corresponding to the first permission category label. If it exists, it means that the first permission category label has corresponding access rights in the first system. If it does not exist, it means that the first permission category label does not have corresponding access rights in the first system, and the access request of the second system can be rejected. In one example, the preset correspondence between the first permission category label and the second permission category label can be stored in the first system and can be adjusted according to the authentication needs of the first system. In this way, the degree of permission control of the first system can be improved, and the flexibility of the first system in authenticating cross-system access requests can be improved.

[0083] According to the above implementation, the first system can verify whether the first target permission category label has corresponding access rights in the first system based on the correspondence between the first permission category label and the second permission category label pre-set by the first system. If the access rights are granted, subsequent permission control is performed. In this way, the first system only needs to store the correspondence between the first permission category label and the second permission category label to authenticate the first permission category label of the second system. This is conducive to improving the simplicity of the system and the accuracy of authentication, thereby improving the security of cross-system access between lightweight systems.

[0084] In one embodiment, when the verification is passed, the first system determines the target permission range of the first system corresponding to the first target permission category label, which may specifically include:

[0085] When the verification is passed, the first system determines that the second target permission category label is within a preset permission range corresponding to the first system.

[0086] The first system determines the preset authority range as the target authority range.

[0087] According to the above implementation, the preset permission range corresponding to the second target permission category label in the first system can be determined as the target permission range corresponding to the first target permission category label. In this way, the permission category of the second system can be associated with the access permission range corresponding to the first system through the correspondence between the second permission category label and the first permission category label. In this way, it is helpful to quickly and accurately determine the access permission range of the first target permission category label in the first system, thereby improving the efficiency of cross-system access and thus improving the user experience.

[0088] In addition, according to the above implementation, the permission range corresponding to the second permission category label in the first system can be determined as the permission range of the first permission category label in the first system. The permission range corresponding to the second permission category label in the first system is configured and managed by the first system, so that the first system can flexibly control the access rights of the second system, thereby improving the flexibility of permission control.

[0089] In one embodiment, the first system verifies the first target permission category label, which may specifically include: the first system verifies the first target permission category label according to a preset correspondence between the first permission category label and the second permission category label, the first permission category label is the permission category label of the second system, and the second permission category label is the permission category label of the first system.

[0090] Before the second system obtains the first target permission category label of the target user in the second system in response to the access request of the target user of the second system to the first system, the cross-system access method may further include:

[0091] The second system classifies the permission scope of the second system according to a preset permission classification rule to obtain a plurality of permission information, wherein the permission information includes a first permission category label and first permission category information corresponding to the first permission category label.

[0092] The second system determines the corresponding relationship between the user and the first permission category label according to the identity information of the user in the second system.

[0093] The second system sends the plurality of permission information to the first system, so that the first system determines the corresponding relationship between the first permission category label and the second permission category label according to the plurality of permission information.

[0094] In the above implementation, the preset permission classification rules can be formulated according to actual needs. As an example, the permission range of the second system can be divided into multiple levels, and the corresponding first permission category labels can be assigned according to the user's position in the enterprise. As another example, the permission range of the second system can be classified according to the job category, and the corresponding first permission category labels can be classified according to the user's position in the enterprise.

[0095] According to the above implementation, the second system will classify the user's authority scope in its own system and obtain authority information. The authority information is then sent to the first system so that the first system can determine the correspondence between the first authority category label and the second authority category label based on multiple authority information. In this way, the first system only needs to synchronize the authority information of the second system and configure the corresponding second authority category label for each first authority category label according to the authority control policy of the first system. In this way, it is not necessary to synchronize all user information of the second system, and authentication can be performed based on the first authority category label carried by the access request. In this way, the simplicity of the system can be improved while having high authentication accuracy.

[0096] In one embodiment, before the first system receives the first target permission category tag sent by the second system, the cross-system access method may further include:

[0097] The first system obtains a plurality of permission information sent by the second system, where the permission information includes a first permission category tag and first permission category information corresponding to the first permission category tag.

[0098] The first system allocates a corresponding second permission category label to the permission information corresponding to the first permission category when the first permission category information meets a preset condition.

[0099] The first system determines a corresponding relationship between the first permission category label and the second permission category label according to the allocation result.

[0100] In the above implementation, the first permission category information meeting the preset conditions may include determining, according to a preset permission control policy, whether the first system's access rights have access rights that match the first permission category information. Exemplarily, if the first system is a business system, the first system's access rights may include product data query rights, product data modification rights, and business transaction information query rights. When the first permission category information is a product permission or a business permission, it can be determined that the first permission category information meets the preset conditions. When the first permission category information is a personnel management permission, it can be determined that the first permission category information does not meet the preset conditions.

[0101] According to the above implementation, the first system can assign the second permission category label to the permission information according to the permission category information in the permission information, and then determine the correspondence between the first permission category label and the second permission category label according to the assignment result. In other words, whether each first permission category label of the second system has the access rights of the first system can be determined by the first system. In this way, the control of the first system over the access rights is strengthened, which is conducive to improving the security of the first system.

[0102] In one embodiment, after the first system assigns a corresponding second permission category label to the permission information corresponding to the first permission category, the cross-system access method may further include:

[0103] The first system configures the second permission category label corresponding to each permission information within the permission scope of the first system according to the preset permission configuration rule and the first permission category information of each permission information.

[0104] According to the above implementation, after the first system assigns the corresponding second permission category tag to the permission information corresponding to the first permission category, it configures the permission scope of the second permission category tag in the first system according to the permission configuration rules. In this way, the access permission scope of each first permission category tag of the second system can be determined by the first system. When the first system needs to adjust the access rights, the permission adjustment can be completed without synchronization with the second system. In this way, the flexibility of the permission control of the first system can be improved while improving the simplicity of the system. In addition, according to the above implementation, even if the first permission range tag in the access request is intercepted by a third party, the first system can promptly control the access rights of the first permission range tag, thereby improving the security of the first system.

[0105] For ease of understanding, based on the above implementation, Figure 2 , a specific example is given to illustrate the process of the first system synchronously storing the permission category label of the second system in the cross-system access method of the embodiment of the present application.

[0106] In one example, the first system verifies the first target permission category label, which may specifically include: the first system verifies the first target permission category label according to a preset correspondence between the first permission category label and the second permission category label, the first permission category label is the permission category label of the second system, and the second permission category label is the permission category label of the first system.

[0107] like Figure 2 As shown, before the second system obtains the first target permission category label of the target user in the second system in response to the access request of the target user of the second system to the first system, the cross-system access method may further include the following steps S210 to S260.

[0108] S210, the second system classifies the permission scope of the second system according to a preset permission classification rule to obtain a plurality of permission information, where the permission information includes a first permission category label and first permission category information corresponding to the first permission category label.

[0109] S220: The second system determines a correspondence between the user and the first permission category label according to the identity information of the user in the second system.

[0110] S230: The second system sends the plurality of permission information to the first system.

[0111] Accordingly, the first system can obtain the multiple permission information sent by the second system.

[0112] S240: When the first permission category information meets a preset condition, the first system assigns a corresponding second permission category label to the permission information corresponding to the first permission category.

[0113] S250: The first system determines a corresponding relationship between the first permission category label and the second permission category label according to the allocation result.

[0114] S260: The first system configures the second permission category label corresponding to each permission information in the permission range of the first system according to the preset permission configuration rule and the first permission category information of each permission information.

[0115] According to the above example, the second system will classify the user's permission range in its own system and obtain permission information. Then send the permission information to the first system. After the first system assigns the corresponding second permission category label to the permission information corresponding to the first permission category, it configures the second permission category label in the permission range of the first system according to the permission configuration rules. In this way, the first system only needs to synchronize the permission information of the second system to determine the access permission range of each first permission category label in the first system. In this way. When the first system needs to adjust the access rights, it can complete the adjustment of the rights without synchronizing with the second system. In this way, the flexibility of the permission control of the first system can be improved while improving the simplicity of the system.

[0116] In addition, according to the above implementation, even if the first permission range tag in the access request is intercepted by a third party, the first system can promptly control the access rights of the first permission range tag, thereby improving the security of the first system.

[0117] In one embodiment, before the second system sends the first target permission category tag to the first system, the cross-system access method may further include:

[0118] The second system verifies the first target permission category label.

[0119] The second system sends the first target permission category tag to the first system, which may specifically include:

[0120] If the first target permission category tag passes the verification, the second system sends the first target permission category tag to the first system.

[0121] In the above implementation, the second system verifies the first target permission category label, which may include: verifying whether the first target permission category label has cross-system access permissions. In one example, the access request may include access to a resource object, and the second system verifies the first target permission category label, which may include: verifying whether the permission category corresponding to the first target permission category label matches the access to the resource object. For example, the permission category corresponding to the first target permission category label may be a product-class permission, and the access to the resource object may be a business-class resource object. In this case, it can be determined that the first target permission category label has not passed the verification.

[0122] According to the above implementation, the second system can verify the first target permission category tag before issuing a cross-system access request, and send the first target permission category tag to the first system if the first target permission category tag passes the verification. In this way, pre-authentication can be performed through the second system, thereby reducing the authentication burden of the first system. In turn, the efficiency of cross-system authentication can be improved.

[0123] Based on the cross-system access method provided in the above embodiment, the present application also provides a specific implementation of a cross-system access device, which can be applied to the first system. Please refer to the following embodiments.

[0124] See first Figure 3 The cross-system access device 200 provided in the embodiment of the present application includes a first receiving module 201, a verification and determination module 202, a first determination module 203 and a return module 204.

[0125] The first receiving module 201 is used to receive a first target permission category label sent by the second system in response to an access request from a target user of the second system to the first system, where the first target permission category label is a permission category label of the target user in the second system.

[0126] The verification module 202 is used to verify the first target permission category label.

[0127] The first determination module 203 is used to determine the target permission range of the first system corresponding to the first target permission category label when the verification is passed.

[0128] The return module 204 is used to return the access resources corresponding to the target permission range to the second system.

[0129] The cross-system access device of the embodiment of the present application is applied to the first system, and can respond to the access request of the target user of the second system to the first system, and receive the first target permission category label sent by the second system, and the first target permission category label is the permission category label of the target user in the second system. Then, the first target permission category label is verified. In this way, the first system only needs to synchronize and store the permission category label of the second system, and does not need to synchronize all user information of the second system to verify the access request of the second system. In this way, it can be applied to the authentication scenario of lightweight systems to improve the simplicity of cross-system access authentication. Then, when the verification is passed, the target permission range of the first system corresponding to the first target permission category label is determined, and the access resources corresponding to the target permission range are returned to the second system. In this way, the permission range of the user in the first system can be determined according to the permission category label of the user in the second system. In this way, the first system can perform permission control on the access request of the user of the second system and improve the security of cross-system access.

[0130] In one embodiment, the verification module may be specifically used to:

[0131] According to the preset correspondence between the first permission category tag and the second permission category tag, the second target permission category tag corresponding to the first target permission category tag is searched in the second permission category tag set of the first system, the first permission category tag is the permission category tag of the second system, the second permission category tag is the permission category tag of the first system, and the second permission category tag set includes multiple second permission category tags.

[0132] In a case where the second permission category tag set includes a second target permission category tag corresponding to the first target permission category tag, it is determined that the verification is passed.

[0133] In the case that the second permission category tag set does not include the second target category tag corresponding to the first target permission category tag, it is determined that the verification fails.

[0134] In one embodiment, the first determination module may be specifically used to:

[0135] When the verification is passed, the preset permission range corresponding to the second target permission category label in the first system is determined.

[0136] Determine the preset permission scope as the target permission scope.

[0137] In one embodiment, the cross-system access device may further include:

[0138] The first acquisition module is used to acquire multiple permission information sent by the second system before receiving the first target permission category tag sent by the second system, the permission information including the first permission category tag and the first permission category information corresponding to the first permission category tag.

[0139] The allocation module is used to allocate a corresponding second permission category label to the permission information corresponding to the first permission category when the first permission category information meets a preset condition.

[0140] The second determining module is used to determine the corresponding relationship between the first permission category label and the second permission category label according to the allocation result.

[0141] In one embodiment, the cross-system access device may further include:

[0142] The configuration module is used to configure the second permission category label corresponding to each permission information within the permission scope of the first system according to the first permission category information of each permission information, after allocating the corresponding second permission category label to the permission information corresponding to the first permission category, in accordance with the preset permission configuration rules.

[0143] Based on the cross-system access method provided in the above embodiment, the present application also provides a specific implementation of a cross-system access device, which can be applied to the second system. Please refer to the following embodiment.

[0144] See first Figure 4 The cross-system access device 200 provided in the embodiment of the present application includes a second acquisition module 301 , a sending module 302 and a second receiving module 303 .

[0145] The second acquisition module 301 is used to obtain a first target permission category label of the target user in the second system in response to an access request from the target user of the second system to the first system.

[0146] The sending module 302 sends the first target permission category label to the first system, so that the first system can verify the first target permission category label.

[0147] The second receiving module 303 is used to receive access resources corresponding to the target authority range returned by the first system when the verification is passed, where the target authority range is the target authority range of the first system corresponding to the first target authority category tag.

[0148] The cross-system access device of the embodiment of the present application is applied to the second system, and can respond to the access request of the target user of the second system to the first system, and obtain the first target permission category label of the target user in the second system. Then, the first target permission category label is sent to the first system for the first system to verify the first target permission category label. In this way, the first system only needs to synchronize and store the permission category label of the second system, and does not need to synchronize all user information of the second system, and can verify the access request of the second system. In this way, it can be applied to the authentication scenario of lightweight systems, and the simplicity of cross-system access authentication is improved. Then, if the verification is passed, the access resource corresponding to the target permission range returned by the first system can be received, and the target permission range is the target permission range of the first system corresponding to the first target permission category label. In this way, the permission range of the user in the first system can be determined according to the permission category label of the user in the second system, and then the corresponding access resource can be obtained. In this way, the first system can perform permission control on the access request of the user of the second system, and improve the security of cross-system access.

[0149] In one embodiment, the cross-system access device may further include:

[0150] The verification module is used to verify the first target permission category label before sending the first target permission category label to the first system.

[0151] The sending module may be specifically configured to send the first target permission category label to the first system when the first target permission category label passes verification.

[0152] In one embodiment, the first system verifies the first target permission category label, which may include: the first system verifies the first target permission category label according to a preset correspondence between the first permission category label and the second permission category label, the first permission category label is the permission category label of the second system, and the second permission category label is the permission category label of the first system.

[0153] Cross-system access means may also include:

[0154] A classification module is used to respond to an access request from a target user of the second system to the first system, and before obtaining a first target permission category label of the target user in the second system, classify the permission scope of the second system according to a preset permission classification rule to obtain multiple permission information, wherein the permission information includes a first permission category label and first permission category information corresponding to the first permission category label.

[0155] The third determination module is used to determine the correspondence between the user and the first permission category label according to the identity information of the user in the second system.

[0156] The sending module is further used to send the plurality of permission information to the first system, so that the first system can determine the corresponding relationship between the first permission category label and the second permission category label according to the plurality of permission information.

[0157] The various modules of the cross-system access device provided in the embodiment of the present application can realize Figure 1 The functions of each step of the cross-system access method are provided and can achieve the corresponding technical effects. For the sake of brevity, they will not be repeated here.

[0158] Figure 5 A schematic diagram of the hardware structure of a cross-system access device provided in an embodiment of the present application is shown.

[0159] The cross-system access device may include a processor 401 and a memory 402 storing computer program instructions.

[0160] Specifically, the processor 401 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0161] Memory 402 may include a large capacity memory for data or instructions. By way of example and not limitation, memory 402 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. In appropriate cases, memory 402 may include a removable or non-removable (or fixed) medium. In appropriate cases, memory 402 may be inside or outside of an integrated gateway disaster recovery device. In a specific embodiment, memory 402 is a non-volatile solid-state memory.

[0162] The memory may include read-only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical or other physical / tangible memory storage devices. Thus, typically, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to an aspect of the present disclosure.

[0163] The processor 401 implements any one of the cross-system access methods in the above embodiments by reading and executing computer program instructions stored in the memory 402 .

[0164] In one example, the cross-system access device may further include a communication interface 403 and a bus 410. Figure 5 As shown, the processor 401, the memory 402, and the communication interface 403 are connected via a bus 410 and communicate with each other.

[0165] The communication interface 403 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.

[0166] Bus 410 includes hardware, software or both, and the parts of online data flow billing equipment are coupled to each other. For example, but not limitation, bus may include accelerated graphics port (AGP) or other graphics bus, enhanced industrial standard architecture (EISA) bus, front-side bus (FSB), hypertransport (HT) interconnection, industrial standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In appropriate cases, bus 410 may include one or more buses. Although the present application embodiment describes and shows a specific bus, the present application considers any suitable bus or interconnection.

[0167] The cross-system access device can execute the cross-system access method in the embodiment of the present application, thereby realizing the combination Figure 1 and Figure 3-4 The cross-system access method and device described. The cross-system access method in the above embodiment can be implemented by providing a computer storage medium in the embodiment of the present application. The computer storage medium stores computer program instructions; when the computer program instructions are executed by the processor, any cross-system access method in the above embodiment is implemented.

[0168] An embodiment of the present application also provides a computer program product, including a computer program, which implements any one of the cross-system access methods in the above embodiments when the computer program is processed and executed.

[0169] It should be clear that the present application is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present application is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present application.

[0170] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware or a combination thereof. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), appropriate firmware, a plug-in, a function card, etc. When implemented in software, the elements of the present application are programs or code segments that are used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. The code segment can be downloaded via a computer network such as the Internet, an intranet, etc.

[0171] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps, that is, the steps can be performed in the order mentioned in the embodiment, or in a different order from the embodiment, or several steps can be performed simultaneously.

[0172] Aspects of the present disclosure are described above with reference to the flowchart and / or block diagram of the method, device (system) and computer program product according to the embodiment of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine so that these instructions executed by the processor of the computer or other programmable data processing device enable the implementation of the function / action specified in one or more boxes of the flowchart and / or block diagram. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field programmable logic circuit. It can also be understood that each box in the block diagram and / or flowchart and the combination of boxes in the block diagram and / or flowchart can also be implemented by dedicated hardware that performs a specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0173] The above are only specific implementation methods of the present application. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the protection scope of the present application is not limited to this. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in this application, and these modifications or replacements should be included in the protection scope of this application.

Claims

1. A cross-system access method, characterized in that: Applied to the first system, the method comprises: In response to an access request from a target user of the second system to the first system, receiving a first target permission category label sent by the second system, where the first target permission category label is a permission category label of the target user in the second system; Verifying the first target permission category label; If the verification is passed, determining a target permission range of the first system corresponding to the first target permission category label; Return access resources corresponding to the target permission range to the second system.

2. The cross-system access method according to claim 1, characterized in that: The verifying the first target permission category label includes: According to the preset correspondence relationship between the first permission category label and the second permission category label, searching for the second target permission category label corresponding to the first target permission category label in the second permission category label set of the first system, the first permission category label is the permission category label of the second system, the second permission category label is the permission category label of the first system, and the second permission category label set includes a plurality of second permission category labels; In a case where the second permission category tag set includes a second target permission category tag corresponding to the first target permission category tag, determining that the verification is passed; When the second permission category tag set does not include a second target category tag corresponding to the first target permission category tag, it is determined that the verification fails.

3. The cross-system access method according to claim 2, characterized in that: In the case where the verification is passed, determining the target permission range of the first system corresponding to the first target permission category label includes: If the verification is successful, determining a preset permission range corresponding to the second target permission category label in the first system; The preset authority range is determined as the target authority range.

4. The cross-system access method according to claim 2 or 3, characterized in that: Before receiving the first target permission category label sent by the second system, the method further includes: Acquire multiple pieces of permission information sent by the second system, the permission information including a first permission category tag and first permission category information corresponding to the first permission category tag; When the first permission category information meets the preset condition, assigning a corresponding second permission category label to the permission information corresponding to the first permission category; The corresponding relationship between the first permission category label and the second permission category label is determined according to the allocation result.

5. The cross-system access method according to claim 4, characterized in that: After assigning a corresponding second permission category label to the permission information corresponding to the first permission category, the method further includes: According to the preset permission configuration rule, the second permission category label corresponding to each permission information is configured in the permission range of the first system according to the first permission category information of each permission information.

6. A cross-system access method, characterized in that: Applied to the second system, the method comprises: In response to an access request from a target user of the second system to the first system, obtaining a first target permission category label of the target user in the second system; Sending the first target permission category label to a first system, so that the first system verifies the first target permission category label; When the verification is passed, access resources corresponding to the target authority range returned by the first system are received, where the target authority range is the target authority range of the first system corresponding to the first target authority category label.

7. The cross-system access method according to claim 6, characterized in that: Before sending the first target permission category label to the first system, the method further includes: Verifying the first target permission category label; The sending the first target permission category label to the first system includes: When the first target permission category tag passes verification, the first target permission category tag is sent to the first system.

8. The cross-system access method according to claim 6 or 7, characterized in that: The first system verifies the first target permission category label, including: the first system verifies the first target permission category label according to a preset correspondence between the first permission category label and the second permission category label, the first permission category label is the permission category label of the second system, and the second permission category label is the permission category label of the first system; Before obtaining the first target permission category label of the target user in the second system in response to the access request of the target user of the second system to the first system, the method further includes: Classify the permission range of the second system according to a preset permission classification rule to obtain a plurality of permission information, wherein the permission information includes a first permission category label and first permission category information corresponding to the first permission category label; Determining a correspondence between the user and the first permission category label according to the identity information of the user in the second system; The plurality of permission information are sent to the first system, so that the first system determines a corresponding relationship between the first permission category label and the second permission category label according to the plurality of permission information.

9. A cross-system access device, characterized in that: Applied to the first system, the device comprises: A receiving module, configured to receive, in response to an access request from a target user of a second system to a first system, a first target permission category label sent by the second system, wherein the first target permission category label is a permission category label of the target user in the second system; A verification module, used to verify the first target permission category label; a determination module, configured to determine, if the verification passes, a target permission range of the first system corresponding to the first target permission category label; A return module is used to return the access resources corresponding to the target permission range to the second system.

10. A cross-system access device, characterized in that: Applied to the second system, the device comprises: An acquisition module, configured to acquire a first target permission category label of the target user in the second system in response to an access request from the target user of the second system to the first system; a sending module, configured to send the first target permission category label to a first system, so that the first system verifies the first target permission category label; A receiving module is used to receive access resources corresponding to a target authority range returned by the first system if the verification is passed, wherein the target authority range is the target authority range of the first system corresponding to the first target authority category label.

11. A cross-system access device, characterized in that: The device comprises: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the cross-system access method according to any one of claims 1 to 8 is implemented.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by a processor, the cross-system access method according to any one of claims 1 to 8 is implemented.

13. A computer program product, characterized in that When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device is enabled to execute the cross-system access method as described in any one of claims 1-8.

Images