CN117157940A - Token management for asynchronous request replies - Google Patents

Abstract

The expiration of the token is managed for requests in an asynchronous request reply mode of communication. If the token in the request expires, the operation to be performed performs the operation with the new token. The new token is obtained from a status check that is sent to a different location than the initial request.

Description

Token management for asynchronous request replies

Background

Identity and Access Management (IAM) generally includes a framework of policies and technologies for ensuring that authorized personnel in an enterprise are able to properly access technical resources. Authentication (AuthN) and authorization (AuthZ) are two processes in an IAM, where AuthN verifies the identity of a user and AuthZ defines, grants, and enforces specific privileges for the user. Tokens are typically used for AuthN and AuthZ. For example, a client application may execute a remote application that may run in a multi-tenant environment depending on a remote Application Program Interface (API). The user must present the appropriate tokens for AuthN and AuthZ to the API to gain access to the remote application and to cause the remote application to perform the desired operation. Typically, these API calls are made through the HyperText transfer protocol (HTTP) and follow the representational State transfer (REST) semantics and may be done synchronously, e.g., the client building an HTTP structure, sending a request and waiting for a response, or asynchronously, the client building an HTTP structure, sending a request and proceeding and notifying when a response arrives.

When a client application is making an API call, in most cases, the API can quickly respond to requests from the client application, such as about 100 milliseconds (ms) or less. However, in some cases, execution of the request may exceed the expiration of the token, which may be due to various factors, such as the current load, the time of backend processing with the request, the size of the request payload, and so forth. In these cases, the token may become invalid. Thus, the request from the client application cannot be successfully executed.

Drawings

Features of the present disclosure are illustrated by way of example in the following figures. In the following drawings, like numbers indicate like elements, wherein:

fig. 1 illustrates an end-to-end asynchronous request reply flow according to an example of the present disclosure.

Fig. 2 illustrates a flow chart for managing token expiration for asynchronous request reply flows according to an example of the present disclosure.

Fig. 3 shows a system block diagram according to an example of the present disclosure.

Fig. 4 illustrates operations of a background request processor according to an example of the present disclosure.

Fig. 5 illustrates a block diagram of a computer-implemented method of managing execution of requests exceeding token expiration in asynchronous request reply mode, according to an example of the disclosure.

Detailed Description

For simplicity and illustrative purposes, the present disclosure is described by reference to examples thereof. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be readily apparent, however, that the present disclosure may be practiced without limitation to these specific details. In other instances, some methods and structures have not been described in detail so as not to unnecessarily obscure the present disclosure. Throughout this disclosure, the terms "a" and "an" are intended to mean at least one of the specified elements. As used herein, the term "comprising" means including but not limited to, and the term "comprising" means including but not limited to. The term "based on" means based at least in part on.

According to examples of the present disclosure, token management is provided for an asynchronous request reply mode of communication that may be employed between a client application and a remote API to which the client application makes API calls. Asynchronous request reply mode allows the API to relieve itself of providing immediate response to the request, but rather provides a way to provide a response later.

Further, token management includes a process for managing long-term programs that are executed for the request, which may otherwise be difficult to manage due to the expiration of tokens during the long-term programs. AuthN and AuthZ require tokens. The token has an expiration. Typically, the default is set to one hour, but the expiration may be set to a shorter period of time, such as within seconds or minutes. If a request in asynchronous request reply mode requires execution of a backend process longer than the expiration period of the token, it may result in failure to execute the requested operation requested in the API call to the remote API. To avoid the problem of expiration of the token, some systems may create credentials that give blind trust to the user, such as authorizing the user's rights for an extended period of time beyond the expiration of the token. However, this creates a security risk because the credential holder is allowed to perform various operations for an extended period of time even if the token is not valid.

According to examples of the present disclosure, the token expiration is handled in a more secure manner. For example, after accepting a request from a client, the client is provided with a tracking key and a new location, such as the location of a stateful checker API, for checking the state of the request. After a specified period of time, the client may send a status request to the status checker API along with the tracking key. When a client sends a request to a new location, such as a status request to a status checker API instead of an initial request to a remote API, the client automatically includes a new token according to the existing client program. The new token is then used to determine the state and respond to the client state request and process the request upon expiration of the initial token. Thus, if the initial token expires, a new token that is not expired may be used for authorization to process the request, and the process may be repeated as needed until processing of the requested operation is completed. Through this process, the manner in which the token expires is more secure than issuing a credential that allows the request to be processed despite the expiration of the token. Furthermore, the client does not need to re-submit the initial request, so the client 101 does not need to perform any additional operations.

Fig. 1 illustrates an end-to-end asynchronous request reply message flow according to an example of the present disclosure. The client 101 may comprise an application executed by a processor, also referred to as a client application. In an example, the client 101 includes code that runs in a web browser, or in another example, the client 101 may include a stand-alone application that may not require a web browser to run. The client 101 communicates with remote APIs (e.g., API 102 and stateful checker API 103), such as to perform business logic or perform other operations. API 102 may also be referred to herein as a work process API. In an example, the API 102, the stateful checker API103, the storage 104, the legacy API 106, and the background request processor 105 described in detail below are provided on the cloud of the cloud provider, and the client 101 accesses the cloud via the API to execute the request. Client 101 may access APIs and clouds via a network not shown.

Client 101 makes API calls to API 102, which by way of example may be made via HTTP protocol(s) and follow REST semantics. In the operational examples used herein to describe end-to-end asynchronous request reply flows, the API 102 is used for tenant order services to order cloud resources from cloud providers, such as orders for creating Virtual Machines (VMs), assigning database servers, performing billing tasks, and the like.

At 110, client 101 makes an API call, such as an HTTP post request, to API 102. An API call includes a request to perform an operation that may trigger a long running operation on the back end. For example, the request in the API call includes an order from the tenant for a plurality of VMs with a particular image and database server provided to the tenant by the tenant's cloud provider. The request also includes a token, also known as an authorization token. The token may be one or more tokens for AuthN and/or AuthZ. Moreover, the request may include a tag that identifies itself as an asynchronous request rather than a synchronous request. API 102 may check for other errors in the request. Moreover, the API 102 may use the token to authenticate the client 101 and the request, or the client 101 and the request may then be authenticated by the background request processor 105 using the token before the requested operation in the request is performed by the request processing endpoint. If the request is accepted, API 102 responds with an acknowledgement, such as shown at 112, and API 102 performs other operations shown at 111 to cause the request to be processed. If the request is not accepted, API 102 responds with an indication that the request is not accepted as soon as possible, so the user can take corrective action as needed.

As indicated above, if the request is accepted by the API 102 for processing, then operations are performed at 111 to cause the request to be processed. For example, API 102 creates a tracking key entry in storage 104 to track the progress of the order, which may include the requested operation performed in the request. Thus, the API 102 creates a tracking key for the request, which is stored in the storage 104. Storage 104 may comprise a cloud provider's storage accessible by the API and background request processor 105 shown in fig. 1. In an example, the storage 104 may include object storage (e.g., blob storage) in the cloud. The API 102 forwards the order to the background request processor 105 for execution, as shown by the forwarded issue request. If execution is required, the background request processor 105 may forward the order to the legacy API 106, such as issuing the request to the legacy API 106. The background request processor 105 may update the execution progress of the requested order from the client in the storage 104, such as by storing a status code in the storage 104 for the corresponding tracking key of the request. The status code indicates the progress of processing the request. For example, the storage 104 may store a status code, such as wait, process, complete, or error (when a listener cannot process it). At 112, API 102 responds with a confirmation to client 101. The validation includes (1) a status code, such as HTTP status code 202, indicating that the request has been accepted for processing but not completed (in fact processing may not have begun), (2) tracking the key, (3) a location for checking the ongoing status of the order, such as the URL of status checker API103, and (4) a post-retry value indicating the amount of time waiting before checking the location of the order status. Subsequently, after waiting for an amount of time specified by the post-retry value to check the execution progress of the order, the client 101 may send a message including the tracking key to a location, such as the stateful checker API103 instead of the API 102. A location may refer to a URL, an IP address, or another type of address that is used to identify the destination of a message or request that may be sent over a network. The operations performed at 111 may be performed by API 102, stateful checker API103, storage 104, background request processor 105, and legacy API 106. The API 102, stateful checker API103, storage 104, background request processor 105, and legacy API 106 may comprise machine readable instructions executable by processors on different servers, but it will be apparent to one of ordinary skill in the art that one or more of these elements may reside on the same server. Storage 104 may comprise storage in the cloud environment indicated above.

At 113, operations are performed to check the processing status of the request originally made at 110, such as the order status of the VM and database server. For example, after waiting an amount of time specified by the post-retry value to check the progress of the order, the client 101 sends a status check (e.g., HTTP get message) including the tracking key to the status checker API 103. Since the client 101 is sending the status check to a new location, such as to the status checker API103 instead of the API 102, the client 101 includes a new token in the status check. If the original token provided by the client 101 at 110 expires, the new token may be used to process a status check and process execution of the order, as further described below with respect to FIG. 2 and other figures. The stateful checker API103 checks the current state of the order in the storage 104 using the tracking key provided in the stateful check. The background request processor 105 may have previously updated the current state in the storage 104 with a state code indicating that execution of the order is in progress, such as shown at 111, and at 113 the state checker API103 retrieves the code indicating the current state from the storage 104 and sends it back to the client 101 with the retried value and URL for the state checker API for the client 101 to subsequently check the initially requested state.

At 114, the legacy API 106 updates the requested processing progress. For example, the order processing is complete, and the legacy API 106 sends a progress update to the background request processor 105 to indicate that the processing is complete. The background request processor 105 updates the storage 104 to indicate that the current status of the order has been completed. At 115, the client 101 again checks the status of the order, such as similarly described with respect to 113. For example, after waiting an amount of time specified by the post-retry value to check the progress of the order, the client 101 sends a status check (e.g., HTTP get message) including the tracking key to the status checker API 103. The stateful checker API103 retrieves the code indicating completion from the storage 104 using the tracking key and sends it back to the client 101.

Fig. 2 illustrates a flow chart for managing token expiration for asynchronous request reply flows according to an example of the present disclosure. The steps of fig. 2 may be performed by the background request processor 105. Referring back to fig. 1, in the operational example discussed above, the initial request in 110 includes an order for a VM and a database server to be provided to a tenant of the cloud provider. The execution of the order may take longer than the expiration time of the token provided by the client 101 at 110. To prevent the order from being processed due to expiration of the token, if the initial token expires, the new token provided by client 110 at 113 is used to continue processing the order, as discussed further below.

At 201, the background request processor 105 checks whether the token provided by the client 101 is valid. This may include verification of AuthN and AuthZ. For example, the token was previously extracted from the request sent by the client 101 and stored in the storage 104, and the background request processor 105 verifies the AuthN and AuthZ tokens. If the token is valid, then at 202, a request (such as a requested order for a VM and database server) is queued on a service bus (such as service bus 310 shown in FIG. 3) and, at 203, the request is processed by the service bus to be dispatched to a request processing endpoint, such as one of request processing endpoints 312 shown in FIG. 3, which may process the request. For example, background request processor 105 may include a service bus to handle a large number of incoming requests and dispatch the requests to the appropriate endpoints to service the requests. In an example, the service bus implements the subject matter of the message broker and enables multiple receivers or request processing endpoints to process different messages based on the subject matter at any given point in time. This helps in the surge of requests and keeps the total turnaround time of any operation to a minimum. Also, the background request processor 105 includes a listener function, such as listener function 311 shown in FIG. 3, which receives the request at 204 and checks whether the token has expired at 205. If the listener function determines that the token has not expired, the request and the token are submitted to a request processing endpoint that can process the request. However, if the token has expired, the request cannot be executed. To overcome the problem of expired tokens, at 206, the listener function obtains a new token from the stateful inspection API 103. For example, when a status check is received, the listener function instructs the status checker API103 to obtain a new token at 206, the status checker API waits for a status check from the client 101 at 207, and when the status check is received, extracts the new token at 208, and re-queues the request for the order with the new token at 209. New tokens that have not expired may be stored in storage 104 so that requests for orders may be performed by the appropriate request processing endpoint. In a running example including a request to create a VM and assign an order to a database server, the appropriate endpoint may be a provisioning endpoint consisting of a server or VM of a cloud provider that is available and capable of executing the order. The expiration of the token is managed without issuing a credential that allows the request to be processed despite the expiration of the token, via steps 206 through 209. Moreover, the client 101 does not need to re-submit the request with the initial order, so the client 101 does not need to perform any additional operations.

At 205, if the token has not expired, the listener function decrypts the token and submits it with the request to the endpoint that will execute the request at 210. If the order execution is determined to be successful 211, then the response is stored in the storage 104 212. For example, the background request processor 105 updates the storage 104 with a status code for the request, the status code indicating that the order is complete. The stateful checker API103 may then retrieve the state code from the storage 104 and send a response to the client 110 indicating that the request has completed processing, such as shown at 115 in fig. 1. If, at 211, it is determined that the order execution was unsuccessful, then, at 213, it is determined whether the number of attempts is greater than a threshold. If so, order execution terminates and the status may be updated accordingly in the storage 104 so that the client 101 may be notified. If the number of attempts does not exceed the threshold determined at 213, then at 214, a determination is made as to whether the token has sufficient lease. For example, the amount of time remaining before the token expires is determined. The amount of time remaining before the token expires must be sufficient to complete the processing of the request. If the amount of time remaining before the token expires is deemed insufficient, such as by comparing the amount of time remaining before the token expires to the average time to complete a particular type of request or another preset threshold time, then it is determined that the token has an insufficient lease. If it is determined at 214 that the token lease is inadequate, processing continues to step 207 where a new token is extracted from a recent client status check, such as described above. If it is determined at 214 that token leases are sufficient, the request is re-queued to the service bus with the existing token at 215.

Fig. 3 shows a system block diagram of the components described above with respect to fig. 1-2, according to an example of the present disclosure. Client 101 may communicate with APIs (such as API 102 and stateful inspection API 103) of API 300 to submit requests and stateful inspection such as described above. The client 101 may communicate with the API through a network not shown. The client 101 may comprise a web application or a stand-alone application executed by a processor of a computer.

The storage 104 is used to request tracking and storage status. It follows the pattern described below. The storage 104 stores a tracking key for identifying the user when the client 101 transmits a status check. The storage 104 also stores the status of the request, such as wait, process, completion, and errors (e.g., when the listener function 311 cannot process the request). The storage 104 also stores a status code, such as an HTTP status code that is returned to the client 101. The storage 104 also stores a plurality of status checks that represent the number of times the status check API103 checked for a given request status. The storage 104 also stores a response to the current request (once available). This may represent a successful response provided by the underlying API or error message. The storage 104 also stores a number of re-queues, such as the number of times the listener function 311 must re-queue the request back to the service bus. The storage 104 also stores the encrypted token and a time stamp for each update, such as for analysis purposes. In an example, storage 104 is cloud storage of a cloud provider that supports the ordering service of tenants ordering cloud resources.

Background request processor 105 may include a service bus 210, a listener function 311, and a request processing endpoint 312. In an example, the request processing endpoint 312 may be external to the background request processor 105, and the listener function 311 and/or the service bus 310 send requests to the appropriate request processing endpoint to process requests queued on the service bus 310. The operations performed by service bus 310 and listener function 311 are described further above with respect to fig. 2. Service bus 310 and listener function 311 may include machine readable instructions that are executed by a processor. Request processing endpoint 312 may include hardware and software for executing requests. For example, assuming that the client 101 sends a request for managing virtual resources to the cloud provider, the request processing endpoint 312 executes the request, such as provisioning and un-provisioning cloud resources for tenants, and the like.

Legacy APIs 106 may be invoked by background request processor 105 to execute requests. In an example, API 102 is used for order services with which client 101 interacts to order resources from a cloud provider. The order service may interact with the customer and have dependencies 320 on other downstream services. When the downstream service needs to execute an order, the background request processor 105 may make an API call to the legacy API 106. In some examples, the dependencies 320 have low reliability due to scaling constraints or other factors. By using the legacy API 106, order services may be decoupled from less reliable dependencies. In this way, order services may be shielded from the reliability degradation caused by dependencies 320. Thus, buffering is provided between the order service or another service provided by the background request processor 105 and the dependency fault.

Fig. 4 shows a block diagram of a background request processor 105 according to an example of the present disclosure. Processor 402 may include a single or multiple hardware processors or other hardware processing circuitry to perform the methods, functions, and other processes described herein. The methods, functions, and other processes may be embodied as machine-readable instructions stored on a computer-readable medium, which may be non-transitory, such as hardware storage devices (e.g., RAM (random access memory), ROM (read only memory), EPROM (erasable programmable ROM), EEPROM (electrically erasable programmable ROM), hard disk drive, and flash memory). Memory 410 may include one or more storage devices, such as RAM, on which machine readable instructions and data for the processor may reside during runtime. Moreover, the APIs 300 and other processes described herein may include machine readable instructions stored on a non-transitory machine readable medium and executed by a hardware processor. Referring to the block diagram shown in fig. 4, the memory 410 may include machine-readable instructions executable by the processor 402. The machine-readable instructions may include instructions 420 for receiving a request to perform an operation, wherein the request includes a token with expiration; instructions 421 for determining whether the token expired before or during execution of the request; and instructions 422 for prompting the stateful inspection API103 to obtain a new token and to execute the request with the new token in response to determining that the token is expired.

Fig. 5 illustrates a block diagram of a computer-implemented method of managing execution of requests exceeding token expiration in asynchronous request reply mode, according to an example of the disclosure. The computer-implemented method is described by way of example as being performed by one or more of the components shown in fig. 1 and 3. At 520, a request to perform an operation is received from the client 101 at the work process API 102, where the request includes a token having an expiration. In 521, the request is issued for processing. For example, a request is issued to service bus 310 so that it can be handled by the request processing endpoint. In 522, a response is transmitted to the client 101 indicating acceptance of the response for processing, wherein the response includes a post-reply time period and a location of a status of the polling request after expiration of the post-reply time period, and wherein the location of the polling is different from the work process API. In 523, a status check for the request is received from the client 101 (e.g., the status checker API 103) at the location of the poll based on the post-answer time period. At 524, if the token has expired, the new token comes from a status check. At 524, the current state of the request is used to transmit a reply to the state check to the client 101. The computer-implemented methods may be performed by the processor 502, which processor 502 may include a single or multiple hardware processors or other hardware processing circuitry to perform the methods, functions, and other processes described herein. The steps of the method may be embodied as machine readable instructions stored on a computer readable medium, which may be non-transitory, such as hardware storage devices (e.g., RAM (random access memory), ROM (read only memory), EPROM (erasable programmable ROM), EEPROM (electrically erasable programmable ROM), hard disk drive, and flash memory). The memory 510 may include one or more storage devices, such as RAM, on which machine readable instructions and data of the processor may reside during runtime.

What has been described and illustrated herein is a few examples and variations thereof. The terms, descriptions and figures used herein are set forth by way of illustration only and are not meant as limitations. Many variations are possible within the spirit and scope of the subject matter, which is intended to be defined by the following claims and their equivalents.

Claims (15)

1. A system operable to manage execution of requests exceeding token expiration in an asynchronous request reply mode, the system comprising:

at least one hardware processor;

a work process Application Program Interface (API), executed by the at least one hardware processor, for:

receiving a request from a client for performing an operation, wherein the request includes a token having an expiration;

creating a tracking key for the request;

issuing the request for processing; and

transmitting a response to the client in response to accepting the request, wherein the response includes a post-reply time period, the tracking key, and a location for polling a status of the request after expiration of the post-reply time period; and

a stateful checker API, executed by the at least one hardware processor, for:

receiving a status check for the request from the client based on the post-reply time period and the location for polling, wherein the status check includes the tracking key;

checking the status of the request using the tracking key;

extracting a new token from the status check based on the new token required to perform the request; and

and sending a response to the status check by using the current status of the request.

2. The system of claim 1, further comprising:

a background request processor executed by the at least one hardware processor, the background request processor to:

determining whether the token expires prior to execution of the request; and

in response to determining that the token expires, prompting the stateful checker API to obtain the new token from the received stateful check and executing the request with the new token; and

and a storage device for storing the token, the new token, the tracking key, and the current state of the request.

3. The system of claim 2, wherein the state checker API compares the tracking key received in the state check with the tracking key stored in the storage, wherein in response to receiving the request, the tracking key is initially stored in the storage to check the state of the request.

4. The system of claim 2, wherein the background request processor updates the current state of the request in the storage device.

5. The system of claim 2, wherein to determine whether the token expired prior to execution of the request, the background request processor is to:

determining whether the token has expired; or alternatively

A determination is made as to whether the token has sufficient leases to fulfill the request.

6. The system of claim 1, wherein the token and the new token are validated prior to processing the request and the status check.

7. The system of claim 6, wherein the token is verified for at least one of authentication (AuthN) and authorization (AuthZ) in an identity and access management process.

8. The system of claim 1, wherein the request is from a tenant of a cloud provider, and the request includes an order for a resource from the cloud provider.

9. The system of claim 1, wherein the request comprises a request for the operation to be performed by an application hosted on a cloud.

10. The system of claim 1, wherein to extract a new token from the state check based on the new token required to execute the request, the state checker API extracts the new token from the state check in response to a prompt from a background request processor.

11. A computer-implemented method for managing execution of requests exceeding token expiration in an asynchronous request reply mode, the method comprising:

receiving a request from a client for performing an operation at a work process Application Program Interface (API), wherein the request includes a token having an expiration;

issuing the request for processing;

transmitting a response to the client indicating that the response is accepted for processing,

the response includes a post-answer time period and a location for polling the status of the request after expiration of the post-answer time period,

wherein the location for polling is different from the location of the work process API; receiving a status check for the request from the client at the location to poll based on the post-answer time period;

extracting a new token from the status check based at least on the token having expired; and

transmitting a response to the status check to the client using the current status of the request.

12. The computer-implemented method of claim 11, wherein the location for polling comprises a stateful checker API, and the method further comprises:

determining, by the stateful checker API, whether the token expires before execution of the request; and

in response to determining that the token expires, the stateful inspector API is prompted to obtain the new token from the received stateful inspection to perform the request.

13. The computer-implemented method of claim 12, comprising:

storing the new token and the current state of the request in a storage accessible by the state checker API; and

the current state of the request is retrieved by the stateful checker API for provision to the client.

14. The computer-implemented method of claim 13, comprising:

in response to receiving the request from the client at the work process API, a tracking key is stored in the storage, wherein the stored tracking key facilitates a subsequent check of the status of the request.

15. The computer-implemented method of claim 11, wherein the request is from a tenant of a cloud provider and the request includes an order for a resource from the cloud provider.