Propagation of Entity Alias metadata attributes to their linked Entities

[ianferguson]

Is your feature request related to a problem? Please describe.

We are using multiple auth backends that all provide metadata such as the user email address, and using the identity backend as a pull through cache of identity. Because metadata attributes are attached only to the Entity Alias and not the Entity, we are running into 2 challenges at the moment.

We use https://github.com/terraform-providers/terraform-provider-vault for managing many of our Vault configurations, and currently when we want to template policies based on metadata attributes of an identity (such as user's email), we end up needing 2 HCL stanzas per path in order to ensure that users have the same effective access regardless of if they use a primary or secondary auth backend, i.e.:

path "secret/user/{{identity.entity.aliases.${vault_auth_backend.primary_backend.accessor}.email}}" {
  capabilities = ["read"]
}

path "secret/user/{{identity.entity.aliases.${vault_auth_backend.backup_backend.accessor}.email}}" {
  capabilities = ["read"]
}

While this may not be ideal it is something we can largely workaround/make work. Where we're unable to work around metadata attributes being attached only to Entity Aliases is when we use the Identity backend's token issuing feature, and specifically the support for templating in metadata from an Entity or Entity Alias in to the JWT that Vault issues.

i.e. if we create an identity oidc role that issues JWT's to log in to an application, currently we might use a template such as this:

  {
    "groups": {{identity.entity.groups.names}},
    "username": {{identity.entity.aliases.${vault_auth_backend.primary_backend.accessor}.name}},
    "email": {{identity.entity.aliases.${vault_auth_backend.primary_backend.accessor}.metadata.email}},
    "email_verified": true
  }

But this would mean that anyone authenticating using the "secondary_backend" or any other backend we trust the metadata from would not be able to acquire a valid JWT for accessing the target application from Vault, because they would not have an Entity Alias from the primary_backend auth backend.

We could potentially have a service proactively push identities into Vault and handle linking different Entity Aliases from different backends to the correct Entities, but that introduces a lot of moving parts and increases the surface of things that are able to manipulate Vault's configuration and access in a pretty wide way. For that reason having Entity Alias metadata propagated to the underlying Entity, despite some challenges/potential issues around freshness of that data or collisions with other backends, seems like it might be preferable.

This is similar to the request in #6856, but with additional use cases that would benefit from propagating Entity Alias metadata attributes to Entities.

Describe the solution you'd like

Entity Alias metadata attributes propagated to linked Entities.

Describe alternatives you've considered

• Using an external service to push identities and metadata attributes into Vault and manage linking entity aliases from different auth backends to entities in a recurring/push based syncing process.

Explain any additional use-cases
Only the 2 detailed in the description at this time.

Additional context
If I've overlooked a more sensible way to accomplish what is being described, I am very open to alternatives beyond what was suggested.