Add token ACL templating support

[nbrownus]

Adds the ability to target token.metadata.* in policy templates

[hashicorp-cla]

All committers have signed the CLA.

[nbrownus]

I do not believe the test-go-race failures are a part of this change.

[jefferai]

I don't think we want to merge this; display name is usually unreliable and can often be set by relatively unprivileged users.

What about Identity doesn't work here? What's the use case?

[nbrownus]

More than happy to drop display_name. Our use case is specifically around token.metadata. I did not find a way to reasonably manipulate identity via a plugin that did not impose additional work on the policy writer.

Identity looks like a great way to deal with dynamic policy, but the requirement for mount accessor, which is dynamically keyed, makes it cumbersome to deal with in an environment where the auth plugin needs to change on any cadence.

Being able to target properties on the token would be incredibly helpful, even if those properties were limited to logical.Auth.InternalData somehow.

Very willing to make any changes you all deem necessary, avoiding dynamically generated identifiers in dynamic (templated) policies is our goal.

[VioletHynes]

Hi there! Thanks for the PR. We discussed this internally, as I wanted to make sure to get you an answer for this PR as it's on the older side. Unfortunately, this isn't something we're planning to support.

See also: #10460 + #10682

In particular, there are two parts of our responses to these that explain our position and hopefully offer an alternative. Hopefully the following answers satisfy you:

I think you can achieve the result you're aiming for by creating an entity and alias for each role that needs distinct policies, put the metadata into the entity, and bind the entity alias to the token role.

and

Thank you for the contribution. Unfortunately I'm afraid that we have decided to refuse it. We view this change as dangerous, since a user can create child tokens with whatever arbitrary metadata they like. This means policy templating using token metadata is vulnerable to any attacker who's aware of what policies are in use. I expect that you could come up with safeguards in your environment to protect against this (e.g. not granting access to the create token endpoints), but we as vault devs have to be vigilant against introducing features that allow for insecure by default behaviour.

Thanks for raising this, and we appreciate the contribution. However, we feel like the 'right' way to do this is using the identity system. Token metadata is quite low privilege.