How Long Are Continuation Tokens Supposed to Be
Background
When your service calls another, it should propagate the security context. Section 3.3 of the Software Development Security Requirements document (commonly referred to as RFC 5 from a former incarnation) phrases it this way:
Non-leaf APIs (that is, APIs that call other APIs)MUSTpass on the credentials of the caller in subsequent requests, where technically feasible, if the identity of the user is necessary to safely service those requests.
There are a number of reasons to do this. One of the more important reasons is so that operators of the platform do not have to grant full access privileges to services as a workaround. We want to grant appropriate, limited privileges to individuals.
However, for long-running transactions, where some services must wait for additional conditions to be satisfied before additional processing, it was historically difficult to comply with this guidance. The duration of the transaction can often be longer than the expiration time of access tokens used to identify the original caller, so services had no choice but to substitute their own credentials for those of the user. This is precisely the condition the security standard was designed to prevent.
Worse, this can happen more than once in the same call graph, as shown in the illustration above.
Continuations for Long-running Processes
The Continuations service is designed to allow long-running processes the ability to acquire tokens that signal the authority and identity of the original caller even after that user's token has expired. Rather than be stuck with question marks, as in the illustration above, Continuations allows a flow like the following:
- Service A, from the illustration above, would register a continuation using the original token, and a client-credentials grant token for identifying itself.
- When Service A is ready to call Service B, it can get a continuation token that will contain all the claims of the original user's token.
- Service A calls Service B.
- Service B accepts the token because it is a valid client-credentials grant access token issued by Auth0.
- Service B calls COAM to verify permissions. It passes the continuation token as the Authorization bearer token. Service B asks COAM what permissions the principal identified by the token has.
- COAM understands continuations properly, so it replies with the permissions for the original caller.
- Service B is happy, does its own processing and calls Service C, using the same continuation token.
- Service C repeats steps 4, 5, and 6. Then, because it also will take a long time to complete, it registers a new continuation.
- When Service C is ready to call Service D, it obtains a continuation token using its new continuation ID and its own client-credentials grant token.
- Service D repeats steps 4, 5, and completes the processing chain.
Service A and Service C could have continued to draw continuation tokens up until the continuation expires, or if the continuation has been halted. Only Service A could get a token for the continuation ID it registered. Likewise, only Service C could get a token for the continuation ID it registered.
As shown in the example, any service may use a continuation token to register its own continuation.
To force a continuation to expire early, you may halt it. Halting a continuation, like expiration, means that the service that registered the continuation may no longer draw continuation tokens for that continuation ID.
Halting continuations
When continuations expire or are halted, the tokens issued from them continue to be valid until they expire.
In the case where Service A above registers a continuation for the same caller, the Continuations service will likely supply the same continuation ID, with the expiration of the continuation extended as needed. After a period of extensions (usually two weeks from initial registration) the Continuations service will issue a new continuations ID for that same combination of original token and caller credentials.
Continuation Tokens and COAM
Continuation tokens are Auth0 access tokens created through the client-credentials grant flow. From an identity perspective, this means that continuation tokens do not carry the actual identity of the original caller. Instead their sub claim is populated with the client ID of the Continuations service. API Management introduced the canonical_id custom claim for just this reason. The continuation token will carry all of the claims from the original token, including the canonical_id and tenants claims.
When COAM is called using a continuation token, and asked about the Continuations client, it will interpret that question as being asked by the principal identified in the canonical_id, and as being about the principal identified in that canonical_id. Doing so allows COAM to answer the intended question correctly.
Note that the Continuations client will never have permissions assigned to it. This means that if COAM is asked about the Continuations client ID by someone not using a continuation token, COAM will answer appropriately that no permissions have been granted. This makes propagation of the security context, as noted at the beginning of the document, one of the most important prerequisites to making this process work.
Source: https://cimpress-support.atlassian.net/wiki/spaces/CI/pages/330274135/Continuations
0 Response to "How Long Are Continuation Tokens Supposed to Be"
Post a Comment