Preflight checklist

• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines."
• I have discussed this feature request with the community.

Describe the background of your feature request

In some cases, the request may contain multiple tokens, with one representing the actual client (the service) sending the request and the other representing the user, who wants to do something. In such scenarios verification of both tokens is required as well as the extraction of the relevant information. The token format may vary depending on the setup.

In such setups, the information about the user is verified and extracted from the corresponding token via an authenticator mechanism. But there is no convenient way to verify and extract the information from the other token.

Examples:

• Context: Access to a staging environment. Only project members should be able to access the services (via e.g. a browser) to see and test the new deployed features. There is also an IAM in the staging environment itself which manages the "customers". So the first IAM manages the access to the environment and the second represents the actual users of the services deployed.
  That way the Authorization header represents the user and describes its permissions through the scope claim and then X-Env-JWT certifies that the request has been routed through an authorized gateway (so access to the environment was legitimate)
• Context: Verification that the request came over a specific intermediary. Depending on the path the request took, the gateway issues an additional token, e.g. X-Caller-ID, which is then present in addition to the token in the Authorization header.

Describe your idea

The challenge described above could be solved by the introduction of authorizers, which would function exactly the same way, as the available jwt and oauth2_introspection authenticators, but with the difference, that they should not create a .Subject object, but use an existing one (created by a used authenticator)

Are there any workarounds or alternatives?

There are two options:

• One can create a small microservice, which would do the required verification of the token and return the relevant data and use that microservice via the remote authorizer.
• One can "stack" multiple heimdall instances, with one reponsible for the one token and the second one for the other token (in both cases on the authenticator level).

Obviously, for the first option, there is a need to write and maintain that microservice and the second option can only be used if heimdall is operated in proxy mode. In addition that second option would mean more latency and might be limiting, depending on the actual environment and setup.

Version

v0.10.1-alpha

Additional Context

That FR and #882 may be related.