CN117544408A

CN117544408A - Enterprise-level service system authority authentication method based on unified authentication package

Info

Publication number: CN117544408A
Application number: CN202311758503.0A
Authority: CN
Inventors: 蒋煜辉
Original assignee: Hangzhou Langge Technology Co ltd; Zhejiang Geely Holding Group Co Ltd
Current assignee: Hangzhou Langge Technology Co ltd; Zhejiang Geely Holding Group Co Ltd
Priority date: 2023-12-19
Filing date: 2023-12-19
Publication date: 2024-02-09

Abstract

The application provides an enterprise-level service system authority authentication method based on a unified authentication package, and relates to the technical field of data processing. The method is applied to background service of a target service platform, the background service is loaded with a unified authentication package, and preset authentication logic is packaged in the unified authentication package, and the method comprises the following steps: receiving a service request sent by a user through front-end service of a target service platform; invoking authentication logic corresponding to the service request based on the service request; if the authority token in the service request is legal, inquiring a local cache, and determining whether an authentication result of the user exists in the local cache; if yes, returning a service processing result or authentication failure information to the front-end service according to the authentication result; if not, acquiring an authentication result, and returning a service processing result or authentication failure information to the front-end service according to the authentication result. The method solves the problem that the authentication is difficult to be quickly accessed in the current software development, and reduces response time consumption.

Description

Enterprise-level service system authority authentication method based on unified authentication package

Technical Field

The application relates to the technical field of data processing, in particular to an enterprise-level service system authority authentication method based on a unified authentication package.

Background

With the development of internet technology, an online business system at an enterprise level is more and more popular, and in order to ensure the security of enterprise data, each user using the business system needs to perform authentication before transacting business.

In the prior art, two common authentication schemes are adopted, one is that a gateway bears all front-end request traffic to realize authentication and request forwarding, the scheme can affect time consumption and stability of requests, and the scheme becomes a system bottleneck with the increase of service requests. The other is that a set of request interception and authority system is respectively arranged at the rear end of each service system to carry out authentication, and the scheme does not form a unified authentication function, so that the specific realization can only depend on the rear end maintenance of each platform, the quality assurance is lacked, the unified management and upgrading are difficult, and the maintenance cost is high.

Therefore, a new enterprise-class service system authority authentication method based on a unified authentication package is needed to solve the above-mentioned problems.

Disclosure of Invention

The application provides an enterprise-level service system authority authentication method based on a unified authentication package, which is used for solving the problems of long response time consumption, instability, lack of quality assurance, high cost and the like in the current authentication.

In a first aspect, the present application provides an enterprise-level service system authority authentication method based on a unified authentication package, where the method is applied to a background service of a target service platform, the background service is loaded with the unified authentication package, and a preconfigured authentication logic is packaged in the unified authentication package, and the method includes:

receiving a service request sent by a user through front-end service of the target service platform; the service request carries an authority token and a target service, wherein the authority token is generated by a user on the basis of user information, a tenant identification code of the target service platform and user authority information of the user on the target service platform when the user logs in the target service platform through the front-end service;

invoking authentication logic corresponding to the service request based on the service request;

if the authority token in the service request is legal, inquiring a local cache, and determining whether an authentication result of the user exists in the local cache; the local cache is used for storing the authentication result for a preset effective duration;

if yes, returning a service processing result or authentication failure information to the front-end service according to the authentication result; if not, acquiring an authentication result, and returning a service processing result or authentication failure information to the front-end service according to the authentication result.

Optionally, the obtaining the authentication result includes:

sending a permission request carrying the permission token to the permission platform; the authority request is used for indicating the authority platform to verify the authority token, authenticating according to the user authority information obtained from the distributed cache, obtaining an authentication result and sending the authentication result to the background service;

and receiving an authentication result sent by the permission platform.

Optionally, the method further comprises:

if the received authentication result sent by the authority platform is determined to be null, loading the authentication result from a permanent database, and updating the authentication result into the distributed cache.

Optionally, the calling the authentication logic corresponding to the service request based on the service request includes:

analyzing the service request, acquiring the analyzed service request, and determining a target service to be executed by a user;

determining and calling authentication logic corresponding to the target service based on the corresponding relation between the target service and a preset; the preset corresponding relation characterizes the corresponding relation between the target service and the authentication logic.

Optionally, the determining that the authority token in the service request is legal includes:

decrypting the authority token in the service request to obtain a decrypted authority token;

if the authority token is generated based on the user information, the tenant identification code of the target service platform and the user authority information of the user on the target service platform and is not expired, determining that the authority token in the service request is legal.

Optionally, the returning, according to the authentication result, service processing result or authentication failure information to the front-end service includes:

if the authentication result is determined to pass the authentication, executing service processing logic corresponding to the target service to obtain a service processing result, and returning the service processing result to the front-end service;

and if the authentication result is determined to be authentication failure, returning authentication failure information to the front-end service.

Optionally, the authentication logic includes one or more of: the system comprises function authority authentication logic, data acquisition authority logic, data authority authentication tool class, user information acquisition logic, interface level authority configuration logic and back-end remote service call authentication configuration logic.

In a second aspect, the present application provides an enterprise-class service system authority authentication device based on a unified authentication package, where the device is applied to a background service of a target service platform, the background service is loaded with the unified authentication package, and a preconfigured authentication logic is packaged in the unified authentication package, and the device includes:

the receiving unit is used for receiving a service request sent by a user through the front-end service of the target service platform; the service request carries an authority token and a target service, wherein the authority token is generated by a user on the basis of user information, a tenant identification code of the target service platform and user authority information of the user on the target service platform when the user logs in the target service platform through the front-end service;

the calling unit is used for calling authentication logic corresponding to the service request based on the service request;

the determining unit is used for querying a local cache if the permission token in the service request is determined to be legal, and determining whether an authentication result of the user exists in the local cache; the local cache is used for storing the authentication result for a preset effective duration;

The processing unit is used for returning a service processing result or authentication failure information to the front-end service according to the authentication result if the authentication result exists; if not, acquiring an authentication result, and returning a service processing result or authentication failure information to the front-end service according to the authentication result.

In a third aspect, the present application provides an electronic device, including: a processor, and a memory communicatively coupled to the processor;

the memory stores computer-executable instructions;

the processor executes computer-executable instructions stored in the memory to implement the method as described above.

In a fourth aspect, the present application provides a computer readable storage medium having stored therein computer executable instructions which when executed by a processor are adapted to carry out the method as described above.

In a fifth aspect, the present application provides a computer program product comprising a computer program for implementing the method as described above when being executed by a processor.

The enterprise-level service system authority authentication method based on the unified authentication package, which is provided by the application, is applied to the background service of the target service platform, the background service is loaded with the unified authentication package, and the unified authentication package is packaged with the pre-configured authentication logic, and the method comprises the following steps: receiving a service request sent by a user through front-end service of the target service platform; the service request carries an authority token and a target service, wherein the authority token is generated by a user on the basis of user information, a tenant identification code of the target service platform and user authority information of the user on the target service platform when the user logs in the target service platform through the front-end service; invoking authentication logic corresponding to the service request based on the service request; if the authority token in the service request is legal, inquiring a local cache, and determining whether an authentication result of the user exists in the local cache; the local cache is used for storing the authentication result for a preset effective duration; if yes, returning a service processing result or authentication failure information to the front-end service according to the authentication result; if not, acquiring an authentication result, and returning a service processing result or authentication failure information to the front-end service according to the authentication result. On one hand, the background service is loaded with the unified authentication package, and as the unified authentication package encapsulates common interface interception and authentication logic of all services, an application platform with perfect functions and any access permission can be directly introduced into the authentication package to realize unified authentication, so that the problem that the authentication is difficult to be quickly accessed in the current software development is solved, the repeated work is avoided, the permission is conveniently and quickly accessed, the access quality is ensured, the unified management and the upgrading are convenient, the abundant and perfect authentication function is provided, and the development workload of the service on related requirements such as the function permission, the data permission and the like is greatly reduced. On the other hand, the local cache of the background service is used for storing the authentication result for the preset effective duration, so that repeated requests of a large number of front ends in the preset effective duration are not required to be repeated for re-authentication of the authority service by the background service, the time consumption caused by calling the authority service is greatly reduced, and the problem that a large number of platform operations bring a large number of concurrences to the authority service is avoided.

Drawings

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

Fig. 1 is a schematic diagram of an authentication architecture according to an embodiment of the present application;

fig. 2 is a schematic diagram of yet another authentication architecture according to an embodiment of the present application;

fig. 3 is a schematic diagram of an authentication architecture based on the authentication method of the present application according to an embodiment of the present application;

fig. 4 is a flow chart of an enterprise-class service system authority authentication method based on a unified authentication package according to an embodiment of the present application;

fig. 5A is a schematic diagram of an authentication model according to an embodiment of the present application;

fig. 5B is a schematic diagram of unified authentication packet function implementation logic according to an embodiment of the present application;

FIG. 6 is a signaling flow diagram of an embodiment of the present application for implementing an enterprise-class service system authority authentication method based on a unified authentication package;

fig. 7 is a schematic structural diagram of an enterprise-level service system authority authentication device based on a unified authentication package according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of another enterprise-class service system authority authentication device based on a unified authentication package according to an embodiment of the present application;

Fig. 9 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Specific embodiments thereof have been shown by way of example in the drawings and will herein be described in more detail. These drawings and the written description are not intended to limit the scope of the inventive concepts in any way, but to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present application as detailed in the accompanying claims.

The terms "first," "second," "third," "fourth" and the like in the description and in the claims of this application and in the above-described figures, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the invention described herein may be implemented, for example, in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) referred to in the present application are information and data authorized by the user or fully authorized by each party, and the collection, use and processing of the related data need to comply with the related laws and regulations and standards, and provide corresponding operation entries for the user to select authorization or rejection.

Authentication refers to verifying whether a user has rights to access a system, and conventional authentication is verified by a password, provided that each user who obtains the password has been authorized.

For each business platform of each enterprise, a set of front-end and back-end business systems are generally corresponding, and if authentication is not performed, each user capable of logging in the business platforms has the operation and viewing authority of all functions and data of the platforms. Although other non-corporate personnel can be restricted to log in the service platforms from the platform level by erecting a local area network, for some corporate personnel and outsourcers needing to log in from different places, the business requirements of the login platforms are met, and the use rights owned by all login users can be different according to different division of staff. To ensure data security, how to open different rights to different users, and how to authenticate them is a matter of concern for each system developer.

In one example, the gateway is used for intercepting and forwarding uniformly, all requests sent to each background service by the front-end service are required to pass through the gateway layer service, and the requests are issued to the back-end service after authentication by the gateway layer is completed, so that the service layer does not need to maintain logic codes related to the request interception and authentication.

Fig. 1 is a schematic diagram of an authentication architecture according to an embodiment of the present application. As shown in fig. 1, a user initiates a service request through a front-end service, and after being uniformly intercepted and authenticated by a gateway, the service request is forwarded to each micro service in a back-end micro service cluster, such as user service, order service and the like, for service processing. In the mode, the gateway bears all front-end request traffic, and the time consumption and stability of response requests can be influenced along with the increase of service requests; in addition, since the service system itself does not include an authentication function, if the gateway is bypassed, the whole service system is exposed, the security is not ensured, the service itself cannot determine the authority configuration, and the service needs to be maintained by means of gateway service.

In yet another example, there is no unified authentication interception module, but a set of request interception and authorization systems are respectively set at the back end of each service system to perform authentication. Fig. 2 is a schematic diagram of still another authentication architecture according to an embodiment of the present application. As shown in fig. 2, a user initiates a service request through a front-end service, after receiving the service request, a background service firstly authenticates by an authentication system in the background service, and after passing the authentication, the background service processes the service. In the mode, each business service can realize interception and authentication according to own requirements and maintain authority configuration called by an interface by oneself, but because a unified authentication function is not formed, the specific realization can only rely on the maintenance of the rear end of each platform, the quality assurance is lacked, the unified management and upgrading are difficult, the maintenance cost is high, repeated workload can be increased for each business maintenance by oneself, the working efficiency is low, the rapid access authority function can not be realized for new application, and repeated authority development work is needed.

In order to solve the above problems, the present application provides an enterprise-class service system authority authentication method based on a unified authentication package. Firstly, in order to have a unified and perfect authentication function, the authority management and the subsequent function upgrading and maintenance are convenient, the unified authentication package which encapsulates common authentication logic of all services is used for authentication in background service of a service platform, accordingly, the authentication can be realized by directly introducing the unified authentication package into an application platform which wants to access the authority, and the problem that quick access and unified authentication are difficult is solved. Secondly, in order to solve the problem of low response speed in unified authentication, the method and the device have the advantages that by means of secondary cache, namely a service application local cache authentication result and an authority application distributed cache, for a large number of repeated requests of the front end in a short time, repeated authentication of the authority removal service is not needed, time consumption caused by the authority removal service is greatly reduced, and therefore the influence of the authentication on request performance is reduced.

The following describes the technical solutions of the present application and how the technical solutions of the present application solve the above technical problems in detail with specific embodiments. The following embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.

Fig. 3 is a schematic diagram of an authentication architecture according to an embodiment of the present application. As shown in fig. 3, to implement the enterprise-level service system authority authentication method based on the unified authentication package of the present application, at least the front-end service, the background service and the authority platform of the target service platform should be included. In some examples, an enterprise login service is also included for completing a user's login request.

Fig. 4 is a flow chart of an enterprise-class service system authority authentication method based on a unified authentication package according to an embodiment of the present application. The method provided by the embodiment is applied to the background service of the target service platform, and the execution subject of the method can be the background service or an authentication device positioned on the background service. The background service is loaded with a unified authentication package, and the unified authentication package is packaged with pre-configured authentication logic.

Illustratively, the unified authentication package encapsulates the common interface interception and authentication logic of all services, and may include: the system comprises one or more of function authority authentication logic, data acquisition authority logic, data authority authentication tool class, user information acquisition logic, interface level authority configuration logic, back-end remote service call authentication configuration logic and the like, and can be configured in a self-defined mode according to requirements.

Illustratively, functional rights are generally used to indicate which rights a user has, such as adding, deleting, modifying, looking up, approving, counterapproving, etc., a particular document; the bill is generally divided according to the working content of a person in an organization, for example, a bill often has an input person and an approver, the input person has the authority of adding, deleting, checking and checking, and the approver has the authority of approving, counterapproving and inquiring; in addition, the function authority may be subdivided into page authority, operation authority, and the like. Data permissions are typically used to indicate what ranges of primary data a user can see, such as being divided by department or business line, e.g., user's third party sees data for team a, user's fourth party can only see data for team B, etc.

The corresponding authentication logic of different authorities is different, the unified authentication package is required to be configured according to the functions of each service platform and the authentication requirements thereof, and only the authority logic added with the relevant configuration can really play a role. The unified authentication package loaded by the background service is the authentication logic which is pre-configured according to the authentication requirements of the target service platform, and can meet the authentication requirements of different service requests.

Fig. 5A is a schematic diagram of an authentication model according to an embodiment of the present application. As shown in fig. 5A, the authentication model includes a user, a role, and a right, where the user and the role may be in a many-to-many relationship, and the role and the right may also be in a many-to-many relationship. In the application, the authority model shown in fig. 5A is adopted, and in practical application, the user, the role and the authority are set according to practical conditions.

The present application does not limit how to configure the unified authentication package. For example, taking a function authority of the vendor management platform for controlling the deletion authority of vendor information as an example, the complete code of the deletion authority is "provider #provider_manager_provider_info#del" for uniquely identifying the authority, the authentication logic of the deletion authority will only be validated when the platform receives the service request of "http:// log.provider_manager_info#del".

By configuring the unified authentication package, perfect authority function support can be provided, and the business party is supported to directly modify own service authority without relying on authority service. When configuration is carried out, firstly, the domain name of the corresponding environment is changed after the url environment of the authority platform is deployed, then, the authentication log is determined, log information such as authentication access parameters is printed, and then, information such as the maximum length of a cache, the initialization length of the cache, the minute level (namely the cache time of an authentication result, default 1 minute) and the like in the authority local cache are set, and the time duration, the quantity and the like of the authentication result of the background service local cache can be determined through the configuration, so that the time-consuming influence of the authentication on the request can be effectively reduced through adjusting the configuration. In addition, when configuring the authority priority, the support wildcard can be set, the wildcard is not matched, namely authentication is not performed, the priority before the matching is higher (but if the path expression is the same, the front matching can be covered by the latter), an authentication filter with lower priority can not be walked after the authentication filter hits a group of filters, and the authentication filter can comprise a token na uth filter, a permas authority filter, an anon default filter, and the like, and the application is not limited.

Fig. 5B is a schematic diagram of unified authentication packet function implementation logic according to an embodiment of the present application. As shown in fig. 5B, when the front end initiates a request, a default filter (anonFilter) intercepts the request, determines whether the request needs to open authentication, if it is determined that authentication is not needed, directly executes service logic, transfers data authority information according to configuration, if it is determined that authentication is needed, a token parsing filter (token filter) parses and verifies the validity of a token carried by the request, and a authority filter (permFilter) further determines the authority needed by the request according to authority configuration, determines whether the token carried by the request meets a condition, if so, determines that authentication is passed, executes service processing logic based on service codes, transfers data authority information according to configuration, if not, determines that authentication is not passed, and returns information that authentication is not passed to the front end.

For the data permission, mainly for the query method, the special permission dataPerm can be declared in the configuration to acquire the data permission of the user, the data permission judging logic is also packaged in the unified authentication package, the data permission judging logic automatically covers the transmission of the parameters according to judgment, the permission can also provide the dataPermHandleEnable annotation, but the section is not forced, and the application party can process the input parameters by using the DatePermHandleUtil according to the annotation in the section method by himself.

Furthermore, the unified authority package can return some authority related information such as user information, provider information, data authority and the like which are concerned by the service request besides providing authentication, and can be realized by adding corresponding specific configuration, so that the application is not limited. In addition, the functions of forcing the user to get off line, monitoring the user behavior, refreshing the authority configuration in real time and the like can be realized by configuring the unified authority package, and the application is not limited.

The unified authentication package encapsulates the common interface interception and authentication logic of all services, so that an application platform with perfect functions and any access permission can directly introduce the authentication package to realize unified authentication, and the problem that the quick access authentication is difficult in the current software development is solved.

As shown in fig. 4, the enterprise-class service system authority authentication method based on the unified authentication package provided in this embodiment includes:

s401, receiving a service request sent by a user through front-end service of a target service platform; the service request carries an authority token and a target service, wherein the authority token is generated by the authority platform based on user information, a tenant identification code of the target service platform and user authority information of the user on the target service platform when the user logs in the target service platform through front-end service.

In this application, a user operates a target service platform through a front-end service (such as a browser) to send a service request, and a background service performs authentication and subsequent service processing according to the received service request after receiving the service request.

The user needs to log in the target service platform first to operate the target service platform. When logging in, a user inputs information such as a user name, a password and the like through a front-end service to initiate a login request, the front-end service or an enterprise login service carries out login authentication based on the login request, and if the verification of a user login target service platform is confirmed to pass, an acquisition request of an authority token is sent to an authority platform; otherwise, determining that the user login fails or the user does not exist. The request for obtaining the permission Token should include information such as user information (e.g. sso Token) and a tenant identification code of the target service platform. After receiving the acquisition request of the permission token, the permission platform inquires and determines the user permission information of the user on the target service platform based on the acquisition request, authenticates to determine an authentication result, generates the permission token (refresh-token) based on the user information, the tenant identification code of the target service platform and the user permission information of the user on the target service platform, stores the permission token and the inquired user permission information in a distributed cache, and returns the distributed cache to the front-end service. And then, the front-end service displays an authority service interface of the user on the target service platform after the user successfully logs in, the user can operate the interface, and a service request carrying an authority token and the target service is initiated to the background service.

The authority token efresh-token is a unique identifier obtained after a user logs in a target service platform, and can be used for identifying the user and the platform, the validity period of the unique identifier is generally one day at the beginning, if the user performs an operation (interface call) on the platform today, the validity period of one day is prolonged for the user, and the maximum validity period can be prolonged for seven days. The validity period can enhance the security of the authority service, the authority token refresh-token can be understood as an encrypted character string of login user information, a user login platform and a maximum validity period system of the information sets, the authority token refresh-token can play a role in authentication and tenant isolation, and the back-end service can carry out verification and authentication according to the refresh-token.

In order to improve data security, when the rights platform generates the rights token based on the user information, the tenant identification code of the target service platform and the user rights information of the user on the target service platform, the information such as the user information, the tenant identification code of the target service platform and the user rights information of the user on the target service platform can be encrypted by an encryption mode such as a data encryption standard (Data Encryption Standard, DES).

S402, based on the service request, invoking authentication logic corresponding to the service request.

For example, since the target services in different service requests are different, the corresponding authentication logic is different, and thus the background service can call the authentication logic corresponding to the service request based on the service request after receiving the service request, so as to perform authentication correctly.

In one example, invoking authentication logic corresponding to a service request based on the service request may include:

s1, analyzing the service request, acquiring the analyzed service request, and determining a target service to be executed by a user.

S2, determining and calling authentication logic corresponding to the target service based on the corresponding relation between the target service and the preset service; the preset corresponding relation characterizes the corresponding relation between the target service and the authentication logic.

The background service may analyze the service request after receiving the service request, determine the analyzed service request, where the analyzed service request includes the permission token and the target service, and call the authentication logic corresponding to the target service based on the corresponding relationship between the target service and the authentication logic, so as to perform authentication correctly.

S403, if the authority token in the service request is legal, inquiring the local cache, and determining whether an authentication result of the user exists in the local cache; the local cache is used for storing the authentication result preset effective duration.

Illustratively, the background service, when authenticating, first determines that the rights token in the service request is legitimate. Wherein, determining that the authority token in the service request is legal may include:

s10, decrypting the authority token in the service request to obtain the decrypted authority token.

And S20, if the permission token is generated based on the user information, the tenant identification code of the target service platform and the user permission information of the user on the target service platform and is not expired based on the decrypted permission token, determining that the permission token in the service request is legal.

Illustratively, the rights token is encrypted for improved data security. The background service firstly decrypts the authority token and determines the decrypted authority token; then, based on the decrypted rights token, it is determined whether the rights token is generated based on the user information, the tenant identity of the target service platform, and the user rights information of the user at the target service platform, and whether the rights token is expired. If the permission token is determined to be generated based on the user information, the tenant identification code of the target service platform and the user permission information of the user on the target service platform, and the permission token is not expired, determining that the permission token in the service request is legal.

The background queries the local cache after determining that the authority token in the service request is legal, and determines whether an authentication result of the user exists in the local cache, wherein the authentication result is used for indicating that the authentication of the user passes or fails. The local cache of the background service is used for storing the preset effective duration of the authentication result, so that repeated requests of a large number of front ends in the preset effective duration are not required to be repeated for re-authentication of the authority service by the background service, time consumption caused by calling the authority service is greatly reduced, and the problem that a large number of platform operations bring a large number of concurrences to the authority service is avoided.

S404, if yes, returning a service processing result or authentication failure information to the front-end service according to the authentication result; if not, acquiring an authentication result, and returning a service processing result or authentication failure information to the front-end service according to the authentication result.

For example, if the background service determines that the authentication result of the user exists in the local cache, the background service determines to execute the service processing logic directly according to the authentication result in the local cache so as to return the service processing result or authentication failure information to the front-end service. If it is determined that the authentication result of the user does not exist in the local cache, the authentication result needs to be acquired first, and then, according to the acquired authentication result, it is determined that the service processing result or authentication failure information is returned to the front-end service.

In one example, obtaining the authentication result may include:

s100, sending a permission request carrying a permission token to a permission platform; the authority request is used for indicating the authority platform to verify the authority token, authenticating according to the user authority information obtained from the distributed cache, obtaining an authentication result and sending the authentication result to the background service.

S200, receiving an authentication result sent by the permission platform.

When it is determined that the authentication result of the user does not exist in the local cache, the authentication result of the local cache is indicated to be valid, and the authentication result needs to be acquired through the authority platform. When the authentication result is obtained, the background service firstly sends an authority request carrying an authority token to the authority platform. When receiving a permission request carrying a permission token, the permission platform firstly checks whether the permission token is legal (whether the permission token is within a valid period), and if the permission token is legal, the permission platform acquires the permission information of the user from the distributed cache, performs authentication to determine an authentication result and returns the authentication result to the background service; if the permission token is determined to be out of date, the permission token is renewed, if the renewal is successful, the step of acquiring the permission information of the user from the distributed cache is executed, authentication is continued to determine an authentication result, and if the renewal is failed, a result of authentication failure is returned.

In an actual scenario, there is a case that the authentication result obtained from the distributed cache may be empty, and when the authentication result obtained from the distributed cache is empty, the authentication result received by the background service is also empty. If the background service determines that the received authentication result sent by the authority platform is null, the authentication result can be loaded from the permanent database and updated into the distributed cache so as to obtain the authentication result later.

Illustratively, after the background service obtains the authentication result, the service returns a service processing result or authentication failure information to the front-end service according to the authentication result. In one example, according to the authentication result, returning the service processing result or authentication failure information to the front-end service may include:

and S1000, if the authentication result is determined to pass, executing the service processing logic corresponding to the target service to obtain a service processing result, and returning the service processing result to the front-end service.

And S2000, if the authentication result is determined to be authentication failure, returning authentication failure information to the front-end service.

The authentication result indicates that the user authentication passes or fails, when the authentication result indicates that the authentication passes, the user has the authority to operate the target service, and the background service executes the service processing logic corresponding to the target service, so that the service processing result can be obtained, and the service processing result is returned to the front-end service; and when the authentication result indicates authentication failure, indicating that the user does not have the authority to operate the target service, and thus returning authentication failure information to the front-end service.

The enterprise-level service system authority authentication method based on the unified authentication package provided by the embodiment of the application comprises the following steps: receiving a service request sent by a user through front-end service of a target service platform; the service request carries an authority token and a target service, wherein the authority token is generated by the authority platform based on user information, a tenant identification code of the target service platform and user authority information of the user on the target service platform when the user logs in the target service platform through front-end service; invoking authentication logic corresponding to the service request based on the service request; if the authority token in the service request is legal, inquiring a local cache, and determining whether an authentication result of the user exists in the local cache; the local cache is used for storing the authentication result for a preset effective duration; if yes, returning a service processing result or authentication failure information to the front-end service according to the authentication result; if not, acquiring an authentication result, and returning a service processing result or authentication failure information to the front-end service according to the authentication result. On one hand, the background service is loaded with the unified authentication package, and as the unified authentication package encapsulates common interface interception and authentication logic of all services, an application platform with perfect functions and any access permission can be directly introduced into the authentication package to realize unified authentication, so that the problem that the authentication is difficult to be quickly accessed in the current software development is solved, the repeated work is avoided, the permission is conveniently and quickly accessed, the access quality is ensured, the unified management and the upgrading are convenient, the abundant and perfect authentication function is provided, and the development workload of the service on related requirements such as the function permission, the data permission and the like is greatly reduced. On the other hand, the local cache of the background service is used for storing the authentication result for the preset effective duration, so that repeated requests of a large number of front ends in the preset effective duration are not required to be repeated for re-authentication of the authority service by the background service, the time consumption caused by calling the authority service is greatly reduced, and the problem that a large number of platform operations bring a large number of concurrences to the authority service is avoided.

Fig. 6 is a signaling flow diagram of an exemplary method for implementing authority authentication of an enterprise-class service system based on a unified authentication package according to an embodiment of the present application. As shown in fig. 6, a process of implementing the enterprise-class service system authority authentication method based on the unified authentication package may include:

s601, a user initiates a request for logging in a target service platform through a front-end service.

S602, the front-end service requests Token from the enterprise login service to verify and acquire user information.

S603, if the verification is passed, the enterprise login service returns sso Token.

S604, the front-end service initiates an acquisition request of a permission Token refresh Token carrying sso Token to the permission platform.

S605, the authority platform requests user information from the enterprise login service.

S606, the enterprise login service returns user information to the permission platform.

In some examples, if the obtaining request includes information such as user information and a tenant identification code of the user on the target service platform, steps S602 to S606 may be omitted.

S607, the authority platform inquires the user authority, and generates a refresh token based on the user information, the tenant identification code of the target service platform, the user authority information of the user on the target service platform and the like.

S608, the rights platform stores the refresh token and the user rights information in the Redis distributed cache.

S609, the rights platform returns refresh token, user rights information and the like to the front-end service.

S610, the front-end service initiates a service request to a background service of the target service platform. Wherein, the service request carries a refresh token.

S611, the background service analyzes the service request and acquires a refresh token.

S612, inquiring the local cache, and determining whether an authentication result of the user exists in the local cache; if so, step S620 or S621 is performed.

S613, if the request does not exist, sending a permission request carrying a refresh token to the permission platform.

S614, the permission platform checks the refresh token, if the refresh token is determined to be out of date, the renewal is carried out, and if the renewal is failed or illegal, the authentication failure result is returned.

S615, if the permission platform determines that the refresh token is legal, the permission information of the user is obtained from the distributed cache, and authentication is performed to determine an authentication result.

S616, the permission platform returns the cache information to the background service.

S617, if the received cache information is determined to be empty, the authentication result is loaded from the permanent database.

And S618, updating the authentication result into the distributed cache.

And S619, the authority platform returns an authentication result to the background service.

And S620, if the background service determines that the authentication passes, executing the service processing logic, and returning a service processing result to the front-end service.

S621, if the background service determines that the authentication fails, the background service returns authentication failure information to the front-end service.

So far, through the flow, the process from logging in the target service platform to completing the service processing of the user can be completed.

The following are device embodiments of the present application, which may be used to perform method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

Fig. 7 is a schematic structural diagram of an enterprise-class service system authority authentication device based on a unified authentication package according to an embodiment of the present application. The enterprise-level service system authority authentication device 70 based on the unified authentication package provided in the embodiment of the present application is applied to a background service of a target service platform, the background service is loaded with the unified authentication package, and the unified authentication package is packaged with a preconfigured authentication logic, as shown in fig. 7, the device 70 includes a receiving unit 701, a calling unit 702, a determining unit 703 and a processing unit 704.

The receiving unit 701 is configured to receive a service request sent by a user through a front-end service of a target service platform; the service request carries an authority token and a target service, wherein the authority token is generated by the authority platform based on user information, a tenant identification code of the target service platform and user authority information of the user on the target service platform when the user logs in the target service platform through front-end service.

And the calling unit 702 is used for calling the authentication logic corresponding to the service request based on the service request.

A determining unit 703, configured to query the local cache if it is determined that the authority token in the service request is legal, and determine whether an authentication result of the user exists in the local cache; the local cache is used for storing the authentication result preset effective duration.

A processing unit 704, configured to return a service processing result or authentication failure information to the front-end service according to the authentication result if the service processing result or the authentication failure information exists; if not, acquiring an authentication result, and returning a service processing result or authentication failure information to the front-end service according to the authentication result.

The device provided in this embodiment may be used to perform the method of the foregoing embodiment, and its implementation principle and technical effects are similar, and will not be described herein again.

Fig. 8 is a schematic structural diagram of another enterprise-class service system authority authentication device based on a unified authentication package according to an embodiment of the present application. The enterprise-level service system authority authentication device 80 based on the unified authentication package provided in the embodiment of the present application is applied to a background service of a target service platform, the background service is loaded with the unified authentication package, and the unified authentication package is packaged with a preconfigured authentication logic, as shown in fig. 8, the device 80 includes a receiving unit 801, a calling unit 802, a determining unit 803 and a processing unit 804.

The receiving unit 801 is configured to receive a service request sent by a user through a front-end service of a target service platform; the service request carries an authority token and a target service, wherein the authority token is generated by the authority platform based on user information, a tenant identification code of the target service platform and user authority information of the user on the target service platform when the user logs in the target service platform through front-end service.

A calling unit 802, configured to call authentication logic corresponding to the service request based on the service request.

A determining unit 803, configured to query the local cache if it is determined that the authority token in the service request is legal, and determine whether an authentication result of the user exists in the local cache; the local cache is used for storing the authentication result preset effective duration.

A processing unit 804, configured to return a service processing result or authentication failure information to the front-end service according to the authentication result if the service processing result or the authentication failure information exists; if not, acquiring an authentication result, and returning a service processing result or authentication failure information to the front-end service according to the authentication result.

In one example, the processing unit 804 includes a transmit module 8041 and a receive module 8042.

A sending module 8041, configured to send a permission request carrying a permission token to a permission platform; the authority request is used for indicating the authority platform to verify the authority token, authenticating according to the user authority information obtained from the distributed cache, obtaining an authentication result and sending the authentication result to the background service.

The receiving module 8042 is configured to receive an authentication result sent by the rights platform.

In one example, the processing unit 804 also includes an update module 8043.

And the updating module 8043 is used for loading the authentication result from the permanent database and updating the authentication result into the distributed cache if the authentication result sent by the received authority platform is determined to be empty.

In one example, the call unit 802 includes a parsing module 8021 and a call module 8022.

The parsing module 8021 is configured to parse the service request, obtain the parsed service request, and determine a target service to be executed by the user.

A calling module 8022, configured to determine and call an authentication logic corresponding to the target service based on the corresponding relation between the target service and the preset service; the preset corresponding relation characterizes the corresponding relation between the target service and the authentication logic.

In one example, the determining unit 803 is specifically configured to: decrypting the authority token in the service request to obtain a decrypted authority token; and if the permission token is generated based on the user information, the tenant identification code of the target service platform and the user permission information of the user on the target service platform and the permission token is not expired, determining that the permission token in the service request is legal.

In one example, the processing unit 804 also includes a first processing module 8044 and a second processing module 8045.

The first processing module 8044 is configured to execute the service processing logic corresponding to the target service if the authentication result is determined to pass the authentication, obtain a service processing result, and return the service processing result to the front-end service.

The second processing module 8045 is configured to return authentication failure information to the front-end service if it is determined that the authentication result is authentication failure.

In one example, the authentication logic includes one or more of the following: the system comprises function authority authentication logic, data acquisition authority logic, data authority authentication tool class, user information acquisition logic, interface level authority configuration logic and back-end remote service call authentication configuration logic.

It should be noted that, it should be understood that the division of the modules of the above apparatus is merely a division of a logic function, and may be fully or partially integrated into a physical entity or may be physically separated. And these modules may all be implemented in software in the form of calls by the processing element; or can be realized in hardware; the method can also be realized in a form of calling software by a processing element, and the method can be realized in a form of hardware by a part of modules. The functions of the above data processing module may be called and executed by a processing element of the above apparatus, and may be stored in a memory of the above apparatus in the form of program codes. The implementation of the other modules is similar. In addition, all or part of the modules can be integrated together or can be independently implemented. The processing element here may be an integrated circuit with signal processing capabilities. In implementation, each step of the above method or each module above may be implemented by an integrated logic circuit of hardware in a processor element or an instruction in a software form.

Fig. 9 is a schematic structural diagram of an electronic device according to an embodiment of the present application. As shown in fig. 9, the electronic device 90 includes: a processor 901, and a memory 902 communicatively coupled to the processor.

Wherein the memory 902 stores computer-executable instructions; processor 901 executes computer-executable instructions stored in memory 902 to implement a method as in any of the preceding claims.

In the specific implementation of the electronic device described above, it should be understood that the processor may be a central processing unit (Central Processing Unit, CPU), but may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The method disclosed in connection with the embodiments of the present application may be embodied directly in hardware processor execution or in a combination of hardware and software modules in a processor.

Embodiments of the present application also provide a computer-readable storage medium having stored therein computer-executable instructions that, when executed by a processor, are configured to implement a method as in any of the preceding claims.

Those of ordinary skill in the art will appreciate that: all or part of the steps for implementing the method embodiments described above may be performed by computer instruction related hardware. The foregoing program may be stored in a computer readable storage medium. The program, when executed, performs steps including the method embodiments described above; and the aforementioned storage medium includes: various media that can store program code, such as ROM, RAM, magnetic or optical disks.

Embodiments of the present application also provide a computer program product comprising a computer program for implementing a method as in any of the preceding claims when executed by a processor.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.

It is to be understood that the present application is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. The enterprise-level service system authority authentication method based on the unified authentication package is characterized in that the method is applied to a background service of a target service platform, the background service is loaded with the unified authentication package, and the unified authentication package is packaged with pre-configured authentication logic, and the method comprises the following steps:

2. The method of claim 1, wherein the obtaining the authentication result comprises:

and receiving an authentication result sent by the permission platform.

3. The method according to claim 2, wherein the method further comprises:

4. The method of claim 1, wherein invoking authentication logic corresponding to the service request based on the service request comprises:

5. The method of claim 1, wherein said determining that the rights token in the service request is legitimate comprises:

6. The method according to claim 1, wherein the returning the service processing result or authentication failure information to the front-end service according to the authentication result includes:

7. The method of any of claims 1-6, wherein the authentication logic comprises one or more of: the system comprises function authority authentication logic, data acquisition authority logic, data authority authentication tool class, user information acquisition logic, interface level authority configuration logic and back-end remote service call authentication configuration logic.

8. An enterprise-level service system authority authentication device based on a unified authentication package, wherein the device is applied to a background service of a target service platform, the background service is loaded with the unified authentication package, and pre-configured authentication logic is packaged in the unified authentication package, and the device comprises:

9. An electronic device, the electronic device comprising: a processor, and a memory communicatively coupled to the processor;

the memory stores computer-executable instructions;

the processor executes computer-executable instructions stored in the memory to implement the method of any one of claims 1-7.

10. A computer readable storage medium having stored therein computer executable instructions which when executed by a processor are adapted to carry out the method of any one of claims 1-7.