[req] Ability to use JWT Role Name as Identity entity alias name

[mbillow]

Problem

There are certain situations where individual claims in the JWT tokens are insufficient at properly identifying a unique identity.

Take GitLab JWTs as an example. Each claim in the JWT is a distinct, disparate piece of information about which repo, branch, user, etc. caused the CI job to spawn.

This makes it impossible to have granular Identities aliased to these JWTs. The finest grain Identity we can have in this example is project_path which severely limits the usefulness of the bound_claims restrictions that can be accomplished with roles. Building on this example, if we wanted to associate an identity with CI jobs in a certain repo but only on the main branch, that is impossible.

This becomes increasingly difficult in Vault enterprise where the Identity engine is used to grant permissions within child namespaces. In order to solve this in the short term, we have mounted per-namespace auth backends and are having users create their own roles within their namespace-local backends which is potentially detrimental to our client count (core licensing metric).

Proposed Solution

Allow for the name of the role used during authentication to be used as the Identity entity alias name.

This would allow us to leverage the powerful bound_claims restrictions and map them directly to an Identity.

For example, we could create a role like:

{
  "name": "myteam.myproject.production"
  // add some boolean to toggle this behavior
  "role_name_as_entity_name": true
  "bound_claims": {
    "project_path": "myteam/myproject"
    "ref_protected": "true",
    "environment": "production",
    "environment_protected": "true"
  }
}

Then an Identity:

{
  "name": "gitlab--myteam-myproject--prod"
}

And an alias:

{
   "name":  "myteam.myproject.production",
   "canonical_id": "id-of-entity",
   "mount_accessor": "accessor-of-jwt-backend"
}

At this point, users are free to create internal groups (with the entity above as a member) in their namespaces with whatever policies they need. The auth mount can live in the root namespace, have access to any number of children, and we don't have to mount an auth backend per-namespace anymore.