CN115801476B - Verification method and device for application request - Google Patents

Abstract

The invention discloses a verification method and device for application requests, and relates to the technical field of data security protection. The specific implementation mode of the method comprises the following steps: receiving an access request 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 according to the request type, the application type and a preset list database; if yes, 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 a verification result of the access request; and rejecting the access request when the verification result is verification failure. According to the embodiment, 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 loopholes caused by the application request bypassing security filtering are prevented, the system security is greatly threatened, and the security of the system is greatly improved.

Description

Verification method and device for application request

Technical Field

The present invention relates to the field of data security protection technologies, and in particular, to a method and an apparatus for verifying an application request.

Background

The distributed micro-service architecture is a service architecture that splits a system into a plurality of micro-services capable of realizing a module function of a very small unit and performs unified management on the plurality of micro-services, thereby completing various system functions. Typically including a server supporting the underlying services, 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 generally constructed and deployed as a middleware; or, the security protection module is independently developed in each application to carry out security protection on various access requests of the application.

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

on the one hand, the existing security service filter belongs to an application level filter, and is in level with each application, so that security problems shared by each application can be simply protected, the security characteristics of each application can not be met, and application requests can bypass the security service filter to access; on the other hand, the time, labor, test, later maintenance and other costs for independently developing the safety protection module in each application are too high, and some applications may not directly do safety logic for saving cost, which can bring great loopholes to the system safety and threaten the system safety.

Disclosure of Invention

In view of the above, the embodiment of the invention provides a method and a device for verifying an application request, which can deploy a global filter to an application server bottom layer, and adopt different verification modes for different application requests to protect system safety, prevent the application requests from bypassing the security filter to cause system loopholes and bringing great threat to system safety, greatly improve the system safety and ensure the safe and stable operation of the system.

Further, by adjusting the verification mode of the access request, the filter verifies the authority of the access request directly through the token ID, and compared with the problems that the existing access request needs to carry token and other information, and the response speed is too high and slow due to the fact that the request content is too much, the access request can be verified only by carrying the token ID, the response speed of the request is greatly improved, and the response performance of the server is guaranteed.

To achieve the above object, according to an aspect of the embodiments of the present invention, there is provided a method for verifying an application request, including:

the method is performed by a security filter deployed in a server of a distributed micro-service architecture, comprising:

receiving an access request of one or more applications; wherein the access request includes 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 yes, 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 a verification result of the access request;

and rejecting the access request under the condition that the verification result is verification failure.

Optionally, the request type of the access request comprises an intra-frame request, the application type comprises an ingress application and a non-ingress application, and the list database comprises an ingress application url whitelist and a service subscription whitelist; the step of 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 intra-frame 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 an entrance application, determining whether the access request meets the verification requirement according to the entrance application url white list, the service subscription white list and the request type.

Optionally, the request 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 the determining whether the access request meets the verification requirement according to the request type, the portal application url whitelist and the service subscription whitelist includes:

determining whether the 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 whitelist; before the determining whether the request type of the access request is the intra-frame request, further includes:

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

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

and determining whether the request function identifier belongs to the static resource white list, and if not, executing the determination 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 expiration dates;

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

and 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; wherein 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 in 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 identity tokens, service tokens, and user tokens.

Optionally, the method further comprises:

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 when any one of the following conditions occurs:

the request type of the access request is that 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 evaluation application white list, and the request function identifier belongs to the static resource white list.

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

the receiving module is used for receiving the access request of one or more applications; wherein the access request includes 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 or not 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 using a preset token cache database and determining the verification result of the access request if the request is yes;

and the response module is used for rejecting 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 for verification of an application request, including:

one or more processors;

storage means 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 are caused to implement the verification method of application requests provided by the present invention.

According to still another aspect of an embodiment of the present invention, there is provided a computer readable medium having stored thereon a computer program which, when executed by a processor, implements the method for verifying an application request provided by the present invention.

One embodiment of the above invention has the following advantages or benefits: because the request url of the access request is analyzed, whether the access request meets the verification requirement is judged according to the request type, the application type and a preset list database; under the condition of meeting the verification requirement, a preset token cache database is utilized to verify the token validity period and the token authority of the token ID carried by the request url, and the technical means of determining the verification result of the access request is overcome, so that the problem that an application-level filter can only simply protect the security problem shared by each application and cannot cope with the security characteristics of each application, and the application request possibly bypasses a security service filter to access; the time, labor, test, later maintenance and other costs for independently developing the safety protection module in each application are too high, some applications may not directly do safety logic for saving cost, so that great loopholes are brought to the safety of the system, the technical problem of threatening the safety of the system is solved, and further, the technical effects that the global filter can be deployed to the bottom layer of the application server, different verification modes are adopted for different application requests to protect the safety of the system, the system loopholes are prevented from being caused by the application requests bypassing the safety filtration, great threat is brought to the safety of the system, the safety of the system is greatly improved, and the safe and stable operation of the system is ensured are achieved.

Further effects of the above-described non-conventional alternatives are 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 the main flow of a verification method of an application request according to an embodiment of the invention;

FIG. 2 is a schematic diagram of a user calling a global filter through a global filter API when using an application in accordance with an embodiment of the present invention;

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

FIG. 4 is a schematic diagram of the main flow of a method of verifying session token information for an access request according to an embodiment of the invention;

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

FIG. 6 illustrates an exemplary system architecture diagram of an application request verification method or application request verification device suitable for application request verification applications in accordance with embodiments of the present invention;

fig. 7 is a schematic diagram of a computer system suitable for use in implementing an embodiment of the invention.

Detailed Description

Exemplary embodiments of the present invention will now be described with reference to the accompanying drawings, in which various details of the embodiments of the present invention are included to facilitate understanding, and are to be considered 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, EAI for short, or enterprise application integration, is a collection of applications and application criteria that can be shared among enterprises, and even among multiple enterprises.

BPM: business Process Management, business process management.

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

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

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

The China settlement SCAP cloud platform adopts a distributed micro-service architecture, performs intersystem communication and load balancing through a self-developed SCAP service bus, and a global filter deployed on a China settlement SCAP cloud platform server performs security control on authorization and authentication of a resource access request based on the distributed environment, so that the overall security of a system is ensured and improved, and the rapid and stable development of system business is supported.

In the embodiment of the invention, the access request comprises a request url, and the request url comprises 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 manner, that is, the request url is in a Restful style, and is spliced by five elements of a service (the service refers to a minimum logic unit triggered from a user perspective and accessible to realize a corresponding request function). Specifically:

the China settlement SCAP cloud platform can provide SCAP services for users, wherein the SCAP services comprise 5 key elements, namely five elements: (1) service domain: serviceDomain, such as overseas, headquarters, etc.; (2) service mode: serviceMode, for example, foreground service, background service, internal service; (3) service name: serviceName refers to a primary service name, which is classified from the perspective of application; (4) module name: the moduleName is a secondary service name, classifies the primary service according to the function, and belongs to a lower module of the primary service; (5) version number: version, for example, 1.0.0.

In summary, the five-element service refers to 5 elements for describing service information, through which a service can be located.

In the embodiment of the invention, the service is classified according to the use scene of the SCAP service, including internal service, background service and foreground service, including application start and stop, service registration, service subscription, heartbeat detection, service polling and the like; the background service is also an external service registered by a provider, the calling mode is interaction of background programs among applications, the background service is usually used for providing services for the applications by using an interface form, and common scenes include database operation and the like; the foreground service is an external service registered by a provider, the calling mode is usually that the access is requested through browser jump, the common scenes are access services with display interfaces, and the like, and most of scenes are that a portal application accesses an internal application through a menu and also has a scene that one internal web application jumps to another internal application. For example, the request url of the access request of various services is shown in table 1 below:

TABLE 1

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

In the embodiment of the invention, the foreground service follows a service calling frame and finally displays the business content through security authentication; the background service needs to follow a unified service invocation framework and a security authentication mechanism.

In the embodiment of the invention, the request types comprise an intra-frame 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 the BPM task view page, and the request URL may be:

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

wherein gllywbpm is the application name, i.e. the 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 to which the access request corresponds is an entry application.

In the embodiment of the invention, the processing of each application access request must pass through a server supporting the bottom layer of each application, the processing is performed by the server, and each application is quietly introduced and uses the global filter by implanting the global filter into the shared library of the server, that is, each application automatically loads the global filter after being started, and the global filter can be effective without additional configuration. Therefore, the global filter deployed on the server can be utilized to filter each access request, so that all the access requests of the application are ensured to pass through 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, that may validate various access requests by the global filter API calling the global filter when the user uses the application.

In the embodiment of the 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 calling framework locates the service provider according to the five-element service, assembles a complete request url by using the service domain, the request type, the application name and the request function identifier, and further executes subsequent judgment. The process can also be called repackaging of the access request, mainly because of the consideration of the program structure, each element of the access request is formatted and repackaged, and the use requirement of the subsequent program is met, so that the subsequent program can directly use the repackaged access request.

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 inlet 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 shifted to, and the access request is verified by using the token ID; if the authentication 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 verification method only needs to verify 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 the access request meets the verification requirement according to the present invention includes the following steps:

and step S301, comparing the application name with the evaluation application white list.

In the embodiment of the invention, the review application white list comprises old applications which are not modified and the request url standard of which does not meet the description requirement of the restful mode, and the old applications are subjected to expert review to ensure that safety risks are not brought to the system, and the old applications are allowed to be temporarily brought into the review application white list for management and judgment, and can be removed from the review application white list if the restful mode is met after the old applications are optimized and modified subsequently.

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

SUMPmonitor/qtfw-nb/CSDCC-SH/SUMPmonitor/menuModuleProvider/showIndexFlowServeret, the SUMPmonitor is compared with a review application whitelist.

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

In the embodiment of the invention, the review application white list is searched according to the application name determined by the request url, and whether the application name is in the review application white list is determined. For example, a review application whitelist is searched according to the SUMPmonitor, and whether the SUMPmonitor is in the review application whitelist is determined.

Step S303, judging whether the request type of the access request is the request inside the framework, 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 an intra-frame request or not is determined. For example, SUMPMonitor does not belong to the review application whitelist.

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 invention, the SCAP service further comprises a static resource, and the static resource generally refers to files independently deployed such as html, css, js and pictures at the front end because the application of the SCAP platform is an application with separated front and back ends. For example, the static resource request url of the BPM workstation home page is: per bpmbench/staticreource/pages/bpmbench. Where statics resource indicates that the requesting function is identified as a static resource.

And under the condition that the request type of the access request is not an intra-frame 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, the menuModuleProvider does not belong to the static resource whitelist.

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

In the embodiment of the invention, the portal application is a portal application, including EAI, and the like, and because of the specificity of the functions (such as user login, token generation, and the like), the user needs to successfully log in through the portal application and obtain the token before accessing other specific services, so that the portal application needs to be independently processed, and the authentication information of the portal application and the non-portal application is different.

Further, if the application type of the access request is a non-portal application, it indicates that the login by the portal application has been successful, and each function of the non-portal application is accessed, so the process goes to step S308, and different token types and token rights are verified 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 an entrance application or not is determined. For example, SUMPmonitor is not a portal application.

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

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

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

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

In the embodiment of the invention, contrary to the portal application url whitelist, the portal application url blacklist includes a request url list which does not conform to the portal application login, so that the access request of each request url 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 white list is determined.

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

In the embodiment of the invention, the service subscription white list integrates various services subscribed by the EAI, and belongs to a function set of a plurality of applications, namely, each application function is integrated to the EAI in a menu mode, each application in the EAI is used as a service consumer to subscribe various services in the service subscription white list, and whether the function requested by the access request belongs to the service subscribed by the EAI can be positioned according to the application name and the request function identifier of the access request.

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

In the embodiment of the invention, under the condition that the request url of the access request neither belongs to the portal application url white list nor the portal application url black list, the service corresponding to the access request belongs to a second verification mode, namely, the service can obtain the required request function only by identity verification, namely, only the token type of the access request needs to be verified, and after the identity verification 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 portal 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 whitelist is determined.

Step S309, judging whether the request type of the access request is the background service request, if yes, 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 or not is determined.

Step S310, judging whether the request type of the access request is the foreground service request, if yes, 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 a background service request, the request type of the access request is judged, and whether the request type of the access request is a foreground service request or not is determined.

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

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

In the embodiment of the present invention, in the case that it is determined in step S310 that the request type of the access request is a foreground service request, the access request is verified by adopting a first verification manner.

In the embodiment of the present invention, in the case that it is determined according to step S309 that the request type of the access request is a background service request, the access request is verified by adopting a third verification method.

Step S312, determining that the access request does not need verification, 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 an embodiment of the present invention, in the event that any of the following situations occur:

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 entry application url white list, and the request function identifier belongs to a static resource white list, which means that the access request is directly responded without verification, 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 an application corresponding to the access request. Wherein:

1. because the review application white list is an application which is subjected to expert review and does not bring security risks to the system, when the application name is in the review application white list, the access request is indicated to be not required to be verified.

2. Since the intra-frame request is usually a basic service of an 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 verification of the intra-frame request is not required, that is, when the request type of the access request is the intra-frame request, the access request is indicated to be not required.

Further, if necessary, the request inside the framework can be verified, which is similar to the service subscription white list, and the token type is verified by adopting a second verification mode.

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, the access of the static resource is generally the resource acquisition in the framework, so that when 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 verification.

4. Because each request url of the portal application url whitelist is an access request conforming to the login standard, the request url of the portal application url whitelist belongs to an access request which can be logged in safely, the access request can be directly forwarded to a login service for processing, corresponding token information is generated for the access request according to the request function of the access request, the token information comprises a token type, token authority and the like corresponding to the service which the access request wants to acquire, namely, when the request url of the access request belongs to the portal application url whitelist, the access request is indicated to be unnecessary to verify.

Step S313, rejecting the access request.

In the embodiment of the invention, under the condition that the request url of the access request is determined to belong to the portal 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, the access request of the application is refused.

In the embodiment of the invention, by the method for judging whether the access request meets the verification requirement or not, whether the access request meets the verification requirement or not can be judged according to the designed safety principle, and the method comprises the steps of judging whether the request type, the application name, the request function identification, 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 distinguishing verification of the safety of the access request is facilitated, the access safety of the system is ensured, and the safe operation of the system is ensured.

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

In the embodiment of the invention, the token cache database stores session token information (namely, complete token) of each token ID, including userID, token ID, token generation time, random serial number, encrypted signed token value, and/or user authority list. In the token cache database, the complete token corresponds to the token ID one by one, and when the token ID is stored, the token ID is used as a key and the complete token is used as a value to be stored.

In the embodiment of the invention, token types comprise identity tokens, service tokens and user tokens, token information of different types of tokens is different, the token information consists of public token and type token, public token parameters of different types of tokens are the same and only parameter values are different, but the type token of different types of tokens has characteristics. Wherein, public token includes:

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

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

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

nonce: i.e., random number, is uuid with "-" removed.

In the embodiment of the invention, the China computing SCAP platform builds a unified security mechanism based on the token, and when the background service and the foreground service call, different types of tokens are needed to be carried respectively, the background service interaction call inside the framework carries an identity token, the background service interaction call inside and outside the framework carries a service token, and the foreground service call carries a user token. Wherein:

The identity token is used for realizing authority control of background service interaction inside the framework, and comprises the following steps: applications use SCAP frameworks such as R (registry) to C (consumer), R to P (provider) heartbeat, C to R subscription, C to R poll, P to R heartbeat probe, P to R registration, P to R offload, etc. services;

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

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

In the embodiment of the invention, the token types of the tokens are mainly different from token extension objects, namely token Ext, and the token extension objects are application information and service rights of the obtained tokens. Specifically:

the token extension object of the identity token comprises a hash value set generated by five elements of a background service inside a framework of authority calling of an application, wherein the hash value set is generated by an application name, a service object (comprising a service consumer and a service provider);

The token extension object of the service token comprises a hash value set generated by five service elements of background service inside and outside a framework to which the application has permission to call;

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

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

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

step S401, obtaining a verification manner of the access request.

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

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

Step S403, taking 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 authority 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 invention, the foreground service request is usually sent by a user through a browser, that is, the foreground service is usually a user request, each user can configure different resource rights, the user logs in to a portal application and generates session token information, the session token information comprises an encrypted rights list, and a global filter queries the session token information stored in a token cache database according to a token ID and verifies whether the service requested to be accessed by the current access request is within the rights range (for example, whether the logged-in user has rights to initiate the request/request a resource). The background service request is usually derived from the application back end, 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 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 authority of the request url, that is, the first verification mode and the third verification mode are verification of the token validity period and the token authority of different token types.

In the embodiment of the invention, the target validity periods corresponding to the token IDs of different token types can be the same or different, and the target authority lists corresponding to the token IDs of different token types can be the same or different, so that the target authority lists can 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 a token cache database, and obtains a target validity period and a target authority 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 and whether the token authority of the access request belongs to the target authority list.

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 within the target validity period and the token authority of the access request belongs to the target authority list, determining that the verification result is verification success; and for the second verification mode, if the token ID is within the target validity period, determining that the verification result is verification success.

In the embodiment of the invention, after the verification is successful, a verification passing identifier can be set in the request header of the access request, so that the subsequent flow Cheng Zhijie determines the security of the access request according to the verification passing identifier, and further processes the access request. For example, after the foreground service request is successfully authenticated, a qtfw authentication passing identifier may be set in the request header of the access request, where qtfw authentication passing identifier is: authoration=qtfwcgf_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 within 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, namely, the verification result is determined to be verification failure; for the second verification mode, if the token ID is not within the target validity period, the verification result is determined to be verification failure.

Step S407, taking 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 invention, the second verification mode needs to verify the token type and the token validity period of the request url, namely, the second verification mode 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 a query key, searches a token cache database, and obtains the target validity period corresponding to the token ID.

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

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

According to the method for verifying 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 processed respectively, the security of application access is greatly improved, and the safe operation of the system is ensured.

Step S104, rejecting the access request when the verification result is verification failure.

In the embodiment of the invention, if the verification of the access request fails, rejecting the access request of the application; and if the verification result is that the verification is successful, forwarding the access request to a 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 interaction call and foreground service call inside and outside the framework, 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 security of the access request is determined, and the access request is processed. Specifically:

and for foreground service call, judging the validity period of the token ID and the token authority of the access request according to the token ValidTime and the user token, and responding to the access request through browser jump under the condition of determining the security of the access request.

And for background service interaction call inside and outside the framework, judging the validity period of the token ID and the token authority of the access request according to the token ValidTime and the service token respectively, and responding to the access request under the condition of determining the security of the access request so as to provide corresponding external call service for the application.

In the embodiment of the invention, or for background service inter-modulation in the framework, if the token ID is within the target validity period, the security of the access request is determined, and the access request is processed. Specifically:

and for background service interaction calling in the framework, judging the validity period of the token ID according to the token ValidTime, and responding to the access request under the condition of determining the security of the access request to provide corresponding internal calling service for the application.

In an embodiment of the invention, an access request of one or more applications is received; wherein the access request includes 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 yes, 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 a verification result of the access request; under the condition that the verification result is verification failure, the steps such as rejecting the access request and the like can be carried out, a global filter can be deployed on the bottom layer of the application server, and different verification modes are adopted according to the type of the application request, so that the safety of the system is protected, the system loophole caused by the fact that the application request bypasses the safety filtration is prevented, the safety of the system is greatly threatened, the safety of the system is greatly improved, and the safe and stable operation of the system is ensured.

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

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

The judging module 502 is configured to analyze the request url, determine a request type and an application type of the access request, and judge 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 authority 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.

And a response module 504, configured to reject 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 the modules such as the receiving module, the judging module, the verifying module and the responding module, and different verifying modes are adopted for different application requests so as to protect the system safety, prevent the system loophole caused by the application requests bypassing the safety filtering, bring great threat to the system safety, greatly improve the safety of the system and ensure the safe and stable operation of the system.

Fig. 6 shows an exemplary system architecture diagram of an application-requested authentication method or an application-requested authentication apparatus adapted to be applied to an embodiment of the present invention, and as shown in fig. 6, an exemplary system architecture of an application-requested authentication method or an application-requested authentication apparatus of an 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 as a medium to provide communication links between the terminal devices 601, 602, 603 and the server 105. The network 604 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

A user may interact with the server 605 via the network 604 using the terminal devices 601, 602, 603 to receive or send messages, etc. Various communication client applications, such as security class applications, shopping class applications, web browser applications, search class applications, instant messaging tools, mailbox clients, social platform software, etc., may be installed on the terminal devices 601, 602, 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 smartphones, tablets, laptop and desktop computers, and the like.

The server 605 may be a server providing various services, such as a background management server providing support for security-like websites browsed by users using the terminal devices 601, 602, 603. The background management server may analyze and process the received data such as the access request, and may feed back the processing result (e.g., failure in verification of the access request) to the terminal devices 601, 602, 603.

It should be noted that, the method for verifying an application request provided in the embodiment of the present invention is generally executed by the server 605, and accordingly, the verification 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 use in implementing a terminal device or a server according to an embodiment of the present invention, and as shown in fig. 7, a computer system 700 of a terminal device or a server according to an embodiment of the present invention includes:

a Central Processing Unit (CPU) 701, which can execute 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 required for the operation of the system 700 are also stored. The CPU701, ROM702, and RAM703 are connected to each other through 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 section 706 including a keyboard, a mouse, and the like; an output portion 707 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, a speaker, and the like; a storage section 708 including a hard disk or 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. The 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 therefrom is mounted into the storage section 708 as necessary.

In particular, according to embodiments of the present disclosure, the processes described above with reference to 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 shown in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication portion 709, and/or installed from the removable medium 711. The above-described functions defined in the system of the present invention are performed when the computer program is executed by a Central Processing Unit (CPU) 701.

The computer readable medium shown in the present invention may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any 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 context of this document, 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, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. 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 flowcharts 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 involved in the embodiments of the present invention may be implemented in software or in hardware. The described modules may also be provided in a processor, for example, as: a processor includes a receiving module, a judging module, a verifying module and a responding module. The names of these modules do not constitute a limitation on the module itself in some cases, for example, the verification module may also be described as a "module for 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".

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 present alone without being fitted into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to include: receiving an access request of one or more applications; wherein the access request includes 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 yes, 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 a verification result of the access request; and rejecting the access request under the condition that the verification result is verification failure.

According to the technical scheme of the embodiment of the invention, a global filter is deployed at the bottom layer of an application server (WAS, JBOSS), and the token type, the token validity period and the token authority of the access request are verified. The global filter embedded in the bottom layer of the application server is deeply fused with the application server, and various applications must automatically load the filter to prevent the application from bypassing the security verification because the application does not make security logic for lazy.

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 verification of a new session token, background service of an original service token, verification of the right of the frame internal call and the like.

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

The above embodiments do not limit the scope of the present invention. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives can occur depending upon design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of the present invention.

Claims (10)

1. A method of validating an application request, the method performed by a security filter deployed in a server of a distributed micro-service architecture, comprising:

Receiving an access request of one or more applications; wherein the access request comprises a request url, and the request url comprises a request function identifier;

analyzing the request url, determining a request type and an application type of the access request, wherein the request type of the access request comprises an intra-frame request, a background service request and a foreground service request, the application type of the access request comprises an entry application and a non-entry application, and judging whether the access request meets the verification requirement according to the request type, the application type and a preset list database comprises the following steps:

judging whether the request type of the access request is the intra-frame request or not; if the request type of the access request is not the intra-frame request, determining whether the application type of the access request is the portal application;

the list database comprises an entrance application url white list and a service subscription white list, and the determining whether the access request meets the verification requirement according to the entrance application url white list, the service subscription white list and the request type under the condition that the application type of the access request is the entrance application comprises the following steps: determining whether the request url of the access request belongs to the portal application url white list, and whether the application name of the application and the request function identifier belong to the service subscription white list; if the request url does not belong to the portal application url white list, and the application name of the application and the request function identifier do not belong to the service subscription white list, judging whether the request type of the access request is the foreground service request or the background service request; 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;

If the access request meets the verification requirement, 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 a verification result of the access request;

and rejecting the access request under the condition that the verification result is verification failure.

2. The method of claim 1, wherein the request url further includes an application name, and the listing database further includes a review application whitelist; before the determining whether the request type of the access request is the intra-frame request, further includes:

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

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

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

4. The method of claim 1, wherein verifying the token validity period and the token authority of the token ID using a preset token cache database, and determining 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; wherein the token IDs of different token types correspond to the same or different target expiration dates;

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

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

5. The method of claim 4, wherein the determining that the authentication result of the access request is authentication success further comprises:

taking the token ID as a query key, searching the token cache database, and determining a target authority list corresponding to the token ID; wherein 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 in 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.

6. The method of claim 4 or 5, wherein the token types include identity tokens, service tokens, and user tokens.

7. The method according to any one of claims 1 to 5, further comprising:

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 when any one of the following conditions occurs:

the request types of the access requests are intra-frame requests, request url of the access requests belong to an entry application url white list, application names belong to a review application white list, and request function identifiers belong to a static resource white list.

8. An application request verification apparatus, comprising:

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

the judging module is used for analyzing the request url and determining the request type and the application type of the access request, wherein the request type of the access request comprises a frame internal request, a background service request and a foreground service request, the application type of the access request comprises an entrance application and a non-entrance application, and the judging whether the access request meets the verification requirement or not according to the request type, the application type and a preset list database comprises the following steps:

Judging whether the request type of the access request is the intra-frame request or not; if the request type of the access request is not the intra-frame request, determining whether the application type of the access request is the portal application;

the list database comprises an entrance application url white list and a service subscription white list, and the determining whether the access request meets the verification requirement according to the entrance application url white list, the service subscription white list and the request type under the condition that the application type of the access request is the entrance application comprises the following steps: determining whether the request url of the access request belongs to the portal application url white list, and whether the application name of the application and the request function identifier belong to the service subscription white list; if the request url does not belong to the portal application url white list, and the application name of the application and the request function identifier do not belong to the service subscription white list, judging whether the request type of the access request is the foreground service request or the background service request; 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;

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 meets the verification requirement, and determining the verification result of the access request;

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

9. An electronic device for application-requested authentication, comprising:

one or more processors;

storage means for storing one or more programs,

when executed by the one or more processors, causes the one or more processors to implement the method of any of claims 1-7.

10. A computer readable medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the method according to any of claims 1-7.

Images