CN115801476A

CN115801476A - Verification method and device for application request

Info

Publication number: CN115801476A
Application number: CN202310111740.1A
Authority: CN
Inventors: 宋卫卫; 颜挺进; 何支军; 焦振海; 钱晨笛; 陈林博; 李乔
Original assignee: China Securities Depository And Clearing Corp ltd
Current assignee: China Securities Depository And Clearing Corp ltd
Priority date: 2023-02-09
Filing date: 2023-02-09
Publication date: 2023-03-14
Anticipated expiration: 2043-02-09
Also published as: CN115801476B

Abstract

The invention discloses a verification method and a verification device for an application request, and relates to the technical field of data security protection. The specific implementation mode of the method comprises the following steps: receiving access requests of one or more applications; analyzing the request url, determining the request type and the application type of the access request, and judging whether the access request meets the verification requirement or not according to the request type, the application type and a preset list database; if so, verifying the token validity period and the token authority of the token ID carried by the request url by using a preset token cache database, and determining the verification result of the access request; and in the case that the verification result is verification failure, rejecting the access request. According to the implementation mode, the global filter is deployed to the bottom layer of the application server, different verification modes are adopted according to the request url, the application request is subjected to security verification, system leaks caused by the fact that the application request bypasses security filtering and great threats are brought to system security are prevented, and the security of the system is greatly improved.

Description

Verification method and device for application request

Technical Field

The invention relates to the technical field of data security protection, in particular to a verification method and device of an application request.

Background

The distributed micro-service architecture is a service architecture which divides a system, refines the system into a plurality of micro-services which can realize module functions of a tiny unit, and manages the plurality of micro-services in a unified manner so as to complete various system functions. Typically including a server supporting the underlying service, one or more middleware, one or more applications, etc.

When the existing distributed micro-service architecture is used for safety protection, a safety service filter is usually constructed and is deployed as a middleware; alternatively, a security module is separately developed in each application to secure various access requests of the application.

In the process of implementing the invention, the inventor finds that at least the following problems exist in the prior art:

on one hand, because the existing security service filter belongs to an application level filter and is level to each application, only the security problem shared by each application can be simply protected, and the security characteristics of each application cannot be coped with, the application request can bypass the security service filter for access; on the other hand, the time, labor, test, post-maintenance and other costs for independently developing the safety protection module in each application are too high, and some applications may not directly perform safety logic in order to save the cost, which brings great vulnerability to the system safety and threatens the system safety.

Disclosure of Invention

In view of this, embodiments of the present invention provide a method and an apparatus for verifying an application request, which can deploy a global filter to an application server bottom layer, and adopt different verification manners for different application requests to protect system security, prevent an application request from bypassing security filtering to cause a system bug and bring a great threat to system security, greatly improve system security, and ensure safe and stable operation of a system.

Furthermore, by adjusting the verification mode of the access request, the filter directly verifies the authority of the access request through the token ID, and compared with the problems that the existing access request needs to carry token and other information, the request content is too much, the response speed is slowed, and the like, the access request can be verified only by carrying the token ID, so that the response speed of the request is greatly improved, and the response performance of the server is ensured.

To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided an application request authentication method, including:

the method is executed by a security filter deployed in a server of a distributed microservice architecture, and comprises the following steps:

receiving access requests of one or more applications; wherein the access request comprises a request url;

analyzing the request url, determining the request type and the application type of the access request, and judging whether the access request meets the verification requirement according to the request type, the application type and a preset list database;

if so, verifying the token validity period and the token authority of the token ID carried by the request url by using a preset token cache database, and determining the verification result of the access request;

and if the verification result is verification failure, rejecting the access request.

Optionally, the request type of the access request includes a frame internal request, the application type includes an entry application and a non-entry application, and the list database includes an entry application url white list and a service subscription white list; the judging whether the access request meets the verification requirement according to a preset list database and the request type comprises the following steps:

judging whether the request type of the access request is the frame internal request or not;

if not, determining whether the application type of the access request is the portal application;

and under the condition that the application type of the access request is the portal application, determining whether the access request meets the verification requirement or not according to the portal application url white list, the service subscription white list and the request type.

Optionally, the requesting url further includes a request function identifier, the request type of the access request further includes a background service request and a foreground service request, and determining whether the access request meets a verification requirement according to the request type, the portal application url whitelist and the service subscription whitelist includes:

determining whether a request url of the access request belongs to the portal application url whitelist and whether the application name and the request function identifier belong to the service subscription whitelist;

if not, judging whether the request type of the access request is the foreground service request or the background service request;

and under the condition that the request type of the access request is a foreground service request or a background service request, determining that the access request meets the verification requirement.

Optionally, the request url further includes an application name, and the list database further includes a review application white list; before the determining whether the request type of the access request is the framework internal request, the method further includes:

and comparing the application name with the review application white list, searching whether the application name belongs to the review application white list, and if not, executing the judgment whether the request type of the access request is the request in the framework.

Optionally, the list database further includes a static resource white list; before the determining whether the request url of the access request belongs to the portal application url whitelist, further comprising:

and determining whether the request function identifier belongs to the static resource white list, and if not, executing the step of determining whether the request url of the access request belongs to the portal application url white list.

Optionally, the verifying the token validity period and the token authority of the token ID by using a preset token cache database, and determining the verification result of the access request includes:

taking the token ID as a query key, searching the token cache database, and determining a target validity period corresponding to the token ID; wherein, the token IDs of different token types correspond to the same or different target validity periods;

judging whether the token ID is within the target validity period or not;

if so, determining that the verification result of the access request is verification success.

Optionally, the determining that the verification result of the access request is verification success further includes:

taking the token ID as a query key, searching the token cache database, and determining a target authority list corresponding to the token ID; the token IDs of different token types correspond to the same or different target authority lists;

judging whether the authority requested by the access request belongs to the target authority list or not;

and if the token ID is within the target validity period and the authority requested by the access request belongs to the target authority list, determining that the verification result is verification success.

Optionally, the token types include an identity token, a service token and a user token.

Optionally, the method further comprises:

when any one of the following situations occurs, forwarding the access request to a target service corresponding to the request function identifier, receiving a processing result returned by the target service, and sending the processing result to an application corresponding to the access request:

the request type of the access request is the frame internal request, the request url of the access request belongs to the portal application url white list, the application name belongs to the review application white list, and the request function identifier belongs to the static resource white list.

According to still another aspect of the embodiments of the present invention, there is provided an apparatus for verifying an application request, including:

the device comprises a receiving module, a processing module and a processing module, wherein the receiving module is used for receiving access requests of one or more applications; wherein the access request comprises a request url;

the judging module is used for analyzing the request url, determining the request type and the application type of the access request, and judging whether the access request meets the verification requirement according to the request type, the application type and a preset list database;

the verification module is used for verifying the token validity period and the token authority of the token ID carried by the request url by utilizing a preset token cache database if the access request url is the access request url, and determining the verification result of the access request;

and the response module is used for refusing the access request under the condition that the verification result is verification failure.

According to another aspect of an embodiment of the present invention, there is provided an electronic device applying verification of a request, including:

one or more processors;

a storage device for storing one or more programs,

when the one or more programs are executed by the one or more processors, the one or more processors implement the method for verifying the application request provided by the present invention.

According to still another aspect of embodiments of the present invention, there is provided a computer-readable medium on which a computer program is stored, the program, when executed by a processor, implementing the method for verifying an application request provided by the present invention.

One embodiment of the above invention has the following advantages or benefits: the request url of the access request is analyzed, and whether the access request meets the verification requirement or not is judged according to the request type, the application type and a preset list database; under the condition of meeting the verification requirement, verifying the token validity period and the token permission of the token ID carried by the request url by utilizing a preset token cache database, and determining the technical means of the verification result of the access request, so that the technical means that an application-level filter can only simply protect the common safety problem of each application and cannot deal with the safety characteristics of each application per se is overcome, and the application request can possibly bypass a safety service filter for access; the time of developing the safety protection module alone in each application, manpower, test, cost such as later maintenance are too high, some applications may not directly do the safety logic in order to save the cost, bring very big leak for system security, threaten the technical problem of system security, and then reach and to deploy the global filter to the application server bottom, take different verification methods to different application requests, in order to protect system security, prevent that the application request from walking around safety filter and leading to the system leak, bring very big threat for system security, the security of system has been improved greatly, the technological effect of system safety and stability operation is guaranteed.

Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.

Drawings

The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:

fig. 1 is a schematic diagram of a main flow of an authentication method of an application request according to an embodiment of the present invention;

FIG. 2 is a diagram illustrating a user invoking a global filter through a global filter API when using an application, according to an embodiment of the present invention;

fig. 3 is a schematic diagram of a main flow of a method for determining whether an access request meets an authentication requirement according to an embodiment of the present invention;

fig. 4 is a schematic diagram of a main flow of a verification method of session token information of an access request according to an embodiment of the present invention;

FIG. 5 is a schematic diagram of the main modules of an authentication device of an application request according to an embodiment of the present invention;

FIG. 6 illustrates an exemplary system architecture diagram of an application request authentication method or application request authentication device suitable for application to embodiments of the present invention;

fig. 7 is a schematic block diagram of a computer system suitable for use in implementing a terminal device or server according to an embodiment of the present invention.

Detailed Description

Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Enterprise application integration: enterprise Application Integration, referred to as EAI, is a set of applications and Application standards that can be shared within an Enterprise or even among multiple enterprises.

BPM: business Process Management, business Process Management.

Fig. 1 is a schematic diagram of a main flow of an authentication method for an application request according to an embodiment of the present invention, and as shown in fig. 1, the authentication method for an application request of the present invention includes the following steps:

step S101, receiving access requests of one or more applications; wherein the access request comprises a request url

In the embodiment of the invention, the verification method of the application request is applied to a self-developed Chinese settlement SCAP cloud platform and is executed by a global security filter (hereinafter referred to as a global filter) deployed on a server of the Chinese settlement SCAP cloud platform; the Chinese settlement SCAP cloud platform adopts a jboss server and a ws server, a global filter is loaded by default when the jboss environment is customized, and the global filter is deployed on a server of a monitoring domain in the ws environment.

The China settlement SCAP cloud platform adopts a distributed micro-service architecture, inter-system communication and load balance are carried out through a self-researched SCAP service bus, and a global filter deployed on a China settlement SCAP cloud platform server carries out safety control on authorization and authentication of resource access requests based on the distributed environment, so that the overall safety of the system is ensured and improved, and the rapid and stable development of system services is supported.

In the embodiment of the present invention, the access request includes a request url, and the request url includes an application name, a request type, a task type, an application type, a service domain, a request function identifier, a request function parameter, a token ID, and the like of the access request. The request url is described in a Restful mode, that is, the request url is in a Restful style and is formed by splicing five service elements (the service refers to a minimum logic unit which is triggered from a user perspective and can be accessed to realize a corresponding request function). Specifically, the method comprises the following steps:

the Chinese settlement SCAP cloud platform can provide SCAP service for users, and the SCAP service comprises 5 key elements, namely, five service elements: (1) service domain: serviceDomain, e.g., shanghai division, headquarters, etc.; (2) service mode: serviceMode, such as foreground service, background service, internal service; (3) service name: the serviceName is a primary service name and is classified from the application perspective; (4) module name: the moduleName is a secondary service name, classifies the primary service according to functions and belongs to a lower module of the primary service; (5) version number: version, e.g., 1.0.0.

In summary, the service five element refers to 5 elements for describing service information, and one service can be located through the service five element.

In the embodiment of the invention, services are classified according to the use scene of the SCAP service, wherein the services comprise internal services, background services and foreground services, and comprise application start-stop, service registration, service subscription, heartbeat detection, service polling and the like; background services are also external services registered by providers, the calling mode of the background services is interaction of background programs among applications, the background services are generally provided for the applications in an interface mode, and database operation and the like are common scenes; the foreground service is an external service registered by a provider, the calling mode of the foreground service is usually to complete request access through browser jump, common scenes comprise access services of a display interface and the like, most scenes comprise that a portal application accesses an internal application through a menu, and a scene of jumping from one internal web application to another internal application is also provided. For example, the request url of the access request for each service is shown in table 1 below:

TABLE 1

Taking the request url of the foreground service of the home page of the monitoring platform as an example, the five service elements are respectively: CSDCC-SH is a service domain; qtfw represents that the service mode is foreground service; SUMPMonitor is the service name; menuModuleProvider is the module name.

In the embodiment of the invention, the foreground service follows the service calling framework and finally displays the service content through the security authentication; background services need to follow a uniform service calling framework and a security authentication mechanism.

In the embodiment of the invention, the request types comprise a frame internal request, a background service request and a foreground service request; the application types include portal applications and non-portal applications. For example, the access request is initialized for a BPM task view page, and the request URL may be:

/gllywbpm/qtfw-nb/CSDCC-SH/gllywbpm/taskModule/showtask/showTaskInit?tokenId=e229f6afbac44da4a395c6864e892469；

wherein gllywbpm is an application name, i.e. a service name; qtfw represents that the request type is a foreground service request; showtask indicates that the task type is a view task.

Further, according to the application name, it may be determined whether the application type of the application corresponding to the access request is a portal application.

In the embodiment of the invention, the processing of each application access request is necessarily processed by the server through the bottom-layer server supporting various applications, and the global filter is implanted into the shared library of the server, so that each application is silently introduced and uses the global filter, that is, each application can automatically load the global filter after being started, and the application can take effect without additional configuration. Therefore, the global filter deployed in the server can be used for filtering each access request, so that the access requests of all applications are ensured to be subjected to security verification, the security of the system is greatly improved, and the safe and stable operation of the system is ensured. For example, the global filter may be in the form of an API interface, as shown in fig. 2, when the user uses the application, the global filter may be called through the global filter API, and the global filter may verify various access requests.

In the embodiment of the present invention, or the access request may include an application name, a service domain, a request type, a task type, a request function identifier, a request function parameter, and the like, and the service invocation framework locates the service provider according to the service five-factor, and assembles a complete request url by using the service domain, the request type, the application name, and the request function identifier, thereby performing subsequent determination. The process can also be called repackaging of the access request, mainly because of the consideration on the program structure, each element of the access request is firstly formatted and then repackaged, the use requirement of the subsequent program is met, and the subsequent program can directly use the repackaged access request.

And step S102, judging whether the access request meets the verification requirement according to the request type, the application type and a preset list database.

In the embodiment of the invention, the list database comprises a review application white list, a static resource white list, an entrance application url white list and a service subscription white list, and is used for judging whether the access request meets the verification requirement, if so, the step S103 is switched to, and the access request is verified by using the token ID; if the verification is not needed, the access request is directly forwarded and the like.

Further, the verification requirements comprise a first verification mode, a second verification mode and a third verification mode, the first verification mode and the third verification mode are used for verifying the token type and the token authority of the token ID carried by the request url, and the token type and the token authority verified by the first verification mode and the third verification mode are different; the second authentication method only needs to authenticate the token type of the token ID carried by the request url.

In the embodiment of the present invention, as shown in fig. 3, the method for determining whether an access request meets the verification requirement of the present invention includes the following steps:

step S301, comparing the application name with the review application white list.

In the embodiment of the invention, the review application white list comprises old applications which are not modified and have the request url standard which does not meet the description requirement of the restful mode, the old applications are reviewed by experts and are determined not to bring safety risk to the system, and the old applications are allowed to be temporarily brought into the review application white list for management and judgment, and after subsequent optimization and modification, if the old applications meet the restful style, the old applications can be removed from the review application white list.

Further, the application name determined by the request url is compared to the review application white list. For example, with request url of access request:

for example,/SUMPMonitor/qtfw-nb/CSDCC-SH/SumpMonitor/menuModuleProvider/showIndexFlowServlet, SUMPMonitor is compared with the review application white list.

Step S302, searching whether the application name belongs to the review application white list, and if so, turning to step S312; if not, go to step S303.

In the embodiment of the invention, the application white list is searched and reviewed according to the application name determined by the request url, and whether the application name is in the review application white list or not is determined. For example, according to the sumpmitor, the review application white list is searched to determine whether the sumpmitor is in the review application white list.

Step S303, judging whether the request type of the access request is the frame internal request, if so, turning to step S312; if not, go to step S304.

In the embodiment of the invention, under the condition that the application name does not belong to the review application white list, the request type of the access request is judged, and whether the request type of the access request is a frame internal request or not is determined. For example, SUMPMonitor does not belong to the review application white list.

Step S304, determining whether the request function identifier belongs to the static resource white list, if so, turning to step S312; if not, go to step S305.

In the embodiment of the present invention, the SCAP service further includes static resources, and since the applications of the SCAP platform are applications with separate front and back ends, the static resources generally refer to files deployed independently, such as html, css, js, and pictures, at the front end. For example, the request url of the static resource of the BPM workbench home page is: html; wherein, static resource indicates that the request function is identified as a static resource.

And under the condition that the request type of the access request is not the frame internal request, judging the request function identifier of the access request, and determining whether the request function identifier of the access request belongs to a static resource white list. For example, menuModuleProvider does not belong to the static resource white list.

Step S305, determining whether the application type of the access request is the portal application, if so, turning to step S306; if not, go to step S308.

In the embodiment of the present invention, the portal application is a portal application, including EAI, and the like, and due to the particularity of the functions (for example, user login, token generation, and the like), the user needs to access other specific services only after successfully logging in the portal application and obtaining the token, so that the portal application needs to be processed separately, and the portal application is different from the authentication information of the non-portal application.

Further, if the application type of the access request is a non-portal application, it indicates that the login by the portal application is successful, and the functions of the non-portal application are accessed, so go to step S308 to verify different token types and token permissions according to the type of the application request.

In the embodiment of the invention, under the condition that the request function identifier of the access request does not belong to the static resource white list, the application type of the access request is judged, and whether the application type of the access request is the portal application or not is determined. For example, sumpmitor is not a portal application.

Step S306, determining whether the request url of the access request belongs to the portal application url white list, if so, turning to step S312; if not, go to step S307.

In the embodiment of the invention, the establishment standard of the entrance application url white list is the request url related to entrance application login, and the token can be generated only after the request url meeting the entrance application url white list requirement is successfully logged in, so that subsequent conversation is carried out.

In the embodiment of the invention, under the condition that the application type of the access request is the portal application, the request url of the access request is judged, and whether the request url of the access request belongs to the portal application url white list is determined.

Step S307, determining whether the request url of the access request belongs to the entrance application url blacklist, if so, turning to step S313; if not, go to step S308.

In the embodiment of the present invention, as opposed to the portal application url white list, the portal application url blacklist includes a list of request urls that are not eligible for portal application login, and thus access requests of respective request urls belonging to the portal application url blacklist should be denied.

In the embodiment of the invention, under the condition that the request url of the access request does not belong to the portal application url white list, the request url of the access request is judged, and whether the request url of the access request belongs to the portal application url black list or not is determined.

Step S308, whether the application name and the request function identifier belong to the service subscription white list or not, if yes, the step S311 is switched to; if not, go to step S309.

In the embodiment of the present invention, the service subscription white list integrates various services subscribed by the EAI, and belongs to a function set of multiple applications, that is, each application function is integrated into the EAI in a menu manner, each application in the EAI is used as a service consumer to subscribe to various services in the service subscription white list, and according to an application name and a request function identifier of an access request, whether a function requested by the access request belongs to a service subscribed by the EAI can be located.

The integrated application service in the EAI is different from foreground service and background service, only identity authentication is needed, and authority authentication is not needed, so that if the application name and the request function identifier belong to a service subscription white list, the access request is authenticated by using a second authentication mode, the response speed of the access request can be greatly improved, and the system safety is ensured.

In the embodiment of the invention, under the condition that the request url of the access request does not belong to the portal application url white list or the portal application url black list, the service corresponding to the access request belongs to the second authentication mode, namely, the desired request function can be obtained only through identity authentication, namely, the token type of the access request is only required to be authenticated, and after the identity authentication is passed, each service in the service subscription white list can be enjoyed.

In the embodiment of the invention, under the condition that the request url of the access request does not belong to the entrance application url blacklist, the application name and the request function identifier of the access request are judged, and whether the application name and the request function identifier of the access request belong to the service subscription white list or not is determined.

Step S309, judging whether the request type of the access request is the background service request, if so, turning to step S311; if not, go to step S310.

In the embodiment of the invention, under the condition that the request function identifier of the access request does not belong to the service subscription white list, the request type of the access request is judged, and whether the request type of the access request is a background service request is determined.

Step S310, judging whether the request type of the access request is the foreground service request, if so, turning to step S311; if not, go to step S313.

In the embodiment of the invention, under the condition that the request type of the access request is not the background service request, the request type of the access request is judged, and whether the request type of the access request is the foreground service request or not is determined.

Step S311, determining that the access request meets the verification requirement.

In the embodiment of the invention, the access request is verified in a second verification mode under the condition that the request function identifier of the access request belongs to the service subscription white list.

In the embodiment of the present invention, when it is determined that the request type of the access request is the foreground service request according to step S310, the access request is verified in the first verification manner.

In the embodiment of the present invention, when it is determined that the request type of the access request is the background service request according to step S309, the access request is authenticated by using a third authentication method.

Step S312, determining that the access request does not need to be verified, forwarding the access request to a target service corresponding to the request function identifier, receiving a processing result returned by the target service, and sending the processing result to an application corresponding to the access request.

In the embodiment of the present invention, in a case where any one of the following occurs:

the application name belongs to a review application white list, the request type of the access request is a frame internal request, the request url of the access request belongs to an entrance application url white list, and the request function identifier belongs to a static resource white list, which means that the access request does not need to be verified and can be directly responded, so that the access request is forwarded to a target service corresponding to the access request, and a processing result returned by the target service is received and sent to the application corresponding to the access request. Wherein:

1. because the review application white list is an application which is reviewed by experts and does not bring safety risk to the system, the access request does not need to be verified when the application name is in the review application white list.

2. Because the intra-frame request is usually the basic service of the intra-frame application such as application start-stop, service registration, service subscription, heartbeat detection, service polling, and the like, when the request type of the access request is the intra-frame request, the operations such as service registration, heartbeat detection, and the like are directly performed, and the intra-frame request does not need to be verified, that is, when the request type of the access request is the intra-frame request, it means that the access request does not need to be verified.

Further, if necessary, the internal request of the framework can be verified, but similar to the service subscription white list, the second verification mode is adopted, and only the token type needs to be verified.

3. Because the request for accessing the static resource generally corresponds to the foreground service and is used for assembling the access page of the front end and the like, the access of the static resource is generally resource acquisition in the frame, and therefore, under the condition that the request function identifier of the access request indicates the static resource, the access request can be directly forwarded to the corresponding static resource service without verifying the access request, that is, when the request function identifier belongs to the static resource white list, the access request is indicated without verifying.

4. Because each request url of the portal application url white list is an access request meeting the login standard, the request url of the portal application url white list belongs to an access request capable of safely logging in, and can be directly forwarded to a login service for processing, and corresponding token information including a token type, a token authority and the like corresponding to a service which the request url wants to acquire is generated for the request according to the request function of the access request, namely, when the request url of the access request belongs to the portal application url white list, the access request does not need to be verified.

Step S313, rejecting the access request.

In the embodiment of the invention, the access request of the application is rejected under the condition that the request url of the access request is determined to belong to the entrance application url blacklist and/or the request type of the access request is determined not to belong to the background service request or the foreground service request.

In the embodiment of the invention, by the method for judging whether the access request meets the verification requirement, whether the access request meets the verification requirement can be judged according to a designed safety principle, wherein the judgment comprises whether the request type, the application name, the request function identifier, the application type, the url address and the like of the access request meet the requirements of a list database, the verification request type and the like, so that the subsequent differentiated verification on the safety of the access request is facilitated, the access safety of a system is ensured, and the safe operation of the system is ensured.

And step S103, if so, verifying the token type and the token authority of the token ID by using a preset token cache database, and determining the verification result of the access request.

In the embodiment of the present invention, the token cache database stores session token information (i.e., complete token) of each token ID, including userID, token ID, token generation time, random sequence number, token value after encryption and signature, and/or user authority list. And in the token cache database, the complete token corresponds to the token ID one by one, and during storage, the token ID is used as the key and the complete token is used as the value for storage.

In the embodiment of the invention, the token types comprise identity tokens, service tokens and user tokens, token information of different types of tokens is different, the token information is composed of a common token and a type token, the common token parameters of different types of tokens are the same, only parameter values are different, but the type tokens of different types of tokens have characteristics. Wherein the common token comprises:

token value: the token value is a character string obtained by splicing a token version, a validity period, a random serial number, an application name, a service object (including a service consumer and a service provider) and a service authority list by using '@' and taking an md5 value from a character string finished by 'endFlag', and encrypting the character string by using a private key provided by gas.

token ValidTime: namely token validity period, and token validity period obtained by combining token generation time, fixed time length and random time length. For example, the fixed time duration is 24 hours, and the random time duration is any value between 0 and 12 hours.

tokenVersion: i.e., token version number, the private key version number used to encrypt the token value.

And (4) nonce: i.e., random number, is uuid minus "-".

In the embodiment of the invention, the Chinese computing SCAP platform builds a unified safety mechanism based on the tokens, when a background service and a foreground service are called, different types of tokens are required to be carried respectively, the background service inside the framework is used for carrying the identity token in an interactive mode, the background service inside and outside the framework is used for carrying the service token in an interactive mode, and the foreground service is used for carrying the user token in an interactive mode. Wherein:

the identity token is used for realizing authority control of background service interaction inside the framework, and comprises the following steps: applications use the SCAP framework, such as services of R (registry) publishing to C (consumer), R heartbeat to P (provider), C subscribing to R, C polling to R, P probing to R heartbeat, P registering to R, P offloading to R, etc.;

the service token is used for realizing authority control of background service interaction inside and outside the framework, and comprises the following steps: c calls the service of P, etc.;

the user token is used for realizing the authority control of the user to access the foreground service, and comprises the following steps: the user accesses a foreground service through the EAI (e.g., EAI accesses a foreground service of the BPM), the application accesses a foreground (e.g., BPM accesses a foreground service of the entry review), and so on.

In the embodiment of the invention, the types of tokens of different types of tokens are mainly different from token extended objects, and the token extended objects, namely token ext, are used for acquiring the application information and the service authority of the tokens. Specifically, the method comprises the following steps:

the token extension object of the identity token comprises an application name, a service object (comprising a service consumer and a service provider) and a hash value set generated by five service elements of background services in a framework which is applied with authority to call;

the token extension object of the service token comprises an application name and a hash value set generated by five service elements of background services inside and outside a frame which is applied with authority to call;

the token extension object of the user token comprises a session id of a login user and a hash value set generated by five service elements of a foreground service which is called by the user with permission.

Further, the token cache database may be a Redis database to ensure query performance and response speed of the system.

In the embodiment of the present invention, as shown in fig. 4, the method for verifying the session token information of the access request of the present invention includes the following steps:

step S401, obtaining the verification mode of the access request.

Step S402, when the authentication method of the access request is the first authentication method or the third authentication method, go to step S403; if the authentication method of the access request is the second authentication method, the process proceeds to step S407.

In this embodiment of the present invention, determining, according to the determination result in step S311, an authentication manner of the access request meeting the authentication requirement includes: requesting the function identifier to belong to a service subscription white list as a second verification mode; the request type is a foreground service request and is a first verification mode; the request type is the third authentication mode of the background service request.

Step S403, using the token ID of the request url as a query key, searching the token cache database, and determining a target validity period and a target permission list corresponding to the token ID.

In the embodiment of the invention, the access request from the portal application is forwarded to the login service for independent processing, so that the foreground service request, the background service request and the request function identifier correspond to each other

In the embodiment of the present invention, a foreground service request is usually sent by a user through a browser, that is, the foreground service is usually a user request, each user may configure different resource permissions, the user logs in a portal application and generates session token information, the session token information includes an encrypted permission list, and a global filter queries, according to a token ID, the session token information stored in a token cache database, and verifies whether a service requested to be accessed by a current access request is within a permission range (for example, whether a logged-in user has a permission to initiate the request/request a certain resource). The background service request usually comes from an application backend, that is, the background service is usually an application request, the SCAP platform defines a name and a password for each application, and the global filter queries the session token information stored in the token cache database according to the token ID to verify whether the service requested to be accessed by the current access request is within the authority range.

Further, the foreground service request and the background service request need to verify the token type, the token validity period, and the token permission of the request url, that is, the first verification manner and the third verification manner are the verification of the token validity period and the token permission of different token types.

In the embodiment of the present invention, the target validity periods corresponding to the token IDs of different token types may be the same or different, and the target permission lists corresponding to the token IDs of different token types may be the same or different, and may be set according to actual needs.

In the embodiment of the invention, the global filter takes the token ID of the request url as a query key, searches the token cache database and obtains the target validity period and the target permission list corresponding to the token ID.

Step S404, judging whether the token ID is in the target validity period and whether the token authority of the access request belongs to the target authority list, if so, turning to step S405; if not, go to step S406.

In the embodiment of the invention, the global filter judges whether the token ID is in the target validity period or not and whether the token authority of the access request belongs to the target authority list or not.

Step S405, determining that the verification result of the access request is verification success.

In the embodiment of the invention, for the first verification mode and the third verification mode, if the token ID is in the target validity period and the token authority of the access request belongs to the target authority list, the verification result is determined to be successful; for the second authentication mode, if the token ID is within the target validity period, the authentication result is determined to be successful.

In the embodiment of the invention, after the verification is successful, the verification passing identifier can be set in the request header of the access request, so that the subsequent process can directly determine the security of the access request according to the verification passing identifier, and further process the access request. For example, after the foreground service request is successfully verified, a qtfw verification passing identifier may be set in the request header of the access request, where the qtfw verification passing identifier is: authorsion = QTFW _ CGF _ SUCCESS.

Step S406, determining that the verification result of the access request is verification failure.

In the embodiment of the invention, for the first verification mode and the third verification mode, if the token ID is not in the target validity period, or the token authority of the access request does not belong to the target authority list, or both are not satisfied, the verification result is determined as verification failure; for the second authentication mode, if the token ID is not within the target validity period, the authentication result is determined to be authentication failure.

Step S407, using the token ID of the request url as a query key, searching the token cache database, and determining a target validity period corresponding to the token ID.

In the embodiment of the present invention, the second verification method needs to verify the token type and the token validity period of the request url, that is, the second verification method is the verification of the token validity period of the identity token.

In the embodiment of the invention, the global filter takes the token ID of the request url as the query key, searches the token cache database and obtains the target validity period corresponding to the token ID.

Step S408, judging whether the token ID is within the target validity period, if so, turning to step S405; if not, go to step S406.

In the embodiment of the invention, the global filter judges whether the token ID is in the target validity period.

In the embodiment of the invention, by the verification method of the session token information of the access request, the token validity period of the token ID and the token authority of the access request can be verified according to the type of the access request, so that the token of the access request is judged, whether the access request is safe or not is determined, the access request is respectively processed, the security of application access is greatly improved, and the safe operation of a system is ensured.

And step S104, refusing the access request under the condition that the verification result is verification failure.

In the embodiment of the invention, if the access request fails to be verified, the access request of the application is rejected; and if the verification result is that the verification is successful, forwarding the access request to the target service corresponding to the request url, so that the target service processes the access request.

In the embodiment of the invention, for background service interactive calling and foreground service calling inside and outside the frame, if the token ID is in the target validity period and the token authority of the access request belongs to the target authority list, the access request is determined to be safe, and the access request is processed. Specifically, the method comprises the following steps:

for foreground service calling, judging according to token ValidTime, validity period of token ID by user token and token authority of access request, respectively, and determining to respond to the access request by browser skip under the condition of access request security.

And for background service interactive calling inside and outside the framework, judging according to the token ValidTime, the service token validity period of the token ID and the token authority of the access request respectively, determining to respond to the access request under the condition of safety of the access request, and providing corresponding external calling service for the application.

In the embodiment of the present invention, or for background service interaction and inter-modulation inside the framework, if the token ID is within the target validity period, it is determined that the access request is safe, and the access request is processed. Specifically, the method comprises the following steps:

and for background service interactive calling in the framework, judging the validity period of the token ID according to the token ValidTime, responding to the access request under the condition of determining that the access request is safe, and providing corresponding internal calling service for the application.

In the embodiment of the invention, the access request of one or more applications is received; wherein the access request comprises a request url; analyzing the request url, determining the request type and the application type of the access request, and judging whether the access request meets the verification requirement according to the request type, the application type and a preset list database; if so, verifying the token validity period and the token authority of the token ID carried by the request url by using a preset token cache database, and determining the verification result of the access request; and if the verification result is that the verification fails, the access request is rejected, the global filter can be deployed to the bottom layer of the application server, different verification modes are adopted according to the type of the application request, and the application request is subjected to security verification so as to protect the system security, prevent the application request from bypassing the security filter to cause system loopholes and bring great threat to the system security, greatly improve the system security and ensure the safe and stable operation of the system.

Fig. 5 is a schematic diagram of main modules of an authentication apparatus for an application request according to an embodiment of the present invention, and as shown in fig. 5, an authentication apparatus 500 for an application request of the present invention includes:

a receiving module 501, configured to receive an access request of one or more applications; wherein the access request comprises a request url.

A determining module 502, configured to analyze the request url, determine a request type and an application type of the access request, and determine whether the access request meets a verification requirement according to the request type, the application type, and a preset list database.

And the verification module 503 is configured to verify the token validity period and the token permission of the token ID carried by the request url by using a preset token cache database, and determine a verification result of the access request if the request url is the access request.

A response module 504, configured to deny the access request if the verification result is that the verification fails.

In the embodiment of the invention, the global filter can be deployed to the bottom layer of the application server through modules such as the receiving module, the judging module, the verifying module and the response module, different verification modes are adopted for different application requests, so that the system safety is protected, system leaks caused by bypassing security filtering of the application requests are prevented, great threats are brought to the system safety, the system safety is greatly improved, and the safe and stable operation of the system is ensured.

Fig. 6 is a diagram illustrating an exemplary system architecture of an application request verification method or an application request verification apparatus suitable for application to the embodiment of the present invention, and as shown in fig. 6, the exemplary system architecture of the application request verification method or the application request verification apparatus according to the embodiment of the present invention includes:

as shown in fig. 6, the system architecture 600 may include

terminal devices

601, 602, 603, a network 604, and a server 605. The network 604 is used to provide a medium for communication links between the

terminal devices

601, 602, 603 and the server 105. Network 604 may include various types of connections, such as wire, wireless communication links, or fiber optic cables, to name a few.

A user may use the

terminal devices

601, 602, 603 to interact with the server 605 via the network 604 to receive or send messages or the like. Various communication client applications, such as a security application, a shopping application, a web browser application, a search application, an instant messaging tool, a mailbox client, social platform software, and the like, may be installed on the

terminal devices

601, 602, and 603.

The

terminal devices

601, 602, 603 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

The server 605 may be a server that provides various services, such as a background management server that supports a security-type website browsed by a user using the

terminal devices

601, 602, and 603. The backend management server may analyze and otherwise process the received data such as the access request, and feed back a processing result (for example, an access request authentication failure) to the

terminal device

601, 602, and 603.

It should be noted that the authentication method for the application request provided by the embodiment of the present invention is generally executed by the server 605, and accordingly, the authentication device for the application request is generally disposed in the server 605.

It should be understood that the number of terminal devices, networks, and servers in fig. 6 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Fig. 7 is a schematic structural diagram of a computer system suitable for implementing the terminal device or the server according to the embodiment of the present invention, and as shown in fig. 7, the computer system 700 of the terminal device or the server according to the embodiment of the present invention includes:

a Central Processing Unit (CPU) 701, which can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 702 or a program loaded from a storage section 708 into a Random Access Memory (RAM) 703. In the RAM703, various programs and data necessary for the operation of the system 700 are also stored. The CPU701, the ROM702, and the RAM703 are connected to each other via a bus 704. An input/output (I/O) interface 705 is also connected to bus 704.

The following components are connected to the I/O interface 705: an input portion 706 including a keyboard, a mouse, and the like; an output section 707 including components such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage section 708 including a hard disk and the like; and a communication section 709 including a network interface card such as a LAN card, a modem, or the like. The communication section 709 performs communication processing via a network such as the internet. A drive 710 is also connected to the I/O interface 705 as needed. A removable medium 711 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 710 as necessary, so that a computer program read out therefrom is mounted into the storage section 708 as necessary.

In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication section 709, and/or installed from the removable medium 711. The computer program performs the above-described functions defined in the system of the present invention when executed by the Central Processing Unit (CPU) 701.

It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor includes a receiving module, a determining module, a verifying module, and a responding module. For example, the verification module may be further described as a module that verifies the token validity period and the token authority of the token ID carried by the request url using a preset token cache database to determine the verification result of the access request.

As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not assembled into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise: receiving access requests of one or more applications; wherein the access request comprises a request url; analyzing the request url, determining the request type and the application type of the access request, and judging whether the access request meets the verification requirement according to the request type, the application type and a preset list database; if so, verifying the token validity period and the token authority of the token ID carried by the request url by using a preset token cache database, and determining the verification result of the access request; and if the verification result is verification failure, rejecting the access request.

According to the technical scheme of the embodiment of the invention, the global filter is deployed at the bottom layer of the application server (WAS, JBOSS), and the access request is verified in terms of token type, token validity period and token permission. The global filter embedded into the bottom layer of the application server is deeply fused with the application server, and various applications must automatically load the global filter to prevent the applications from bypassing security verification without doing security logic for laziness.

According to the technical scheme of the embodiment of the invention, the global security filter at the server level is utilized to carry out security verification in a shared library mode, wherein the security verification comprises identity verification (namely validity period verification) and authority verification. The method can be compatible with the verification of the background service of the new session token and the original service token, the verification of the internal calling authority of the framework and the like.

According to the technical scheme of the embodiment of the invention, the global filter can be deployed to the bottom layer of the application server, different verification modes are adopted for different application requests, so that the system safety is protected, system loopholes caused by bypassing the safety filter of the application requests are prevented, the system safety is greatly threatened, the system safety is greatly improved, and the safe and stable operation of the system is ensured.

The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for validating an application request, the method being performed by a security filter deployed in a server of a distributed microservice architecture, comprising:

2. The method of claim 1, wherein the request type of the access request comprises a framework internal request, wherein the application types comprise portal applications and non-portal applications, and wherein the roster database comprises a portal application url white list and a service subscription white list; the judging whether the access request meets the verification requirement according to a preset list database and the request type comprises the following steps:

judging whether the request type of the access request is the internal request of the framework;

3. The method of claim 2, wherein the request url further includes a request function identifier, wherein the request type of the access request further includes a background service request and a foreground service request, and wherein determining whether the access request meets the authentication requirement according to the request type, the portal application url whitelist, and the service subscription whitelist comprises:

determining whether a request url of the access request belongs to the portal application url whitelist and whether the application name and the request function identification belong to the service subscription whitelist;

4. The method of claim 3, wherein the request url further includes an application name, and wherein the list database further includes a review application whitelist; before the determining whether the request type of the access request is the framework internal request, the method further includes:

and comparing the application name with the review application white list, searching whether the application name belongs to the review application white list, and if not, executing the judgment whether the request type of the access request is the request in the frame.

5. The method of claim 3, wherein the list database further comprises a static resource white list; before the determining whether the request url of the access request belongs to the portal application url whitelist, further comprising:

6. The method of claim 1, wherein the verifying the token validity period and the token authority of the token ID by using a preset token cache database to determine the verification result of the access request comprises:

taking the token ID as a query key, searching the token cache database, and determining a target validity period corresponding to the token ID; the token IDs of different token types correspond to the same or different target validity periods;

judging whether the token ID is within the target validity period or not;

7. The method of claim 6, wherein the determining that the verification of the access request is successful further comprises:

using the token ID as a query key, searching the token cache database, and determining a target authority list corresponding to the token ID; the token IDs of different token types correspond to the same or different target authority lists;

8. The method according to claim 6 or 7, wherein the token types comprise identity tokens, service tokens and user tokens.

9. The method of any of claims 1 to 7, further comprising:

under the condition that any one of the following situations occurs, forwarding the access request to a target service corresponding to a request function identifier, receiving a processing result returned by the target service and sending the processing result to an application corresponding to the access request:

the request type of the access request is a frame internal request, the request url of the access request belongs to an entrance application url white list, the application name belongs to a review application white list, and the request function identification belongs to a static resource white list.

10. An apparatus for validating an application request, comprising:

11. An electronic device that applies a requested authentication, comprising:

one or more processors;

a storage device for storing one or more programs,

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method recited in any of claims 1-9.

12. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-9.