feat: add AIP 4120 - Universe Domain support #1282
Conversation
bshaffer
changed the title
|
@westarle FYI |
|
|
||
| Additional recommendations: | ||
|
|
||
| - GCE credentials **should** retrieve the universe domain in a 'lazy' way, when the end-user requests the `universe_domain` via the property/get method. They **should not** do it during the credentials initialization. |
There was a problem hiding this comment.
Who tests that the fetched credential universe matches the user-specified universe domain in the client lib and prevents mismatches?
There was a problem hiding this comment.
This validation happens in the client libraries
|
@westarle in anticipation of discussions happening later this week, can we get another review on this one from you? |
aip/auth/4120.md
Outdated
| #### Authentication libraries **must** use the self-signed JWT flow when authenticating outside the GDU using Service Account credentials | ||
|
|
||
| Currently the self-signed JWT (SSJ) sub-flow is the default option for Service Account auth flow, but user parameters provided, such as `scope`, `audience`, or `useJwtWithScopes` can change that. E.g. setting `useJwtWithScopes` to `false` when specifying `scope` would result in auth library fallback to token exchange flow for service accounts. | ||
| The token exchange for Service Accounts is not a supported flow outside the GDU, and services must support SSJ with scopes. Therefore authentication libraries **must** use the self-signed JWT flow when authenticating outside the GDU using Service Account credentials. If the `useJwtWithScopes` parameter exists (whatever form it takes in specific languages), it **must** be ignored outside the GDU, and its documentation **must** be updated to reflect that. |
There was a problem hiding this comment.
Since this is a specification, could we just say "If the universe domain is not GDU, only self-signed JWT tokens may be used for authentication via bearer token when using service account key credentials."
And discard all the stuff that might change over the next few months/years like how the library works in GDU?
There was a problem hiding this comment.
The useJwtWithScope option is already documented in https://google.aip.dev/auth/4111, so I think it's appropriate to have it as part of this spec as well.
| | -------------------------------------------------- | ------ | | ||
| | 404 | The authentication libraries **must** set the `universe_domain` to the default value `"googleapis.com"`. | | ||
| | Timeout | The authentication libraries **must not** fall back to the `"googleapis.com"` default value. A retry mechanism is recommended. The authentication libraries **should** do the same action as when retrieving the access token times out. | | ||
| | Any other error | The authentication libraries **must not** fall back to the `"googleapis.com"` default value. The authentication libraries **should** do the same action as when the same error happens when retrieving the access token. | |
There was a problem hiding this comment.
Heads up: this has turned out to be a bit of a problem -- because "MDS" doesn't much have a specification we can refer to, customers have implemented "MDS" clones that don't match our expectations.
Beyond the scope of this AIP, but is there a way we can mitigate that problem without requiring changes to MDS clones or our libraries? Maybe a trusted parameter or environment variable available to auth libraries to fix the universe domain.
There was a problem hiding this comment.
By accepting 404s to be googleapis.com, we should be handling all edgecases where other MDSs don't behave as expected (see line 66)
There's a potential for accepting a timeout as googleapis.com in the event that the library has already confirmed that it's running on MDS. But this is a temporary fix, and has not been accepted in the spec yet, so I think it's best to leave it out.
|
|
||
| > This requirement applies **only** to the flows which are supported outside the GDU. | ||
|
|
||
| The code for the authentication flows **must not** contain hardcoded endpoints, endpoint-alikes or other authentication information unless this information is constant across all flows for all universes. Any information that is possible to read from the credentials file should be read from the credentials file. For example, `scopes` contain the "googleapis.com" domain but are still valid outside the GDU because their values are consistent across all universes, whereas the STS endpoint "sts.googleapis.com" is not allowed because it is different for every universe. |
There was a problem hiding this comment.
Is there a reference for what changes outside and what doesn't that we can refer to?
There was a problem hiding this comment.
There is no canonical list that I am aware of. I believe this is because "scopes" is currently the only value of googleapis.com that is allowed outside GDU - everything else should change based on the universe.
|
|
||
| Currently the self-signed JWT (SSJ) sub-flow is the default option for Service Account auth flow, but user parameters provided, such as `scope`, `audience`, or `useJwtWithScopes` can change that. E.g. setting `useJwtWithScopes` to `false` when specifying `scope` would result in auth library fallback to token exchange flow for service accounts. | ||
| The token exchange for Service Accounts is not a supported flow outside the GDU, and services must support SSJ with scopes. Therefore authentication libraries **must** use the self-signed JWT flow when authenticating outside the GDU using Service Account credentials. If the `useJwtWithScopes` parameter exists (whatever form it takes in specific languages), it **must** be ignored outside the GDU, and its documentation **must** be updated to reflect that. | ||
| The token exchange for Service Accounts is not a supported flow outside the GDU, and services must support SSJ with scopes. Therefore authentication libraries **must** use the self-signed JWT flow when authenticating outside the GDU using Service Accountj key credentials. If the `UseJWTAccessWithScope` parameter exists (whatever form it takes in specific languages), it **must** be ignored outside the GDU, and its documentation **must** be updated to reflect that. |
There was a problem hiding this comment.
"The token exchange for Service Accounts" --> "Service Account Key authentication using OAuth" (from the SA Key AIP)
No description provided.