You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So this comes from my experience setting up Azure OIDC authentication in our Vault cluster. I believe it would be generally applicable to other examples.
I'd like to be able to declare what aliases are generated, and have that be independent from the user claim. This way I can use a durable, but opaque identifier for the user_claim, and a set more operator-friendly aliases instead.
With Azure, the recommendation is to use a durable identifier such as (sub or oid). Unfortunately, those are opaque Azure identifers or a GUID respectively. This makes the aliases generated in Vault pretty useless.
Though one can copy some of these values into the metadata, the Vault API doesn't let one query by metadata either. Which makes finding a particular user's entity a bit challenging if the user claims are opaque openid values.
The text was updated successfully, but these errors were encountered:
So this comes from my experience setting up Azure OIDC authentication in our Vault cluster. I believe it would be generally applicable to other examples.
I'd like to be able to declare what aliases are generated, and have that be independent from the user claim. This way I can use a durable, but opaque identifier for the user_claim, and a set more operator-friendly aliases instead.
With Azure, the recommendation is to use a durable identifier such as (
sub
oroid
). Unfortunately, those are opaque Azure identifers or a GUID respectively. This makes the aliases generated in Vault pretty useless.Though one can copy some of these values into the metadata, the Vault API doesn't let one query by metadata either. Which makes finding a particular user's entity a bit challenging if the user claims are opaque openid values.
The text was updated successfully, but these errors were encountered: