Include User metadata as headers in extAuth configuration

[kcbabo]

Is your feature request related to a problem? Please describe. The API Key used with Ext Auth contains portal-related metadata from the Environment, Product, Usage Plan, and User definition associated with the key. Here's an example of API Key metadata today:

product:      24 bytes
username:     4 bytes 
api-key:      48 bytes   
environment:  11 bytes  
plan:         5 bytes   

The AuthConfig used with the generated proxy configuration for an API includes configuration to include the plan name as a header:

configs:
  - apiKeyAuth:
      headersFromMetadata:
        x-solo-plan:
          name: plan
          required: true

Unfortunately, this configuration does not include other details that would be useful for access logging and upstream APIs such as the username and email address from the Portal User object associated with the API Key. Note that the X-User-Id header is not actually the username - it's the name of the API Key secret.

Describe the solution you'd like We would like the ability to include additional metadata from the Portal User object as headers, specifically the username and email address. The following pieces are required to make that happen:

• [x] When Portal creates an API Key, include email address from the associated User object as a data field in the secret (username already exists)
• [x] When Portal creates an AuthConfig for a usage plan, include headersFromMetadata entries for x-solo-username and x-solo-email to include these headers in the upstream request.
• [x] Verify that Access Logging has access to these headers for auditing purposes.
• [x] Verify that upstream APIs receive these headers

An additional option to consider here is that instead of the static addition of these headers as described above, the person configuring the Environment and API Product CRs can include gateway options that configure headersFromMetadata directly. I don't believe this is possible today, as Portal does not permit extAuth configuration overrides in Environments.

Describe alternatives you've considered We can simulate the behavior by modifying the API Key secret to include the fields we want and the associated AuthConfig to pass them as headers. This is not a workable solution, however, because these objects are actually managed by Portal for API Products and Environments.

Additional context Add any other context or screenshots about the feature request here.

[soloio-bot]

Zendesk ticket #526 has been linked to this issue.

[spunuru]

Resolution of this issue helps us in tracking the user (using access logs or by sending headers to upstream) who originally create the api-key. Here is another issue, we would like to solve. I created the # 526 for this reason.

User wants to generate multiple api keys, one api key per each API client. User needs to label or alias the api key for following reasons:

• User can log the api-key label/alias in access logs. This is more desirable than PII field useremail.
• User can send it to upstreams, so they use it for caller identification or logs
• easier identification of the api-key and rotate the api-key

[bewebi]

PRs have merged to be released in the next Portal 1.2.0 beta:

• Email will be written to new API Key secrets from the given user identifier
  • For OIDC auth we already write email to the username field, so we will have the same value twice
• X-Solo-Username and X-Solo-Email headers will be added to incoming requests and will be available to upstream APIs and when access logging

Note that email will only be written for secrets created after upgrading; use of pre-existing keys will result in no X-Solo-Email header