Business system, request authentication method, electronic equipment and storage medium

Abstract

The invention provides a service system, a request authentication method, electronic equipment and a storage medium. The system comprises a front end, a foreground gateway, an application layer, a middle station gateway and a middle station application, the front end accesses the application layer through the foreground gateway, and the application layer calls the middle station application through the middle station gateway; the foreground gateway is used for performing login state verification on a user included in the first token information according to the first token information sent by the front end and verifying a first permission of the user so as to determine whether the user is allowed to access the application layer; and the middle station gateway is used for checking the second authority of the application layer according to the second token information of the application layer so as to determine whether the application layer allows to call the middle station application. And different service systems in the same service field multiplex the same group of foreground gateways and middle station gateways. According to the system architecture provided by the invention, the foreground gateway and the middle gateway are arranged to execute authentication tasks of different links respectively, so that the function of each gateway is simplified, and the system architecture is easier to expand and manage.

Description

Technical Field

[0001] The present application relates to the technical fields such as software development, and in particular to a business system, a request authentication method, an electronic device, and a storage medium. Background Art

[0002] Microservices (or microservice architecture) is a cloud-native architecture approach that includes numerous loosely coupled and independently deployable small components or services in a single application. By dividing a software system into multiple small, autonomous service units, each microservice runs in an independent process and interacts with other microservices through lightweight communication mechanisms (usually Hypertext Transfer Protocol (HTTP) or message queues). Each microservice focuses on performing a specific business function and can be independently deployed, updated, and scaled. The microservice architecture helps to achieve system modularity, flexibility, and maintainability, reduces the complexity of the software development process, and improves operational efficiency and customer experience.

[0003] A microservice gateway is a component that uniformly manages and controls each service in a microservice architecture. As the front-end portal in the microservice architecture, it provides a unified entry point for clients to access and call multiple microservices. Summary of the Invention

[0004] The present application aims to solve at least one of the technical problems in the related art to some extent.

[0005] To this end, the first object of the present application is to propose a business system. Through a layered architecture, the authentication tasks in different links are assigned to the front-end gateway and the middle-end gateway for execution, so as to improve the overall permission management, simplify the functions of each gateway, and make it easier to expand and manage. And a business system can be set up for different business fields respectively, so that the authentication function of the gateway can be further refined from the perspective of the business field, and the gateway efficiency can be improved.

[0006] The second object of the present application is to propose a request authentication method.

[0007] The third object of the present application is to propose an electronic device.

[0008] The fourth object of the present application is to propose a computer-readable storage medium.

[0009] The fifth object of the present application is to propose a computer program product.

[0010] To achieve the above object, the first aspect embodiment of the present application provides a business system, including:

[0011] The front end, the front-end gateway, the application layer, the middle-tier gateway, and the middle-tier application. Among them, the front end accesses the application layer through the front-end gateway, and the application layer invokes the middle-tier application through the middle-tier gateway;

[0012] The front-end gateway is used to perform a login status verification on the user included in the first token information sent by the front end to obtain a first verification result, and verify the first permission of the user to determine whether the user is allowed to access the application layer;

[0013] The middle-tier gateway is used to verify the second permission of the application layer according to the second token information of the application layer to determine whether the application layer is allowed to invoke the middle-tier application.

[0014] To achieve the above object, a request authentication method is proposed in the second aspect of the present application, which is executed by the front-end gateway and includes:

[0015] In response to an access request from the front end to the target application layer, obtain the first token information of the user included in the access request;

[0016] According to the first token information, verify the login status of the user to obtain a first verification result;

[0017] When the first verification result is logged in, obtain a second verification result on whether the user is allowed to access the target application layer;

[0018] When the second verification result is allowed to access, process the access request.

[0019] Further, a request authentication method is also proposed in the second aspect of the embodiment, which is executed by the middle-tier gateway and includes:

[0020] In response to a call request from the target application layer to the target middle-tier application, obtain the second token information included in the call request;

[0021] According to the second token information, obtain a third verification result on whether the target application layer is allowed to call the target middle-tier application;

[0022] When the third verification result is allowed to call, process the call request. To achieve the above object, an electronic device is proposed in the third aspect of the present application, including: a processor, and a memory communicatively connected to the processor;

[0023] The memory stores computer execution instructions;

[0024] The processor executes the computer execution instructions stored in the memory to implement the request authentication method as in the second aspect of the embodiment.

[0025] To achieve the above object, an embodiment of the fourth aspect of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, they are used to implement the request authentication method as in the embodiment of the second aspect.

[0026] To achieve the above object, an embodiment of the fifth aspect of the present application provides a computer program product, including a computer program, which when executed by a processor implements the request authentication method as in the embodiment of the second aspect.

[0027] The service system, request authentication method, electronic device, and storage medium provided by the present application divide the gateway into a front-end gateway and a middle-end gateway according to their responsibilities to be responsible for the permission management of the front-end and the middle-end respectively, and can further refine the functions of the front-end gateway and the middle-end gateway from the perspective of the business domain. Each business domain corresponds to a set of front-end gateway and middle-end gateway for authentication, making the permission management more perfect, simplifying the functions of each gateway, and making it more convenient for the expansion and management of the microservices architecture.

[0028] Some of the additional aspects and advantages of the present application will be given in the following description, some will become obvious from the following description, or will be understood through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The above and / or additional aspects and advantages of the present application will become obvious and easy to understand from the following description of the embodiments in conjunction with the drawings, where:

[0030] Figure 1 is a schematic diagram of the architecture of a service system provided by an embodiment of the present application;

[0031] Figure 2 is a schematic diagram of the architecture of a service system between different business domains provided by an embodiment of the present application;

[0032] Figure 3 is a schematic flowchart of a request authentication method provided by an embodiment of the present application;

[0033] Figure 4 is a schematic flowchart of another request authentication method provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0034] The embodiments of the present application will be described in detail below. The examples of the embodiments are shown in the drawings, where the same or similar reference numerals denote the same or similar elements or elements with the same or similar functions throughout. The embodiments described below with reference to the drawings are exemplary and are intended to explain the present application, and should not be construed as limiting the present application.

[0035] Currently, in a microservices architecture, authentication is carried out through a single gateway. Traffic is routed through the gateway to different back-end services. This gateway needs to handle all requests, such as being responsible for verifying the login status and permission verification, etc. The processing efficiency is low, the risk is high, and it makes it difficult to expand the application. Therefore, a business system and a request authentication method are needed to simplify the gateway function and improve efficiency by splitting the responsibilities of the single gateway.

[0036] The business system and the request authentication method proposed in this application are management permission schemes based on business domains. By dividing the gateway into a front-end gateway and a middle-tier gateway according to responsibilities, they are respectively responsible for the permission management of the front end and the middle tier, making the permission management more perfect, simplifying the functions of each gateway, and making it more convenient for expansion and management.

[0037] The following describes the business system and the request authentication method of the embodiments of this application with reference to the accompanying drawings.

[0038] Figure 1 It is a schematic diagram of the architecture of a business system provided by an embodiment of this application.

[0039] As Figure 1 shown, the business system is a multi-layer distributed architecture, which may include a front end, a front-end gateway, an application layer, a middle-tier gateway, and a middle-tier application. The front end accesses the application layer through the front-end gateway, and the application layer calls the middle-tier application through the middle-tier gateway.

[0040] Among them, the front end, that is, the user interface (UI), refers to the part of the system interface directly faced by the user, which can realize the interaction function between the user and the interface, such as clicking buttons, inputting data, page jumping, etc., receiving user operation instructions, passing them to the background for processing, and displaying the processed results.

[0041] Among them, the front-end gateway is an application programming interface (API) gateway. Unified access request authentication and authorization can be carried out through the front-end gateway to realize the interaction between the user interaction front end and the application layer. The front end and the application layer are the front desk, and the front end and the application layer are separated. The front end can only access the application layer through the front desk.

[0042] In some possible embodiments of this application, the front-end gateway can be used to verify the login status of the user included in the first token information according to the first token information sent by the front end, obtain the first verification result, and verify the first permission of the user to determine whether the user is allowed to access the application layer.

[0043] Among them, the first token information (token) refers to the information saved on the client page after the user logs in to the client, which is used to verify the user's identity. The first token information may include the user's login information, such as the login account, password, and login time, etc.

[0044] In the embodiments of this application, the user can interact with the front end through the communication network on the client. The front end requests the application layer, and the first token information can be carried each time the front end requests the application layer, so that the front desk gateway can determine the user who currently requests to access the application layer based on the first token information, and determine whether the current login status of the user is invalid, so as to complete the login status verification to obtain the first verification result. The first verification result may be logged in or not logged in, etc. Before request authentication, verifying the user's login status can avoid invalid authentication operations, prevent illegal access, and improve the efficiency and security of request authentication.

[0045] Among them, the first permission refers to the specific operation permissions or access levels granted to the user, which determines which services or resources the user can access.

[0046] In the embodiments of this application, the front desk gateway can verify the first permission of any user by accessing the user center to determine whether the first permission allows the any user to access the application layer it requests. The permissions of all users can be uniformly stored in the user center to ensure the unity of access permission verification for the business system.

[0047] Among them, the application layer is responsible for processing the user's application requests and responses. After receiving the request from the front end, it can determine which middle platform applications need to be called by arranging tasks for the request.

[0048] Among them, the middle platform gateway is also an Application Programming Interface (API) gateway. The middle platform gateway can perform authentication and authorization for system - to - system calls between the application layer and the middle and back ends (i.e., middle platform applications), and shield illegal system - to - system calls.

[0049] Among them, the middle platform applications are a series of reusable services, such as user management, payment processing, or search, etc. The middle platform applications can be services or resources provided in different systems. These middle platform applications can be shared by different business departments or applications in the front end, providing efficient and flexible support for the front end, coordinating communication between the front and back ends, as well as interaction between different systems, improving development efficiency and reducing maintenance costs.

[0050] By Figure 1It can be seen that the middle platform (including the middle platform gateway and middle platform applications) is located between the front end and the back end. The application layer is separated from the middle platform, and the front end can only access the application layer through the front end gateway, rather than directly accessing the middle platform. In this application, the middle platform is a business middle platform, which can integrate the common businesses of each project into a general service platform, such as payment, commodity management, marketing, users, search, trading center, etc. The business middle platform reduces duplicate development and improves the business response speed by abstracting and encapsulating these common businesses. The middle platform can decouple the complexity of the front and back ends, improving the scalability and maintainability of the system. By integrating and sharing common capabilities, the middle platform can quickly respond to the changing needs of the front end while maintaining the stability and security of the back end. This architecture model helps enterprises achieve rapid iteration and innovation of their businesses and improve their overall competitiveness.

[0051] In some possible embodiments of this application, the middle platform gateway can be used to verify the second permission of the application layer according to the second token information of the application layer to determine whether the application layer is allowed to call the middle platform application.

[0052] Among them, the second token information (token) refers to the information used to verify whether the application layer can call any middle platform application between systems. The second token information can be generated by the architecture management platform according to the application layer sending the request, the middle platform application requested to be called, and the request time, etc.

[0053] Among them, the second permission is the specific operation permission or access level granted to the application layer, which determines which services or resources the application layer can call. The middle platform gateway can verify the second permission of any application layer by accessing the authentication microservice to determine whether the second permission allows the any application layer to call the middle platform application it requests. The authentication microservice has the permission verification function for interface calls between systems.

[0054] In the embodiments of this application, after the application layer receives the request from the front end and performs task scheduling on the request, it can determine which middle platform applications are needed to process the request. Therefore, the application layer needs to carry the second token information and request to call these middle platform gateways through the middle platform gateway. Then, the middle platform gateway can verify the second permission of the application layer called by the current request through the authentication microservice. When the second permission allows the application layer to call the middle platform application it requests, the verification passes, and the middle platform gateway can route the call request to the middle platform application. Otherwise, the middle platform gateway rejects the call request of the application layer.

[0055] In this application, the interaction between the front end and the application layer conducts unified access request authentication and authorization through the front desk API gateway, which can shield illegal user requests. Moreover, between the application layer and the middle desk applications, authentication and authorization for inter-system calls can be carried out through the middle desk API gateway to shield illegal inter-system calls. Thus, different gateways can be used to handle the authentication tasks between different architecture layers, improving the accuracy of gateway authentication, and further enhancing the authentication efficiency and the security of the business system.

[0056] It should be noted that in Figure 1 , in the layered architecture of the business system, which is located above the front end, between the front end and the front desk gateway, and between the application layer and the middle desk gateway, a load balancer can also be included. The load balancer can distribute a large number of concurrent accesses or data flows to multiple node devices for separate processing, so as to reduce the user's waiting time for responses, expand the bandwidth of network devices and servers, and increase the throughput.

[0057] In addition, a reverse proxy can also be included above the front end. The reverse proxy is a proxy server model located between the client and the backend server, allowing requests to be forwarded to the backend server and responses to be returned to the client. The reverse proxy is an effective means to achieve load balancing.

[0058] It should be noted that in order to further refine the functions of the front desk gateway or the middle desk gateway, in this application, multiple business systems can be divided based on business domains. Each business domain can correspond to one or more business systems, and each business system adopts the Figure 1 multi-layer distributed architecture shown. Different business systems within the same business domain reuse the same set of front desk gateways and middle desk gateways, while the front desk gateways and middle desk gateways in different business systems in different business domains are different, enabling each front desk gateway and middle desk gateway to only be responsible for the authentication tasks of the systems within the corresponding business domain, and the request authentication efficiency is higher.

[0059] Optionally, multiple business domains can be determined according to the needs of the target business scenario.

[0060] For example, for the insurance business scenario, 16 business domains can be divided, namely consumer-oriented sales (i.e., c-end sales), enterprise-oriented sales (i.e., e-end sales), e-end mobile sales, external cooperation, customers, auto insurance underwriting, non-auto insurance underwriting, social insurance, agricultural insurance, inclusive finance, claims settlement, finance, risk control, comprehensive, public, and big data.

[0061] Then, based on multiple business domains, the business system is divided to obtain at least one business system within each business domain. After that, for each business domain, a set of front-end gateways and middle-tier gateways can be determined respectively, and this set of front-end gateways and middle-tier gateways are reused by at least one business system within the business domain.

[0062] For example, there are 3 business systems, namely business system 1, business system 2, and business system 3. Business system 1 and business system 3 belong to business domain A, and business system 2 belongs to business domain B. A set of front-end gateway a and middle-tier gateway a can be configured for business domain A, and a set of front-end gateway b and middle-tier gateway b can be configured for business domain B. Then, in the layered architecture of business system 1 and business system 3 as Figure 1 shown, the front-end gateways are all front-end gateway a, and the middle-tier gateways are all middle-tier gateway a. Different business systems within the same business domain reuse the same set of gateways. In the layered architecture of business system 2 as Figure 1 shown, the front-end gateway is front-end gateway b, and the middle-tier gateway is middle-tier gateway b. Then, different business systems within different business domains use different sets of gateways.

[0063] In the embodiments of the present application, by grouping business systems using business domains, multiple business systems within the same business domain reuse the same set of gateways, and business systems within different business domains use different gateways. The functions of the front-end gateways and middle-tier gateways can be further refined based on business domains, which is beneficial to improving the authentication accuracy and efficiency of each gateway.

[0064] Optionally, in the present application, the front-end gateways of multiple business domains are docked to the same user center. This user center can be used to obtain the first permissions of the user included in the first token information according to the first token information sent by any front-end gateway, and based on the first permissions, determine whether the user is allowed to access the second verification result of the application layer, and return the second verification result to any front-end gateway.

[0065] In the embodiments of the present application, the user center may contain the access permissions of all users. Therefore, after the user center receives the first token information sent by any front-end gateway, it can traverse the first permissions of the user included in the first token information among the access permissions of all users. Thus, based on the first permissions, it can be determined whether the user is allowed to access the requested application layer to obtain the second verification result. The second verification result may be allowed access or not allowed access. Then, the user center can return the generated second verification result to the any front-end gateway that sent the first token information. Furthermore, the front-end gateway can determine whether to route the access request sent by the front-end to the application layer according to the second verification result.

[0066] It should be noted that after the user center completes the permission verification for a user's request to access a certain application layer, the verification result can be saved in the user center, so that when the next verification is performed on the request of the same user to access the same application layer (which may be a verification process initiated by the front-end gateway in other business domains), the verification result can be directly obtained, improving the authentication efficiency.

[0067] In addition, the middle-tier gateways of multiple business domains are connected to the same authentication service. This authentication service can be used to obtain the second permissions of the application layer included in the second token information according to the second token information sent by any middle-tier gateway, and based on the second permissions, determine the third verification result of whether the application layer is allowed to access the middle-tier application, and return the third verification result to any middle-tier gateway.

[0068] In the embodiments of the present application, the authentication service may include the call permissions of all application layers to the middle-tier application. Therefore, after the authentication service receives the second token information sent by any middle-tier gateway, it can traverse the second permissions of the application layer included in the second token information among the call permissions of all application layers to the middle-tier application. Thus, based on the second permissions, it can be determined whether the application layer is allowed to call the requested middle-tier application, and the third verification result is obtained. The third verification result may be allowed to call or not allowed to call. Then the authentication service can return the generated third verification result to the middle-tier gateway that sent the second token information. Furthermore, the middle-tier gateway can determine whether to route the call request sent by the application layer to the corresponding middle-tier application according to the third verification result.

[0069] It should be noted that after the authentication service completes the permission verification for a request of a certain application layer to call a certain middle-tier application, the verification result can be saved in the authentication service, so that when the next verification is performed on the request of the same application layer to call the same middle-tier application (which may be a verification process initiated by the middle-tier gateway in other business domains), the verification result can be directly obtained, improving the authentication efficiency.

[0070] In the embodiments of the present application, the relationship between business systems in different business domains can be as Figure 2 shown Figure 2 is a schematic architecture diagram of business systems belonging to different business domains provided by the embodiments of the present application.

[0071] In Figure 2 it, Domain A and Domain B are two different business domains. The business systems corresponding to Domain A or Domain B all follow as Figure 1The multi-layer distributed architecture shown in the figure includes a front-end gateway and a middle-end gateway. The two front-end gateways corresponding to domain A and domain B are connected to the same user center, which can ensure that no matter which domain the user accesses, the front-end gateway can verify the user's permissions, ensuring the uniformity of user permissions. The two middle-end gateways corresponding to domain A and domain B are connected to the same set of authentication services, so that different middle-end gateways can uniformly manage the calling permissions between systems, ensuring the uniformity and reliability of the permission verification of the middle-end gateways when performing authentication.

[0072] It should be noted that in Figure 2 In the figure, only two business areas, area A and area B, are used for exemplary description. In a specific embodiment, the number of gateway data connected to the user center and the authentication service is not necessarily two, but may be more.

[0073] In this application, Figure 1 and Figure 2 The front-end gateway and middle-end gateway provided in are used to implement request authentication in different links. The request authentication process of the front-end gateway and the middle-end gateway are explained separately in conjunction with the attached drawings below.

[0074] Figure 3 A flowchart of a method for requesting authentication provided in an embodiment of the present application is shown below. Figure 3 The request authentication method in is executed by the front-end gateway.

[0075] like Figure 3 As shown, the request authentication method includes the following steps:

[0076] Step 301, in response to a front-end access request to a target application layer, obtain first token information of a user included in the access request.

[0077] In the embodiment of the present application, the business system may include multiple application layers, each of which may implement different business logic and functions, so it is necessary to specify the target application layer that currently needs to be accessed in the access request.

[0078] In the embodiment of the present application, in order to ensure security, users must log in through the portal to access the business system. The user first needs to log in once on the portal. The portal can support login methods such as account password, mobile phone verification code, face scanning, or security order, and login authentication is unified through the user center or other services that can perform login authentication. After the user successfully logs in, the login information such as login time and account number can be saved as the first token information on the client page, and then the user can interact with the front end, and the front end requests the application layer to implement the user's operation. The first token information can be placed in the message header of the access request to the target application layer for login status verification and access permission verification.

[0079] It should be noted that the client used by the user when interacting with the front end can be any electronic device such as a mobile phone or a computer, or it can also be an external system.

[0080] In the embodiments of the present application, each application layer can call the corresponding business logic for processing according to the user's request. The business logic may involve operations such as data verification, calculation, or conversion, and these operations may be implemented by services provided by different systems or applications. Therefore, in order to ensure the security of access, the access permissions of the user and the application layer should be verified. Only when the permission verification passes, the front end is allowed to access the target application layer.

[0081] Step 302: According to the first token information, verify the login status of the user to obtain a first verification result.

[0082] In the embodiments of the present application, after the front desk gateway obtains the first token information in the current access request, the front desk gateway can first verify the login status of the user in the client according to the first token information to obtain a first verification result. The first verification result may be that the user is currently in the logged-in state, or the user's login status has expired, etc. It can ensure the security of the user's identity during application layer access, avoid invalid requests, and maintain the stability of the application layer.

[0083] In some embodiments, when the front desk gateway performs the login status verification, it can first determine the time interval between the login time in the first token information and the current time. Then, when the time interval is less than the threshold, it is determined that the user's login status is logged in to obtain the first verification result.

[0084] Among them, the threshold is the effective time for maintaining the login status after the user logs in, and it can be set according to the security requirements.

[0085] In the embodiments of the present application, the user's login time can be determined in the first token information, and the difference between the login time and the current time is calculated to obtain the time interval since the last login. When the time interval is less than the threshold, it can be determined that the user's last login has not expired and is still in the logged-in state. Then, the first verification result obtained by the front desk gateway is that the user who currently requests to access the target application layer is in the logged-in state. At this time, verifying whether the user has the permission to access the target application layer can reduce the resources wasted by invalid authentication.

[0086] In the embodiments of the present application, when the time interval between the login time and the current time is greater than or equal to the threshold, the first verification result is that the current user is not logged in, or the user's login operation has expired. At this time, continuing to authenticate the user in the first token information may waste computing resources.

[0087] It should be noted that in the embodiments of the present application, it is also possible that when the time interval between the login time in the first token information and the current time is less than the threshold, the user actively logs out of the login state on the client. In this case, the obtained first verification result should also be that the current user is not logged in.

[0088] Step 303, when the first verification result is logged in, obtain a second verification result on whether the user is allowed to access the target application layer.

[0089] Among them, the second verification result may be that the currently logged-in user has the permission to access the target application layer, or it may be that the currently logged-in user does not have the permission to access the target application layer.

[0090] In the embodiments of the present application, when the front-end gateway performs access permission verification, it can determine the information of the user who requests to access the target application layer in the current client according to the first token information, such as the account number, mobile phone number, etc., to query whether the user has the permission to access the target application layer and obtain the second verification result. For example, the verification result can be obtained by querying the user permissions in the user center that contains the access permissions of all users.

[0091] In some embodiments, the front-end gateway can send the target application layer and user identifier corresponding to the access request to the user center to obtain the second verification result returned by the user center.

[0092] In the embodiments of the present application, the user center can find the first permission corresponding to it, that is, all the permissions of the user, according to the information that can uniquely identify the user in the first token information, such as the account number. Then, further query the first target permission in the first permission. The first target permission indicates that the user is allowed to access the target application layer. When the first permission contains the first target permission, the second verification result is allowed to access. On the contrary, when the first permission does not contain the first target permission, the second verification result is not allowed to access, so as to ensure that the user has the correct access permission and maintain the security and stability of the application layer access. After that, the user center can return the generated second verification result to the front-end gateway to complete the authentication of the interaction between the front end and the application layer.

[0093] Step 304, when the second verification result is allowed to access, process the access request.

[0094] In the embodiments of the present application, when the second verification result is allowed to access, the access request can be routed to the target application layer, so that the target application layer further performs task scheduling according to the access request.

[0095] In this embodiment, the front-end gateway first responds to the access request of the front-end to the target application layer, obtains the first token information of the user included in the access request, and then, according to the first token information, sequentially verifies the login status of the user corresponding to the first token information and the access permission of the user to the target application layer. When the user is in the logged-in state and the user has the permission to access the target application layer, the access request is allowed. This request authentication method, by setting up a front-end gateway to handle the authentication tasks between the front-end and the application layer, ensures the security of the business system. The front-end gateway does not need to handle the request authentication between other levels, and its functions are more streamlined and centralized, making it easier to expand and manage the services in the business system.

[0096] This embodiment provides another request authentication method. Figure 4 It is a schematic flow diagram of a request authentication method provided by an embodiment of the present application. Figure 4 The request authentication method in [diagram] is executed by the middle-tier gateway.

[0097] As Figure 4 shown, the request authentication method may include the following steps:

[0098] Step 401, in response to the call request of the target application layer to the target middle-tier application, obtain the second token information included in the call request.

[0099] In an embodiment of the present application, the target application layer can be orchestrated into corresponding business logics according to user interactions. The business logics may involve operations such as data verification, calculation, or conversion, and these operations can be implemented by one or more middle-tier applications. These one or more middle-tier applications are the target middle-tier applications that the application layer needs to call. Therefore, the middle-tier gateway can receive the call request of the target application layer to the target middle-tier application. The call request may include the second token information generated by the architecture management platform. The second token information is a credential for authenticating the application layer. Thus, between the application layer and the mid-back end (i.e., the middle-tier application), the second token information can be used for authentication of calls between different systems to ensure the security of system calls.

[0100] Step 402, according to the second token information, obtain the third verification result of whether the target application layer is allowed to call the target middle-tier application.

[0101] In an embodiment of the present application, the middle-tier gateway can use an authentication microservice with the permission verification function for system interface calls to verify whether the target application layer has the permission to call the target middle-tier application, and obtain the third verification result.

[0102] In some embodiments, the middle-tier gateway can send the second token information to the authentication service and obtain the third verification result returned by the authentication service.

[0103] In the embodiments of the present application, the authentication service may search for the corresponding second permissions according to the information in the second token information that can uniquely identify the application layer, such as the identifier of the application layer, etc., that is, all the permissions corresponding to the middle platform applications that the application layer can call. Then, the second target permission is further queried in the second permissions, that is, it is determined whether the target middle platform application is included in all the middle platform applications that the application layer can call. In the case of inclusion, it can be determined that the second target permission is included in the second permissions, and the third verification result is that the target application layer is allowed to call the target middle platform application. On the contrary, when the target middle platform application is not included in all the middle platform applications that the application layer can call, the third verification result is that the target application layer is not allowed to call the target middle platform application. After that, the authentication service may return the generated third verification result to the middle platform gateway to complete the authentication of the interaction between the application layer and the middle platform application.

[0104] Step 403, when the third verification result is allowed to call, process the call request.

[0105] In the embodiments of the present application, when the third verification result is allowed to call, the middle platform gateway may route the call request to the service provider (i.e., the target middle platform application) to complete the processing of the call request.

[0106] In this embodiment, the middle platform gateway first responds to the call request of the target application layer for the target middle platform application, obtains the second token information included in the call request, and then verifies the call permission of the target application layer for the target middle platform application according to the second token information. When the verification result is allowed to call, the corresponding middle platform application of the call request. This request authentication method, by setting up a middle platform gateway to handle the authentication task between the application layer and the middle platform application, ensures the security of system - to - system calls. The middle platform gateway does not need to handle the request authentication between other levels, and its functions are more streamlined and concentrated, making it easier to expand and manage services in the business system.

[0107] To implement the above - mentioned embodiments, the present application also proposes an electronic device, including: a processor, and a memory communicatively connected to the processor; the memory stores computer - executable instructions; the processor executes the computer - executable instructions stored in the memory to implement the method provided in the foregoing embodiments.

[0108] To implement the above - mentioned embodiments, the present application also proposes a computer - readable storage medium, in which computer - executable instructions are stored, and when the computer - executable instructions are executed by a processor, they are used to implement the method provided in the foregoing embodiments.

[0109] To implement the above - mentioned embodiments, the present application also proposes a computer program product, including a computer program, and when the computer program is executed by a processor, it implements the method provided in the foregoing embodiments.

[0110] The collection, storage, use, processing, transmission, provision, and disclosure of the user's personal information involved in this application all comply with the provisions of relevant laws and regulations and do not violate public order and good customs.

[0111] It should be noted that personal information from users should be collected for legal and reasonable purposes and should not be shared or sold outside of these legal uses. In addition, such collection / sharing should be carried out after obtaining the informed consent of the user, including but not limited to notifying the user to read the user agreement / user notice and signing an agreement / authorization that includes authorizing relevant user information before the user uses this function. In addition, any necessary steps should be taken to protect and safeguard access to such personal information data and ensure that others with access to the personal information data comply with their privacy policies and procedures.

[0112] This application is expected to provide an implementation plan for users to selectively block the use or access of personal information data. That is, this disclosure is expected to provide hardware and / or software to prevent or block access to such personal information data. Once the personal information data is no longer needed, the risk can be minimized by restricting data collection and deleting the data. In addition, when applicable, personal identifiers are removed from such personal information to protect the privacy of the user.

[0113] In the description of the foregoing embodiments, the descriptions referring to terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of this application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0114] In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one of such features. In the description of this application, "a plurality" means at least two, such as two, three, etc., unless otherwise specifically defined.

[0115] Any process or method description represented in a flowchart or otherwise described herein can be understood to represent a module, segment, or portion of code including one or more executable instructions for implementing a customized logic function or process, and the scope of the preferred embodiments of the present application includes additional implementations, where functions can be executed in a substantially simultaneous manner or in a reverse order according to the functions involved, rather than in the order shown or discussed, which should be understood by those skilled in the art to which the embodiments of the present application pertain.

[0116] The logic and / or steps represented in a flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing a logical function, and can be specifically implemented in any computer-readable medium for use by an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other systems that can fetch and execute instructions from the instruction execution system, apparatus, or device), or in conjunction with such instruction execution systems, apparatuses, or devices. For the purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (non-exhaustive list) of computer-readable media include the following: an electrical connection portion having one or more wirings (electronic device), a portable computer diskette (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium can even be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpretation, or other appropriate processing as necessary, and then stored in a computer memory.

[0117] It should be understood that various parts of the present application can be implemented using hardware, software, firmware, or combinations thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one or a combination of the following techniques well known in the art can be used: discrete logic circuits having logic gate circuits for implementing logical functions on data signals, application specific integrated circuits having appropriate combinational logic gate circuits, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

[0118] Those of ordinary skill in the art can understand that all or part of the steps carried out in implementing the above-mentioned embodiment methods can be completed by instructing relevant hardware through a program, and the said program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.

[0119] In addition, in each of the embodiments of the present application, each functional unit can be integrated in a processing module, can also exist physically separately for each unit, or two or more units can be integrated in one module. The above-mentioned integrated module can be implemented in the form of hardware, or can be implemented in the form of a software functional module. When the above-mentioned integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0120] The storage medium mentioned above can be a read-only memory, a magnetic disk, an optical disc, etc. Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and should not be construed as limiting the present application. Those of ordinary skill in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present application.

Claims

1. A business system, characterized in that: The system comprises: Front-end, front-end gateway, application layer, middle-end gateway and middle-end application, wherein the front-end accesses the application layer through the front-end gateway, and the application layer calls the middle-end application through the middle-end gateway; The front-end gateway is used to verify the login status of the user included in the first token information according to the first token information sent by the front-end, obtain a first verification result, and verify the first permission of the user to determine whether the user is allowed to access the application layer; The middle platform gateway is used to verify the second permission of the application layer according to the second token information of the application layer to determine whether the application layer is allowed to call the middle platform application.

2. The system according to claim 1, characterized in that Also includes: Determine multiple business areas based on the needs of the target business scenarios; Based on the multiple business fields, the business systems are divided to obtain at least one business system in each of the business fields; For each of the business domains, a group of front-end gateways and middle-end gateways are determined respectively, and the group of front-end gateways and middle-end gateways are reused by at least one business system in the business domain.

3. The system according to claim 2, characterized in that Also includes: The front-end gateways of the multiple business areas are connected to the same user center, wherein the user center contains access rights of all users; The user center is used to obtain the first permission of the user contained in the first token information sent by any front-end gateway, and based on the first permission, determine whether the user is allowed to access the second verification result of the application layer, and return the second verification result to any front-end gateway.

4. The system according to claim 2, characterized in that Also includes: The middle-end gateways of the multiple business areas are connected to the same authentication service, wherein the authentication service includes the calling permissions of all application layers; The authentication service is used to obtain the second permission of the application layer contained in the second token information sent by any middle station gateway, and based on the second permission, determine the third verification result of whether the application layer is allowed to access the middle station application, and return the third verification result to any middle station gateway.

5. A method for requesting authentication, characterized in that: Executed by the front-end gateway, the method includes: In response to the front-end access request to the target application layer, obtaining the first token information of the user included in the access request; Verify the user's login status according to the first token information to obtain a first verification result; When the first verification result is that the user is logging in, obtaining a second verification result of whether the user is allowed to access the target application layer; When the second verification result is that access is allowed, the access request is processed.

6. The method according to claim 5, characterized in that The first token information includes the login time of the user, and the verifying the login status of the user according to the first token information to obtain a first verification result includes: Determine the time interval between the login time in the first token information and the current time; When the time interval is less than the threshold, the user's login status is determined to be logged in as a first verification result.

7. The method according to claim 5, characterized in that The obtaining a second verification result of whether the user is allowed to access the target application layer includes: Sending the target application layer and user identification corresponding to the access request to the user center; Obtain the second verification result returned by the user center.

8. A method for requesting authentication, characterized in that: Executed by the middle platform gateway, the method includes: In response to a call request from the target application layer to the target middle platform application, obtaining second token information included in the call request; Obtaining, according to the second token information, a third verification result of whether the target application layer is allowed to call the target middle platform application; When the third verification result indicates that the call is allowed, the call request is processed.

9. The method according to claim 8, characterized in that The obtaining, according to the second token information, a third verification result of whether the target application layer is allowed to call the target middle platform application includes: The second token information is sent to the authentication service, and a third verification result is obtained from the authentication service.

10. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the authentication request method according to any one of claims 5 to 9.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the authentication request method according to any one of claims 5 to 9.

12. A computer program product, characterized in that It comprises a computer program, which, when executed by a processor, implements the request authentication method described in any one of claims 5 to 9.

Images