Security authentication and permission control method and device under micro application architecture and storage medium

Abstract

The application discloses a security authentication and permission control method and device under a micro application architecture and a storage medium, and relates to the technical field of security authentication and permission control. The method comprises the following steps: receiving an authentication request sent by a client to perform verification; when the authentication request is verified successfully, generating a token according to the authentication request, sending a shared session key negotiation parameter and the token to the client, and encrypting the token by using the shared session key; receiving a resource access request generated by the client according to the token to verify whether the resource access request is valid; when the resource access request is verified to be valid, generating a permission access request according to a preset user-role allocation rule and the resource access request; and comparing the permission access request with a preset permission policy to determine whether the corresponding resource can be accessed and operated. By implementing the application, more fine-grained permission control can be provided, the permission of single permission control is effectively prevented, the complexity of role management is reduced, and the possibility of role explosion is reduced. In addition, the setting of the shared session key enhances the low-coupling characteristic under the micro application architecture.

Description

Technical Field

[0001] This invention relates to the field of micro-application architecture technology, specifically to a method, apparatus, and storage medium for security authentication and access control under a micro-application architecture. Background Technology

[0002] With the rise of microapplication architecture, the challenges of identity authentication and access control in traditional monolithic application scenarios are increasing. In a monolithic application system, the application is a single entity, and permissions are typically verified for all requests. However, in a microapplication architecture, an application is broken down into several microapplications, each of which needs to verify and control access, and each microapplication needs to clearly identify the current user and their permissions.

[0003] However, most existing access verification and control methods are based on tokens for access verification. But as the number of accesses increases, the number of tokens in various scenarios will become larger and larger. At the same time, token verification configurations need to be deployed in authentication servers, gateways, and microservices. This will consume more time and space in token management, which is not conducive to efficient access and control of micro-applications. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a method, apparatus and storage medium for security authentication and access control under a micro-application architecture, in order to solve the technical problem that token management in the prior art consumes more time and space, which is not conducive to efficient access and control of micro-applications.

[0005] The technical solution proposed in this invention is as follows:

[0006] The first aspect of this invention provides a security authentication and access control method under a micro-application architecture, comprising: receiving and verifying an authentication request sent by a client; when the authentication request is successfully verified, generating a token based on the authentication request, sending a shared session key negotiation parameter and the token to the client, wherein the token is encrypted using a shared session key; receiving and verifying the validity of a resource access request generated by the client based on the token; when the resource access request is verified as valid, generating an access permission request based on a preset user-role allocation rule and the resource access request; and determining whether the user has the right to access and operate the corresponding resource by comparing the access permission request with a preset access permission policy.

[0007] Optionally, receiving an authentication request sent by a client for verification includes: receiving an authentication request sent by a client, the authentication request including user identity, client public key, client temporary key negotiation public key, and client private key signature, wherein the client private key signature is obtained by signing the client temporary key negotiation public key after hash calculation using an asymmetric algorithm and the client private key; performing a hash calculation on the client temporary key negotiation public key to obtain a first result and signing the hashed client temporary key negotiation public key using the client public key and an asymmetric encryption algorithm to obtain a second result; comparing the first result with the hashed client temporary key negotiation public key and comparing the second result with the client private key to obtain a first-level identity authentication result; and verifying the user identity to obtain a second-level identity authentication result.

[0008] Optionally, when the authentication request is successfully verified, a token is generated based on the authentication request, and the shared session key negotiation parameters and the token are sent to the client. The token is encrypted using the shared session key, including: when both the first-level and second-level identity authentication results are passed, generating an identity authentication string and a basic role based on the user's identity; calculating a shared session key based on the key negotiation information in the authentication request and the gateway temporary key negotiation private key; encrypting the identity authentication string and the basic role using a symmetric algorithm based on the shared session key to generate a token; and sending the token and the gateway temporary key negotiation public key as shared session key negotiation parameters to the client.

[0009] Optionally, verifying the validity of a resource access request generated by the client based on the token includes: receiving a resource access request generated by the client based on the token, wherein the resource access request includes an access token and an operation request for the resource, wherein the access token includes data obtained by decrypting the token using a shared session key calculated by the client using shared session key negotiation parameters, a timestamp, and access restriction parameters; performing a first-level verification on the data obtained by decrypting the token; performing a second-level verification on the timestamp; and determining whether the resource access request is a replay attack request based on the access restriction parameters and cached data to complete a third-level verification.

[0010] Optionally, after the resource access request is verified as valid, generating an access permission request based on a preset user-role allocation rule and the resource access request includes: after the resource access request is verified as valid, assigning a role based on the user's identity and the preset user-role allocation rule; and generating an access permission request based on the assigned role and the resource access request.

[0011] Optionally, determining whether an individual has the right to access and operate the corresponding resource by comparing the access request with a preset role-permission allocation rule includes: determining the permissions satisfied by the assigned role based on the assigned role in the access request and the preset role-permission allocation rule, wherein the preset role-permission allocation rule includes permissions when the role satisfies resource attribute restrictions and environment attribute restrictions; and comparing the permissions satisfied by the assigned role with the resource operation request in the resource access request to determine whether an individual has the right to access and operate the corresponding resource.

[0012] Optionally, the security authentication and access control method under this micro-application architecture also includes: determining whether to revoke the corresponding permissions based on preset user-role reclamation rules and preset role-permission revocation rules.

[0013] Optionally, before verifying the authentication request sent by the client, the method further includes: receiving a user registration request sent by the client, wherein the user registration request includes the user's registration subject attributes and user identity; returning a user registration success information value to the client; and generating a preset user-role assignment rule based on the subject attributes and / or the subject attributes of the micro-application.

[0014] A second aspect of this invention provides a security authentication and access control device under a micro-application architecture, comprising: a first request verification module, configured to receive and verify authentication requests sent by a client; a token generation module, configured to generate a token based on the authentication request when the authentication request is successfully verified, and send a shared session key negotiation parameter and the token to the client, wherein the token is encrypted using the shared session key; a second request verification module, configured to receive and verify the validity of a resource access request generated by the client based on the token; a third request generation module, configured to generate an access permission request based on a preset user-role allocation rule and the resource access request after the resource access request is verified as valid; and a decision module, configured to compare the access permission request with a preset access permission policy to determine whether the user has the right to access and operate the corresponding resource.

[0015] Optionally, the first request verification module is specifically configured to: receive an authentication request sent by the client, the authentication request including user identity, client public key, client temporary key negotiation public key, and client private key signature, wherein the client private key signature is obtained by signing the client temporary key negotiation public key after hash calculation using an asymmetric algorithm and the client private key; perform hash calculation on the client temporary key negotiation public key to obtain a first result and sign the client temporary key negotiation public key after hash calculation using the client public key and an asymmetric encryption algorithm to obtain a second result; compare the first result with the client temporary key negotiation public key after hash calculation and compare the second result with the client private key to obtain a first-level identity authentication result; and verify the user identity to obtain a second-level identity authentication result.

[0016] Optionally, the token generation module is specifically used to: generate an identity authentication string and a basic role based on the user's identity when both the first-level and second-level identity authentication results are passed; calculate a shared session key based on the key negotiation information in the authentication request and the gateway temporary key negotiation private key; encrypt the identity authentication string and the basic role using a symmetric algorithm based on the shared session key to generate a token; and send the token and the gateway temporary key negotiation public key as shared session key negotiation parameters to the client.

[0017] Optionally, the second request verification module is specifically used for: receiving a resource access request generated by the client based on a token, the resource access request including an access token and an operation request for the resource, the access token including data obtained by decrypting the token using a shared session key calculated by the client using shared session key negotiation parameters, a timestamp, and access restriction parameters; performing a first-level verification on the data obtained by decrypting the token; performing a second-level verification on the timestamp; and determining whether the resource access request is a replay attack request based on the access restriction parameters and cached data to complete a third-level verification.

[0018] Optionally, the third request generation module is specifically used for: after verifying the validity of the resource access request, assigning a role according to the user's identity and a preset user-role allocation rule; and generating an access permission request based on the assigned role and the resource access request.

[0019] Optionally, the decision module is specifically used to: determine the permissions satisfied by the assigned role based on the assigned role in the permission access request and the preset role-permission allocation rules, wherein the preset role-permission allocation rules include the permissions when the role satisfies resource attribute restrictions and environment attribute restrictions; compare the permissions satisfied by the assigned role with the operation requests for the resource in the resource access request to determine whether the role has the right to access and operate the corresponding resource.

[0020] Optionally, the security authentication and access control device under this micro-application architecture also includes: a revocation module, used to determine whether to revoke the corresponding permissions based on preset user-role reclamation rules and preset role-permission revocation rules.

[0021] Optionally, the security authentication and access control device under this micro-application architecture further includes: a registration module, specifically used to receive a user registration request sent by the client, wherein the user registration request includes the user's registration subject attributes and user identity; return a user registration success information value to the client; and generate a preset user-role assignment rule based on the subject attributes and / or the subject attributes of the micro-application.

[0022] A third aspect of this invention provides a security authentication and access control system under a micro-application architecture, comprising: a client, a gateway, an access control center, and a micro-application group. The gateway receives and verifies authentication requests sent by the client. When the authentication request is successfully verified, the gateway generates a token based on the authentication request and sends a shared session key negotiation parameter and the token to the client. The token is encrypted using the shared session key. The gateway receives and verifies the validity of resource access requests generated by the client based on the token. When the resource access request is verified as valid, the gateway sends the resource access request to the access control center. The access control center generates an access request based on a preset user-role allocation rule and the resource access request. The access control center compares the access request with a preset access policy to determine whether the user has the right to access and operate the corresponding resource. When the user has the right to access and operate the corresponding resource, the access request is sent to the micro-application group.

[0023] A fourth aspect of the present invention provides a computer-readable storage medium storing computer instructions for causing the computer to perform the security authentication and access control method under the micro-application architecture as described in the first aspect and any one of the first aspects of the present invention.

[0024] A fifth aspect of the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the security authentication and access control method under the micro-application architecture as described in the first aspect and any one of the first aspects of the present invention.

[0025] The technical solution provided by this invention has the following effects:

[0026] The security authentication and access control method, apparatus, and storage medium provided in this invention for a micro-application architecture achieve user authentication through authentication request verification; token validity through resource access request verification; and access permission verification through access permission request. Thus, secure access to micro-applications is achieved through this security authentication and access control method. Simultaneously, by pre-setting user-role allocation rules and pre-setting role-permission allocation rules, more granular access control can be provided, effectively preventing single-permission control. Furthermore, role-based access control applies not only to user access control but also to access control between internal micro-applications, reducing the complexity of role management and the possibility of role explosion. In addition, the shared session key generated for encryption in each request is only used until the end of the request and its validity period is only within one access cycle. The micro-application cluster does not need to store it, and client requests also do not depend on information from the micro-application cluster, enhancing the low-coupling characteristics of the micro-application architecture and solving the thorny key management problem in symmetric encryption algorithms.

[0027] The security authentication and access control method for micro-application architecture provided in this embodiment of the invention improves the security of the authentication process by using an asymmetric signature algorithm to encrypt the data in the authentication request, since the authentication request is transmitted securely through a channel whose security is uncertain.

[0028] The security authentication and access control method under the micro-application architecture provided in this embodiment of the invention first verifies whether the authentication request was sent by the user through signature verification, i.e., two-way authentication, and finally verifies whether the user is a trusted user of the system through account and password. At the same time, three-level authentication is also performed when requesting access to resources. Thus, through multi-level authentication, the access security between the two parties can be guaranteed at a higher level, ensuring the secure authentication of both parties while ensuring that the user is a system user.

[0029] The security authentication and access control method under the micro-application architecture provided in this invention transmits communication over a secure transmission channel. Because all security information is encrypted into ciphertext using a shared session key before being sent, even if intercepted during transmission, the interceptor cannot obtain the plaintext information. The messages transmitted via key negotiation over the network contain a message digest, i.e., a signature. If a message is intercepted, altered, and then resent, its authenticity can be verified by comparing the signature. Even if a message is intercepted by a man-in-the-middle during transmission, replaced, and then sent to another party, the signature allows for verification of the message's authenticity. Furthermore, the user authentication method combines timestamps and access restriction parameters, effectively preventing both replay attacks within the timestamp range and timeout replay attacks outside the timestamp range.

[0030] Compared to purely role-based access control, this approach addresses a resource with N attributes, each with M sub-attributes. i For the case of (i∈[1,N]) attribute values, the maximum number of roles that need to be set in the security authentication and access control method under the micro-application architecture provided in this embodiment of the invention is: The maximum number of roles that need to be set based purely on role-based access control is... This significantly reduces the complexity of role management and the possibility of role explosion. Furthermore, in this method, permissions are fine-grained, based on resource and environment attributes, and are tailored to different resources. After acquiring a role, a user does not directly have access to resources; they must obtain the corresponding permissions based on the resource and environment attributes in the access request. As the system runs, when environment or resource attributes fail to meet constraints, the user's permissions will be revoked—either user-role revocation or role-permission cancellation. Under this permission control, both users and resources are represented by attributes. Any fine-grained resource permission control requirement can be fulfilled by considering user attributes, resource attributes, environment attributes, and the different relationships between them, supporting dynamic permission allocation. Moreover, permission control between users and services, as well as between services, is only related to attribute-role-permission, eliminating the need to set up multiple permission control models separately within the system.

[0031] The security authentication and access control method for micro-application architecture provided in this embodiment of the invention provides subject attributes for access control, which obtain the role set through RAP, eliminating the need to add subject attributes to the request header for each access; access control adds additional protection to the authentication result, that is, after ensuring that the request is indeed sent by the client and that the user is indeed a trusted user of the system, it further ensures that the user has certain control permissions to access the system's micro-application resources. The combination of the two will make authentication more secure and access control simpler.

[0032] The security authentication and access control method for micro-application architecture provided in this invention introduces asymmetric signature algorithms, hybrid encryption algorithms, and timestamps in authentication. In addition to enabling the micro-application system to verify user identity, it can also resist common network attacks. Attached Figure Description

[0033] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0034] Figure 1This is a flowchart of a security authentication and access control method under a micro-application architecture according to an embodiment of the present invention;

[0035] Figure 2 This is a schematic diagram illustrating the interaction of various structures in a security authentication and access control system under a micro-application architecture according to an embodiment of the present invention;

[0036] Figure 3 This is a flowchart of a hybrid encryption algorithm used in a security authentication and access control system under a micro-application architecture according to an embodiment of the present invention;

[0037] Figure 4 This is a schematic diagram of access control based on multiple attributes and roles in a security authentication and access control system under a micro-application architecture according to an embodiment of the present invention;

[0038] Figure 5 This is a structural block diagram of a security authentication and access control device under a micro-application architecture according to an embodiment of the present invention;

[0039] Figure 6 This is a schematic diagram of the structure of a computer-readable storage medium provided according to an embodiment of the present invention;

[0040] Figure 7 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present invention. Detailed Implementation

[0041] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0042] The terms "first," "second," "third," "fourth," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0043] According to embodiments of the present invention, a security authentication and access control method under a micro-application architecture is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0044] This embodiment provides a security authentication and access control method under a micro-application architecture, which can be used in electronic devices such as computers, mobile phones, and tablets. Figure 1 This is a flowchart of a security authentication and access control method under a micro-application architecture according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0045] Step S101: Receive the authentication request sent by the client and verify it; specifically, when a user accesses a micro-application or a micro-application in a micro-application cluster, the user's identity is first authenticated, that is, the user first sends an authentication request through the client, and the authentication request is received by the gateway at the micro-application entry point to verify the user's identity.

[0046] Step S102: When the authentication request is successfully verified, a token is generated according to the authentication request, and the shared session key negotiation parameters and the token are sent to the client. The token is encrypted using the shared session key. Specifically, when the gateway approves the authentication request, it issues an encrypted stateless strong token to the user.

[0047] Step S103: Receive the resource access request generated by the client based on the token and verify its validity; specifically, after the client receives the token, it generates a shared session key based on the received shared session key negotiation parameters, uses the shared session key to decrypt the received token, and uses the decrypted data combined with the resource operation request to generate a resource access request, which is then sent back to the gateway; the gateway receives the resource access request and verifies whether the data in it is valid.

[0048] Step S104: After the resource access request is verified to be valid, an access permission request is generated according to the preset user-role allocation rules and the resource access request. Specifically, after the gateway verifies the data to be valid, it forwards the resource access request to the access control center. The access control center has pre-generated preset user-role allocation rules and preset role-permission allocation rules. When it receives the resource access request, it assigns a role to the user based on the user identity in the resource access request and the preset user-role allocation rules, and then generates an access permission request again.

[0049] Step S105: Compare the access request with the preset role-permission allocation rules to determine whether the user has the right to access and operate the corresponding resource. Specifically, the access center generates corresponding permissions based on the role assigned in the access request and the preset role-permission allocation rules. It then compares these permissions with the resource operation requests in the resource access request to determine whether the user has the right to access and operate the corresponding resource. If the user is determined to have the right to access and operate the corresponding resource, the access request is sent to the micro-application group, which then returns the corresponding resource to the client based on the access request.

[0050] The security authentication and access control method for micro-application architecture provided in this invention verifies user identity through authentication request verification, token validity through resource access request verification, and access permissions through access request verification. Thus, secure access to micro-applications is achieved through this security authentication and access control method. Simultaneously, by pre-setting user-role allocation rules and pre-setting role-permission allocation rules, more granular access control can be provided, effectively preventing single-permission control. Furthermore, role-based access control applies not only to user access control but also to access control between internal micro-applications, reducing the complexity of role management and the possibility of role explosion. In addition, the shared session key generated for encryption in each request is only used until the end of the request and its validity period is only within one access cycle. The micro-application cluster does not need to store it, and client requests also do not depend on information from the micro-application cluster, enhancing the low-coupling characteristics of the micro-application architecture and solving the thorny key management problem in symmetric encryption algorithms.

[0051] In one embodiment, receiving and verifying an authentication request sent by a client includes the following steps:

[0052] Step S201: Receive an authentication request sent by the client. The authentication request includes the user's identity, the client's public key, the client's temporary key negotiation public key, and the client's private key signature. The client's private key signature is obtained by signing the client's temporary key negotiation public key after hash calculation using an asymmetric algorithm and the client's private key. Specifically, the authentication request can be represented as AuthRequest = {UID, pb c p, b, key c key c Sign}, where UID represents the user ID, i.e., the user's identity, pb c This represents the client's public key, p represents the negotiated large prime number, b represents a primitive root of p, and key. c This indicates the client's temporary key for negotiating the public key, key. c Sign indicates that the client has signed the private key.

[0053] The client generates the authentication request in the following way: the client randomly generates a large prime number p and its primitive root g, and the client's temporary key negotiates the private key R. c The client negotiates the private key R based on the temporary key. c Calculate the client's temporary key to negotiate the public key. The key is obtained by processing the client's temporary key and negotiating the public key using a one-way hash function. c Hash = HASH(key) c The client's private key signature key is obtained by signing the one-way hash value using an asymmetric algorithm such as RSA (Rivest-Shamir-Adleman) signature algorithm with the client's private key. c Sign is the key. c Sign = RSA(key) c Hash||pv c ), where the client's private key PV c With client public key pb c Together, they form a key pair for the RSA signature algorithm, which negotiates the large prime number p and its primitive root g, and the client's temporary key and public key key. c Signature key c The Sign is added to the authentication request sent to the gateway.

[0054] Step S202: The client's temporary key negotiation public key is hashed to obtain a first result, and the hashed client's temporary key negotiation public key is signed using the client's public key and an asymmetric encryption algorithm to obtain a second result. Specifically, after receiving an authentication request, the gateway filters out the pb from the authentication request. c ,key c ,key c Sign, for key c The first result key is obtained by using the same one-way hash function as the client. c Hash′=HASH(key c The second result key is obtained through asymmetric encryption algorithms such as RSA desealing algorithm. c Hash″ = RSA(key) c Sign||pb c ).

[0055] Step S203: Compare the first result with the hashed client temporary key negotiation public key and compare the second result with the client private key to obtain the first-level authentication result; wherein, the hashed client temporary key negotiation public key can be obtained by comparing the key. c Sign decryption is obtained, then the decrypted key is obtained. c Hash and first result keyc Hash′=HASH(key c Compare the two results to determine if they are the same; simultaneously, set the second result as the key. c Hash″ = RSA(key) c Sign||pb c ) and the received key c The Signature Comparison checks if the two signatures are identical. The results of both comparisons constitute the Level 1 authentication result. If both comparisons pass, the signature verification is successful.

[0056] Step S204: Obtain a secondary identity authentication result by verifying the user's identity. The secondary authentication specifically involves account and password verification, which filters the user's identity UID from the authentication request and verifies whether a user with the same UID exists in the third-party account and password verification system. If a user exists, then that user is indeed a trusted user of the system, thus obtaining the secondary identity authentication result.

[0057] The security authentication and access control method for micro-application architecture provided in this embodiment of the invention improves the security of the authentication process by using an asymmetric signature algorithm to encrypt the data in the authentication request, since the authentication request is transmitted securely through a channel whose security is uncertain.

[0058] In one embodiment, when the authentication request is successfully verified, a token is generated based on the authentication request, and the shared session key negotiation parameters and the token are sent to the client. The token is encrypted using the shared session key, and the process includes the following steps:

[0059] Step S301: When both the first-level and second-level identity authentication results are passed, an identity authentication string and basic roles are generated based on the user's identity; specifically, when both the first-level and second-level identity authentication results are passed, the gateway generates an identity authentication string, i.e., JWT (JSON Web Token) identity authentication, for the successfully authenticated user and constructs a basic role set RG. UID ={role0}, where role0 is the basic role and includes the most basic permissions for itself, such as changing the password and changing the username.

[0060] Step S302: Calculate the shared session key based on the key negotiation information in the authentication request and the gateway's temporary key negotiation private key; in order to generate an encrypted token subsequently, the gateway first generates the shared session key based on the key negotiation information in the received authentication request. Wherein, the authentication request AuthRequest = {UID, pb...} c p, b, key c key cThe authentication request includes the negotiated large prime number p and its primitive root g, as well as the client's temporary key and the negotiated public key key. c The gateway filters out the key negotiation information upon receiving the authentication request, and then negotiates the private key R based on the randomly generated gateway temporary key. g Calculate the gateway temporary key negotiation public key Simultaneously, a shared session key is generated based on the public key negotiated with the gateway's temporary key. The shared session key is used as the key for the symmetric algorithm DES (Data Encryption Standard).

[0061] Step S303: Encrypt the authentication string and basic role using a symmetric algorithm based on the shared session key to generate a token; after generating the shared session key, the gateway uses the shared session key to encrypt the authentication string and basic role using a symmetric algorithm such as DES to obtain the token token = DES(JWT||RG). UID ||key share ).

[0062] Step S304: Send the token and the gateway temporary key negotiation public key as shared session key negotiation parameters to the client.

[0063] In one implementation, verifying the validity of a resource access request generated by a client based on a token includes the following steps:

[0064] Step S401: Receive a resource access request generated by the client based on a token. The resource access request includes an access token and a request to operate on the resource. The access token includes data obtained by decrypting the token using the shared session key calculated by the client using the shared session key negotiation parameters, a timestamp, and access restriction parameters. Specifically, upon receiving the token and the gateway temporary key negotiation public key, the client... g Calculate the shared session key The key is used as the DES key; then, the received token is decrypted using the DES decryption algorithm and the calculated shared session key. Based on the decryption result, the access token is obtained, i.e., (UID||JWT||RG). UID ||timestamp||nonce)=DES(access token ||key share ), where access tokenThis indicates a stateless strong token, also known as an access token. It is generated by encrypting the decrypted token data along with parameters such as a timestamp and the access restriction parameter nonce (a randomly generated UUID (Universally Unique Identifier, different for each request to strengthen its statelessness). This results in an access token. token =DES(UID||JWT||RG) UID ||timestamp||nonce||key share ).

[0065] The client generates a resource access request (AccessRequest = {access...}) using an access token and a request to manipulate the resource. token The generated resource access request is sent to the gateway, where Att(E) = {(EA1, value1), (EA2, value2), (EA3, value3), ..., (EA...}. n value n} represents the access request attribute, where (name, val) represents the attribute value pair, name represents the attribute name, and val represents the attribute value. Att(R) = {(RA1, value1), (RA2, value2), (RA3, value3), ..., (RA...} n value n )} represents the resource attribute of the access request, and operation represents the operation of the access request on the resource.

[0066] Step S402: Perform first-level verification on the data obtained from token decryption; specifically, when the gateway receives a resource access request, it performs third-level verification. First, the validity of the JWT obtained from token decryption is verified: one, whether the user ID in the decoded JWT verification payload is the same as the ID in the decryption; two, whether the decoded JWT verification is within its validity period.

[0067] Step S403: Perform secondary verification on the timestamp; the verification of the timestamp specifically includes verifying whether the timestamp is less than the JWT expiration time; and determining whether the difference between the decrypted timestamp and the current timestamp is less than 60s, that is, considering an HTTP request to be no more than 60s.

[0068] Step S404: Based on the access restriction parameters and cached data, determine whether the resource access request is a replay attack request to complete the three-level verification. Specifically, when verifying the access restriction parameters, check whether the received access restriction parameters are in the cache server. If they exist, it indicates that the resource access request is a replay attack request, and the access fails; otherwise, consider the request a valid resource access request, save the received nonce in the cache server, and record the last modification time; when the next resource access request is received, determine whether the time difference between the current nonce and the last saved nonce in the cache server is greater than 60 seconds. If it exceeds 60 seconds, clear the cache server and save it again.

[0069] It should be noted that the nonce for each resource access request is randomly generated, i.e., a "unique" UUID. This means that the probability of two identical UUIDs appearing within 60 seconds is almost negligible. Even if the nonce is eavesdropped on by an attacker, the attacker can only obtain an encrypted string containing information and cannot change its content. The attacker can only obtain the resource by replaying the request. However, since the nonce of the request has already been stored in the cache server, the system considers the request to be a replay request, i.e., the request fails.

[0070] Specifically, after the gateway performs three-level verification on the received resource access request, if all three levels of verification are valid, the resource access request is forwarded to the access control center.

[0071] The security authentication and access control method under the micro-application architecture provided in this embodiment of the invention first verifies whether the authentication request was sent by the user through signature verification, i.e., two-way authentication, and finally verifies whether the user is a trusted user of the system through account and password. At the same time, three-level authentication is also performed when requesting access to resources. Thus, through multi-level authentication, the access security between the two parties can be guaranteed at a higher level, ensuring the secure authentication of both parties while ensuring that the user is a system user.

[0072] The security authentication and access control method under the micro-application architecture provided in this invention transmits communication over a secure transmission channel. Because all security information is encrypted into ciphertext using a shared session key before being sent, even if intercepted during transmission, the interceptor cannot obtain the plaintext information. The messages transmitted via key negotiation over the network contain a message digest, i.e., a signature. If a message is intercepted, altered, and then resent, its authenticity can be verified by comparing the signature. Even if a message is intercepted by a man-in-the-middle during transmission, replaced, and then sent to another party, the signature allows for verification of the message's authenticity. Furthermore, the user authentication method combines timestamps and access restriction parameters, effectively preventing both replay attacks within the timestamp range and timeout replay attacks outside the timestamp range.

[0073] In one embodiment, before verifying the authentication request sent by the client, the method further includes: receiving a user registration request sent by the client, wherein the user registration request includes the subject attributes of the user registration and the user identity; returning a user registration success information value to the client; and generating a preset user-role assignment rule based on the subject attributes and / or the subject attributes of the micro-application.

[0074] Specifically, to ensure that role-based access control applies not only to client user access control but also to access control between internal micro-applications, the user's principal attributes are saved along with the micro-application's principal attributes. Then, the saved principal attributes are compared with Att(S) = {(SA1, value1), (SA2, value2), (SA3, value3), ..., (SA... n value n Each user and role corresponds one-to-one with a UID. When generating the preset user-role assignment rules, an attribute constraint pair lim = (name, ass) is defined, where name represents the attribute name, ass represents the constraint expression, and |S lim |Att(s) represents the evaluation of the subject attributes of subject s. If all attribute values ​​are within the range of the attribute expression, the evaluation result is true. Therefore, the preset user-role assignment rule URA includes |S lim |Att(s)=true→allow(Assign role i (to user) indicates that subject s satisfies a certain subject attribute constraint and is assigned a role. i role i Associated with the subject attribute restrictions.

[0075] Based on the preset user-role assignment rules, a role-permission assignment rule (RAP) is generated, that is, the preset role-permission assignment rule is expressed as: |R lim |Att(r)∩|E lim |Att(e)=true→allow(Assign op i to role i ), indicating role i Granting permissions to an operator that meets certain resource attribute and environment attribute restrictions. i Permission and resource attribute restrictions are associated with environment attribute restrictions.

[0076] In one embodiment, after the resource access request is verified as valid, generating an access permission request based on a preset user-role allocation rule and the resource access request includes: after the resource access request is verified as valid, assigning a role based on the user's identity and the preset user-role allocation rule; and generating an access permission request based on the assigned role and the resource access request.

[0077] Specifically, since user identity and user subject attributes are in one-to-one correspondence, and user roles are associated with subject attributes, the access control center can determine a user's role (RG) by matching the user identity with the preset user-role assignment rules. UID Based on this role and Att(R), Att(E), and operation obtained from the filtered resource access requests, a permission access request PARequest = {RG} is generated. UID ,Att(R),Att(E),operation}.

[0078] In one embodiment, determining whether an individual has the right to access and operate the corresponding resource by comparing the access request with preset role-permission allocation rules includes: determining the permissions satisfied by the assigned role based on the assigned role in the access request and the preset role-permission allocation rules, wherein the preset role-permission allocation rules include permissions for roles that satisfy resource attribute restrictions and environment attribute restrictions; comparing the permissions satisfied by the assigned role with the resource operation requests in the resource access request to determine whether an individual has the right to access and operate the corresponding resource; and determining whether to revoke the corresponding permission based on preset user-role reclamation rules and preset role-permission revocation rules.

[0079] Specifically, the permissions assigned to a role are based on the permissions of that role. i permissions op i The restricted resource attributes and environment attributes are determined, and then the determined permissions are compared with the operation requests for the resources. If the permissions match the role set... i middle Right now Users can be granted full permissions for their access requests; otherwise, users lack sufficient permissions to access the required resources. This applies to user role sets RG. UID A certain role i For a specific permission policy, where "operation" refers to the operations (op) under that role. i If the resource attributes and environment attributes also meet the environment and resource restrictions under this policy, then the role can obtain this permission; for the user role set RG UID All roles execute the above decision. If all conditions are met, the user is granted full permissions; otherwise, the user lacks sufficient permissions to access the required resources.

[0080] In addition to the preset user-role assignment rules and preset role-permission assignment rules, there are also preset user-role reclamation rules and preset role-permission revocation rules. Among these, the user-role reclamation rules... This indicates that the subject s possesses a role. i However, if the existing subject attributes do not meet the subject attribute restrictions, the role will be revoked; preset role-permission revocation rules, Indicates role i If a user possesses permissions under the original environment and resource attributes, but these permissions no longer meet the current environment or resource attribute restrictions, then those permissions will be revoked. Therefore, during user access, if the environment or resource attributes no longer meet the constraints, the user's permissions will be cancelled—either the user-role is revoked or the role-permission is withdrawn.

[0081] Compared to purely role-based access control, this approach addresses a resource with N attributes, each with M sub-attributes. i For the case of (i∈[1,N]) attribute values, the maximum number of roles that need to be set in the security authentication and access control method under the micro-application architecture provided in this embodiment of the invention is: The maximum number of roles that need to be set based purely on role-based access control is... This significantly reduces the complexity of role management and the possibility of role explosion. Furthermore, in this method, permissions are fine-grained, based on resource and environment attributes, and are tailored to different resources. After acquiring a role, a user does not directly have access to resources; they must obtain the corresponding permissions based on the resource and environment attributes in the access request. As the system runs, when environment or resource attributes fail to meet constraints, the user's permissions will be revoked—either user-role revocation or role-permission cancellation. Under this permission control, both users and resources are represented by attributes. Any fine-grained resource permission control requirement can be fulfilled by considering user attributes, resource attributes, environment attributes, and the different relationships between them, supporting dynamic permission allocation. Moreover, permission control between users and services, as well as between services, is only related to attribute-role-permission, eliminating the need to set up multiple permission control models separately within the system.

[0082] The security authentication and access control method for micro-application architecture provided in this embodiment of the invention provides subject attributes for access control, which obtain the role set through RAP, eliminating the need to add subject attributes to the request header for each access; access control adds additional protection to the authentication result, that is, after ensuring that the request is indeed sent by the client and that the user is indeed a trusted user of the system, it further ensures that the user has certain control permissions to access the system's micro-application resources. The combination of the two will make authentication more secure and access control simpler.

[0083] The security authentication and access control method for micro-application architecture provided in this invention introduces asymmetric signature algorithms, hybrid encryption algorithms, and timestamps in authentication. In addition to enabling the micro-application system to verify user identity, it can also resist common network attacks.

[0084] This invention also provides a security authentication and access control system under a micro-application architecture, including: a client, a gateway, an access control center, and a micro-application group. The gateway receives and verifies authentication requests sent by the client. When the authentication request is successfully verified, the gateway generates a token based on the authentication request and sends the shared session key negotiation parameters and the token to the client. The token is encrypted using the shared session key. The gateway receives and verifies the validity of resource access requests generated by the client based on the token. When the resource access request is verified as valid, the gateway sends the resource access request to the access control center. The access control center generates an access request based on a preset user-role allocation rule and the resource access request. The access control center compares the access request with a preset access policy to determine whether the user has the right to access and operate the corresponding resource. When the user has the right to access and operate the corresponding resource, the access request is sent to the micro-application group.

[0085] The security authentication and access control system for micro-application architecture provided in this invention verifies user identity through authentication requests, validates token validity through resource access requests, and verifies permissions through access requests. Thus, secure access to micro-applications is achieved through this security authentication and access control system. Simultaneously, by pre-setting user-role allocation rules and pre-setting role-permission allocation rules, more granular access control can be provided, effectively preventing single-permission control. Furthermore, role-based access control applies not only to user access control but also to access control between internal micro-applications, reducing the complexity of role management and the possibility of role explosion. In addition, the shared session key generated for encryption in each request is only used until the end of the request and its validity period is only within one access cycle. The micro-application cluster does not need to store it, and client requests also do not depend on information from the micro-application cluster, enhancing the low-coupling characteristics of the micro-application architecture and solving the thorny key management problem in symmetric encryption algorithms.

[0086] In one implementation, such as Figure 2 As shown, the security authentication and access control system under this micro-application architecture adopts the following process to implement security authentication and access control:

[0087] S1, when a user registers for the first time to become a user of the system, the registration request is intercepted at the gateway.

[0088] S2: After the gateway intercepts the request, it saves the necessary information required for user registration, namely the main attributes, and associates them with the ID when saving.

[0089] S3, the gateway returns the registration success and saved information to the client and the user.

[0090] S4, the user initiates an authentication request through the client, the authentication request including the user ID, pb c The client uses a long-term public key, p is a large prime number to negotiate, b is a primitive root of p, and key is... c Client temporary key negotiation public key, key c The signature obtained from the Sign client's private key.

[0091] S5 performs multi-level authentication on authentication requests at the gateway, including signature verification and account / password verification. Signature verification ensures that the request was indeed sent by the client, and account / password verification ensures that the user is indeed a trusted user of the system.

[0092] S6: If any level of multi-level authentication fails, i.e. authentication failure, an error message is returned to the client and the user is notified.

[0093] S7. If all multi-level authentications are successful, the request will be forwarded to the access control center, where the user ID needs to be filtered out as the unique identifier for the role set creation in the access control center.

[0094] S8, the access control center creates a basic role set and adds basic roles for successfully authenticated users. The basic role permissions include, but are not limited to, changing passwords and changing usernames.

[0095] S9 returns the user's role set to the gateway.

[0096] S10, generate a shared session key through the client shared session key negotiation parameters in the authentication request, generate a token for the user and encrypt it.

[0097] S11, the token and gateway shared session key negotiation parameters are returned to the client, and the client generates a shared session key based on them.

[0098] S12, the user initiates a resource access request through the client, whereby the resource access request includes a stateless strong token access. token (The data is encrypted by combining the decrypted token with the timestamp and the access restriction parameter nonce), access request attribute Att(E), access request resource attribute Att(R), and access request operation on the resource.

[0099] S13, the gateway verifies the validity of the request and token, including three levels of verification: verifying the validity of the JWT, verifying the validity of the timestamp, and verifying the validity of the access restriction parameter nonce.

[0100] S14. If any level of the three-level verification fails, i.e., verification fails, return an error message to the client and inform the user.

[0101] If all three levels of verification are successful, S15 will forward the request to the access control center, where the user ID needs to be filtered out as the unique identifier for adding roles to the role set in the access control center.

[0102] S16, the access control center adds roles to users and creates access permission requests based on the subject attributes. The access permission requests include: user role set and Att(R), Att(E), and operation obtained by filtering client resource access requests. The policy decision result is obtained by comparing with the policies in the policy library, i.e., the preset role-permission allocation rules.

[0103] S17 If the access permission request policy decision result is denied, the resource access request fails, the user does not have the right to access the required resource, and the gateway returns an error message to the client and informs the user.

[0104] S18 If the access permission request policy decision result is allowed, the resource access request is successful, the user has the right to access and operate the required resources, and the request is forwarded to the corresponding micro-application through the gateway;

[0105] S19, the micro-application receives the access permission request and policy decision result, obtains the requested resource and performs related operations;

[0106] S20: The micro-application returns the resources required by the user and the results of the operation on the resources to the client through the gateway and informs the user.

[0107] In one embodiment, during data transmission between the gateway and the client, a signature-based key negotiation hybrid encryption algorithm is used to prevent network attacks and ensure data security during channel transmission, such as... Figure 3 As shown, this hybrid encryption algorithm is implemented using the following process:

[0108] S21, Alice publishes her public key pb A Alice and Bob share a large prime number p and its primitive root g.

[0109] S22, Alice generates a random number a less than p, and calculates A = g. amod p, Ahash = H(A), the hash function is SHA-256, and the signature algorithm is RSA to obtain Asign = RSA(Ahash||pv). A Send Assign along with A to Bob.

[0110] S23, Bob generates a random number b less than p, and calculates B = g. b mod p; After Bob receives Assign and A, he first needs to verify Alice's identity: through the public key pb A The interpretation yields Ahash′=RSA(Asign||pb) A Ahash = H(A), and after successful verification, a shared key K = A is generated. b mod p.

[0111] S24, Bob uses the shared key K to encrypt the data to be transmitted, cipher = AES(data||K), using the AES encryption algorithm, and sends cipher and B to Alice.

[0112] S25, after Alice receives the cipher and B, she calculates K′ = B. a The shared key is obtained by modulo p, and the data to be transmitted, data = AES(cipher||K′), can be obtained by decrypting cipher with this key. The AES encryption algorithm can also be replaced by other symmetric encryption algorithms such as DES. This embodiment of the invention does not limit the specific choice of symmetric algorithm.

[0113] In addition, such as Figure 4 As shown, in this system, users or microapplications can be the subjects of resource access requests, and their role sets are associated with their subject attribute S. A role is a different division of labor or position within an organization or system; a subject obtains one or more roles through its subject attribute. Role operation permissions are associated with resource attribute R and environment attribute E. A microapplication is the object / resource of the resource access request, and a role obtains one or more permissions for the corresponding microapplication resource through resource and environment attributes. That is, there are many-to-many mapping relationships between users and roles, and between roles and permissions, all associated through attributes. By determining the role of a user or microapplication through subject attributes and controlling the permissions of roles through resource and environment attributes, the logical separation of subjects and permissions is achieved, refining the granularity of permission control and improving the security of the microapplication system.

[0114] This invention also provides a security authentication and access control device for a micro-application architecture, such as... Figure 5 As shown, the device includes:

[0115] The first request verification module is used to receive and verify authentication requests sent by the client; for details, please refer to the corresponding part of the above method embodiment, which will not be repeated here.

[0116] The token generation module is used to generate a token based on the authentication request when the authentication request is successfully verified, and send the shared session key negotiation parameters and the token to the client. The token is encrypted using the shared session key. For details, please refer to the corresponding part of the above method embodiment, which will not be repeated here.

[0117] The second request verification module is used to receive resource access requests generated by the client based on the token and verify whether they are valid; for details, please refer to the corresponding part of the above method embodiment, which will not be repeated here.

[0118] The third request generation module is used to generate a permission access request based on the preset user-role allocation rules and the resource access request after the resource access request has been verified as valid; for details, please refer to the corresponding part of the above method embodiment, which will not be repeated here.

[0119] The decision module is used to compare the access request with a preset permission policy to determine whether the user has the right to access and operate the corresponding resource. For details, please refer to the corresponding section of the above method embodiment; it will not be repeated here.

[0120] The security authentication and access control device for micro-application architecture provided in this embodiment of the invention verifies user identity through authentication request verification, token validity through resource access request verification, and access permissions through access request verification. Thus, secure access to micro-applications is achieved through this security authentication and access control device. Simultaneously, by pre-setting user-role allocation rules and pre-setting role-permission allocation rules, more granular access control can be provided, effectively preventing single-permission control. Furthermore, role-based access control applies not only to user access control but also to access control between internal micro-applications, reducing the complexity of role management and the possibility of role explosion. In addition, the shared session key generated for encryption in each request is only used until the end of the request and its validity period is only within one access cycle. The micro-application cluster does not need to store it, and client requests also do not depend on information from the micro-application cluster, enhancing the low-coupling characteristics of the micro-application architecture and solving the thorny key management problem in symmetric encryption algorithms.

[0121] For a detailed description of the functions of the security authentication and access control device under the micro-application architecture provided in the embodiments of the present invention, please refer to the description of the security authentication and access control method under the micro-application architecture in the above embodiments.

[0122] Optionally, the first request verification module is specifically configured to: receive an authentication request sent by the client, the authentication request including user identity, client public key, client temporary key negotiation public key, and client private key signature, wherein the client private key signature is obtained by signing the client temporary key negotiation public key after hash calculation using an asymmetric algorithm and the client private key; perform hash calculation on the client temporary key negotiation public key to obtain a first result and sign the client temporary key negotiation public key after hash calculation using the client public key and an asymmetric encryption algorithm to obtain a second result; compare the first result with the client temporary key negotiation public key after hash calculation and compare the second result with the client private key to obtain a first-level identity authentication result; and verify the user identity to obtain a second-level identity authentication result.

[0123] Optionally, the token generation module is specifically used to: generate an identity authentication string and a basic role based on the user's identity when both the first-level and second-level identity authentication results are passed; calculate a shared session key based on the key negotiation information in the authentication request and the gateway temporary key negotiation private key; encrypt the identity authentication string and the basic role using a symmetric algorithm based on the shared session key to generate a token; and send the token and the gateway temporary key negotiation public key as shared session key negotiation parameters to the client.

[0124] Optionally, the second request verification module is specifically used for: receiving a resource access request generated by the client based on a token, the resource access request including an access token and an operation request for the resource, the access token including data obtained by decrypting the token using a shared session key calculated by the client using shared session key negotiation parameters, a timestamp, and access restriction parameters; performing a first-level verification on the data obtained by decrypting the token; performing a second-level verification on the timestamp; and determining whether the resource access request is a replay attack request based on the access restriction parameters and cached data to complete a third-level verification.

[0125] Optionally, the third request generation module is specifically used for: after verifying the validity of the resource access request, assigning a role according to the user's identity and a preset user-role allocation rule; and generating an access permission request based on the assigned role and the resource access request.

[0126] Optionally, the decision module is specifically used to: determine the permissions satisfied by the assigned role based on the assigned role in the permission access request and the preset role-permission allocation rules, wherein the preset role-permission allocation rules include the permissions when the role satisfies resource attribute restrictions and environment attribute restrictions; compare the permissions satisfied by the assigned role with the operation requests for the resource in the resource access request to determine whether the role has the right to access and operate the corresponding resource.

[0127] Optionally, the security authentication and access control device under this micro-application architecture also includes: a revocation module, used to determine whether to revoke the corresponding permissions based on preset user-role reclamation rules and preset role-permission revocation rules.

[0128] Optionally, the security authentication and access control device under this micro-application architecture further includes: a registration module, specifically used to receive a user registration request sent by the client, wherein the user registration request includes the user's registration subject attributes and user identity; return a user registration success information value to the client; and generate a preset user-role assignment rule based on the subject attributes and / or the subject attributes of the micro-application.

[0129] This invention also provides a storage medium, such as... Figure 6 As shown, a computer program 601 is stored on it. When executed by the processor, this program implements the steps of the security authentication and access control method under the micro-application architecture in the above embodiments. The storage medium also stores audio and video stream data, feature frame data, interactive request signaling, encrypted data, and preset data sizes. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium may also include combinations of the above types of memory.

[0130] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium can also include combinations of the above types of memory.

[0131] This invention also provides an electronic device, such as... Figure 7 As shown, the electronic device may include a processor 51 and a memory 52, wherein the processor 51 and the memory 52 may be connected via a bus or other means. Figure 7 Taking the example of a connection between China and Israel via a bus.

[0132] Processor 51 can be a central processing unit (CPU). Processor 51 can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0133] The memory 52, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the corresponding program instructions / modules in the embodiments of the present invention. The processor 51 executes various functional applications and data processing of the processor by running the non-transitory software programs, instructions, and modules stored in the memory 52, thereby implementing the security authentication and access control method under the micro-application architecture in the above method embodiments.

[0134] The memory 52 may include a program storage area and a data storage area. The program storage area may store applications required for operating the device and at least one function; the data storage area may store data created by the processor 51, etc. Furthermore, the memory 52 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 52 may optionally include memory remotely located relative to the processor 51, and these remote memories may be connected to the processor 51 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0135] The one or more modules are stored in the memory 52, and when executed by the processor 51, they perform the following: Figure 1 The security authentication and access control method under the micro-application architecture shown in the embodiment.

[0136] For specific details regarding the aforementioned electronic devices, please refer to the relevant documentation. Figure 1 The relevant descriptions and effects in the illustrated embodiments are for understanding purposes only and will not be repeated here.

[0137] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A method for security authentication and access control under a micro-application architecture, characterized in that, include: Receive authentication requests sent by clients and verify them; When the authentication request is successfully verified, a token is generated based on the authentication request. The shared session key negotiation parameters and the token are sent to the client. The token is encrypted with the shared session key. The shared session key is only used before the end of the request and its validity period is only within one access cycle. The micro-application cluster does not save it. Receive resource access requests generated by the client based on the token and verify their validity. Once the resource access request is verified to be valid, an access permission request is generated based on the preset user-role allocation rules and the resource access request. Based on the comparison between the access request and the preset access policy, it is determined whether the user has the right to access and operate the corresponding resources. Receive and verify authentication requests sent by clients, including: The system receives an authentication request sent by a client. The authentication request includes the user's identity, the client's public key, the client's temporary key negotiation public key, and the client's private key signature. The client's private key signature is obtained by signing the client's temporary key negotiation public key after hash calculation using an asymmetric algorithm and the client's private key. The first result is obtained by hashing the client's temporary key negotiation public key, and the second result is obtained by signing the hashed client's temporary key negotiation public key using the client's public key and an asymmetric encryption algorithm. The first-level authentication result is obtained by comparing the first result with the hashed client temporary key negotiation public key and by comparing the second result with the client private key signature. The secondary identity authentication result is obtained by verifying the user's identity.

2. The security authentication and access control method under the micro-application architecture according to claim 1, characterized in that, When the authentication request is successfully verified, a token is generated based on the authentication request, and the shared session key negotiation parameters and the token are sent to the client. The token is encrypted using the shared session key and includes: When both the first-level and second-level identity authentication results are passed, an identity authentication string and basic role are generated based on the user's identity. The shared session key is calculated based on the key negotiation information in the authentication request and the gateway temporary key negotiation private key. Based on the shared session key, a symmetric algorithm is used to encrypt the authentication string and basic role to generate a token; The token and the gateway temporary key negotiation public key are sent to the client as shared session key negotiation parameters.

3. The security authentication and access control method under the micro-application architecture according to claim 1, characterized in that, Receive the client's resource access request generated based on the token and verify its validity, including: Receive a resource access request generated by the client based on a token. The resource access request includes an access token and an operation request for the resource. The access token includes data obtained by decrypting the token using the shared session key calculated by the client using the shared session key negotiation parameters, a timestamp, and access restriction parameters. Perform first-level verification on the data obtained from decrypting the token; Perform secondary verification on the timestamp; Based on the access restriction parameters and cached data, it is determined whether the resource access request is a replay attack request, thus completing the three-level verification.

4. The security authentication and access control method under the micro-application architecture according to claim 1, characterized in that, After the resource access request is verified as valid, an access permission request is generated according to the preset user-role allocation rules and the resource access request, including: Once the resource access request is verified as valid, a role is assigned based on the user's identity and the preset user-role assignment rules. Generate an access permission request based on the assigned role and the resource access request.

5. The security authentication and access control method under the micro-application architecture according to claim 4, characterized in that, Based on the comparison between the access request and the preset role-permission allocation rules, determine whether the user has the right to access and operate the corresponding resource, including: The permissions that the assigned role must satisfy are determined based on the assigned role in the permission access request and the preset role-permission allocation rules. The preset role-permission allocation rules include the permissions that the role must satisfy when it meets resource attribute restrictions and environment attribute restrictions. The permissions granted by the assigned role are compared with the resource operation requests in the resource access requests to determine whether the user has the right to access and operate the corresponding resource.

6. The security authentication and access control method under the micro-application architecture according to claim 5, characterized in that, Also includes: Determine whether to revoke the corresponding permissions based on the preset user-role recycling rules and the preset role-permission revocation rules.

7. The security authentication and access control method under the micro-application architecture according to claim 1, characterized in that, Before verifying the authentication request sent by the client, the process also includes: Receive a user registration request sent by the client, wherein the user registration request includes the user's main attributes and user identity; Return a successful user registration message to the client. Preset user-role assignment rules are generated based on the main attributes and / or the main attributes of the micro-application.

8. A security authentication and access control device under a micro-application architecture, characterized in that, include: The first request verification module is used to receive and verify authentication requests sent by the client. The token generation module is used to generate a token based on the authentication request when the authentication request is successfully verified. The shared session key negotiation parameters and the token are sent to the client. The token is encrypted with the shared session key. The shared session key is only used before the end of the request and its validity period is only within one access cycle. The micro-application cluster does not save it. The second request verification module is used to receive resource access requests generated by the client based on the token and verify whether they are valid. The third request generation module is used to generate a permission access request based on the preset user-role allocation rules and the resource access request after the resource access request has been verified as valid. The decision module is used to compare the access request with the preset access policy to determine whether the user has the right to access and operate the corresponding resources. Receive and verify authentication requests sent by clients, including: The system receives an authentication request sent by a client. The authentication request includes the user's identity, the client's public key, the client's temporary key negotiation public key, and the client's private key signature. The client's private key signature is obtained by signing the client's temporary key negotiation public key after hash calculation using an asymmetric algorithm and the client's private key. The first result is obtained by hashing the client's temporary key negotiation public key, and the second result is obtained by signing the hashed client's temporary key negotiation public key using the client's public key and an asymmetric encryption algorithm. The first-level authentication result is obtained by comparing the first result with the hashed client temporary key negotiation public key and by comparing the second result with the client private key signature. The secondary identity authentication result is obtained by verifying the user's identity.

9. A security authentication and access control system under a micro-application architecture, characterized in that, include: Client, gateway, access control center, and micro-application group, The gateway receives the authentication request sent by the client and performs verification; When the authentication request is successfully verified, the gateway generates a token based on the authentication request, sends the shared session key negotiation parameters and the token to the client, the token is encrypted with the shared session key, the shared session key is only used before the end of the request and its validity period is only within one access cycle, and the micro application cluster does not save it; The gateway receives resource access requests generated by the client based on the token and verifies whether the requests are valid. Once the resource access request is verified as valid, the gateway sends the resource access request to the permission control center, which generates a permission access request based on the preset user-role allocation rules and the resource access request. The permission control center compares the permission access request with the preset permission policy to determine whether it has the right to access and operate the corresponding resource. When it has the right to access and operate the corresponding resource, it sends the permission access request to the micro-application group. Receive and verify authentication requests sent by clients, including: The system receives an authentication request sent by a client. The authentication request includes the user's identity, the client's public key, the client's temporary key negotiation public key, and the client's private key signature. The client's private key signature is obtained by signing the client's temporary key negotiation public key after hash calculation using an asymmetric algorithm and the client's private key. The first result is obtained by hashing the client's temporary key negotiation public key, and the second result is obtained by signing the hashed client's temporary key negotiation public key using the client's public key and an asymmetric encryption algorithm. The first-level authentication result is obtained by comparing the first result with the hashed client temporary key negotiation public key and by comparing the second result with the client private key signature. The secondary identity authentication result is obtained by verifying the user's identity.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the security authentication and access control method under the micro-application architecture as described in any one of claims 1-7.

11. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the security authentication and access control method under the micro-application architecture as described in any one of claims 1-7.

Images