identity: do not allow a role's token_ttl to be longer than verification_ttl

[fairclothjm]

Fixes issue #11441 which reported that OIDC identity tokens can have a TTL longer than their signing key will be visible.

Tests

Test role invalid TTL

Test that an attempt to create a new role checks that the token ttl is not greater than the key's verification_ttl

# set verification_ttl=1m
vault write identity/oidc/key/a-key rotation_period=1m verification_ttl=1m allowed_client_ids="*"

# try to create a role with ttl=60m -- Fails
vault write identity/oidc/role/a-role key=a-key ttl=60m

Error:

Error writing data to identity/oidc/role/a-role: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/identity/oidc/role/a-role
Code: 400. Errors:

* a role's token_ttl cannot be longer than the verification_ttl of the key it references

Test key invalid TTL

Test that an update to an existing key that is referenced by a role cannot have its verification_ttl exceed the role's ttl

# set verification_ttl=4m
vault write identity/oidc/key/a-key rotation_period=1m verification_ttl=4m allowed_client_ids="*"

# create a role with ttl=4m -- Success
vault write identity/oidc/role/a-role key=a-key ttl=4m

# update key's verification_ttl=2m -- Fails
vault write identity/oidc/key/a-key rotation_period=1m verification_ttl=2m allowed_client_ids="*"

Error:

Error writing data to identity/oidc/key/a-key: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/identity/oidc/key/a-key
Code: 400. Errors:

* unable to update key "a-key" because it is currently referenced by one or more roles with a token_ttl greater than 120 seconds

[calvn]

We could also consider changing the line where we ultimately set on ID token's Expiry value during token generation by using the floor of the two.

[fairclothjm]

@calvn

We could also consider changing the line where we ultimately set on ID token's Expiry value during token generation by using the floor of the two.

In that case, would we want to add a warning if we are not using a value set by the user explicitly? It does seem like a simpler option.

[calvn]

Yeah, a warning would be useful. I also didn't imply that we should remove the checks that you added. I was suggesting that we could do both :)

[calvn]

Few comments, but otherwise looks good!

[calvn]

One comment, looks good otherwise!

[austingebauer]

LGTM!