Currently there are no validations around the email provided by callers of JVS. This applies to both scenarios which include the subject field in the proto as well as the IAP provided email header. Additionally this validation should not hinder the local development of the service and its components such as the JVS UI.
Detailed design
TBD
There is a DEV_MODE environment variable which should be leveraged if/when we need to bypass scenarios in which more infrastructure is needed i.e. KMS and IAP.
Alternatives considered
Ignoring validation entirely. For the UI case, it is implied the caller is the principal. For the gRPC case, the consumer of the JWT should validate the principal.
Additional information
For the IAP case, the x-goog-iap-jwt-assertion is provided to the application and is meant to be more secure than the currently used x-goog-authenticated-user-email header (which can be spoofed). Additionally there are testable JWT verification scenarios through query parameters.
TL;DR
Currently there are no validations around the email provided by callers of JVS. This applies to both scenarios which include the subject field in the proto as well as the IAP provided email header. Additionally this validation should not hinder the local development of the service and its components such as the JVS UI.
Detailed design
TBD
There is a
DEV_MODEenvironment variable which should be leveraged if/when we need to bypass scenarios in which more infrastructure is needed i.e. KMS and IAP.Alternatives considered
Ignoring validation entirely. For the UI case, it is implied the caller is the principal. For the gRPC case, the consumer of the JWT should validate the principal.
Additional information
For the IAP case, the x-goog-iap-jwt-assertion is provided to the application and is meant to be more secure than the currently used
x-goog-authenticated-user-emailheader (which can be spoofed). Additionally there are testable JWT verification scenarios through query parameters.