feat(auth): add support for service account impersonation

[m1racoli]

Summary

Added the arguments target_principal and delegates which optionally define an impersonation chain for the given target principal to the Token class and related clients.

The request to generate the impersonated access token is made via the IAM credentials API method projects.serviceAccounts.generateAccessToken.

Test skeletons have been added. Those tests are currently skipped as they require additional setup of the testing environment with additional service accounts which are to be impersonated:

• sa_a to be impersonated by the base service account
• sa_b to be impersonated by sa_a via delegation

closes #421

[m1racoli]

I understand that I added changes beyond the auth package. Let me know if you'd like this PR to focus only on the auth package.

[m1racoli]

Thanks! :) Do we have an ETA for this to get merged or is something particular blocking the PR?

[Lee-W]

Hi @TheKevJames , we're wondering whether gcloud-aio is interested in this feature and if so, is there any blocker of suggestions in this PR? Thanks!

[kaxil]

Gentle nudge @TheKevJames @shaundialpad

[TheKevJames]

Hey all, sorry for the radio silence on this one, taking a look now! Thanks for posting this.

[TheKevJames]

Ok, I've merged this (here) and will be releasing shortly. Thanks for the contribution! Overall this looked great, just needed to tweak some linting things. Thank you especially for the integration test skeleton, that was very easy to work with.

[TheKevJames]

Oh, just to add -- I needed to pull out the changes to other libraries to avoid order-of-operations, but will introduce them later. For now, you can build a Token instance with the delegation and pass it to any other library class, you just can't let it pass through those values.

Now that the Token class has gotten so many params, I'm starting to think it might be worth making it mandatory to have users create the Token, frankly -- especially with how many places we would need to plumb everything, as you pointed out for BQ Jobs. I'll look into this and see about pushing out a follow-up.

[m1racoli]

Thank you

Oh, just to add -- I needed to pull out the changes to other libraries to avoid order-of-operations, but will introduce them later. For now, you can build a Token instance with the delegation and pass it to any other library class, you just can't let it pass through those values.

Yeah, that makes sense.

Now that the Token class has gotten so many params, I'm starting to think it might be worth making it mandatory to have users create the Token, frankly -- especially with how many places we would need to plumb everything, as you pointed out for BQ Jobs. I'll look into this and see about pushing out a follow-up.

Yes, I had similar thoughts. You either provide a token or assume the default credentials. That would align with the methodology in google libs where the credentials object is a container for every aspect of the credentials and needs to be configured as such. I also wonder if the project ID needs to be part of the token.