New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ImpersonatedCredentials can't negotiate proper access token with delegated access to user account #759
Comments
@silvolu Could you ask someone to look at this? |
Hi @tzhou2021, The code that you referenced is expected. It is a default functionality, which is - not implemented. Individual credentials should have an override with a specific implementation. As an example you can see ServiceAccountCredential has this method implemented. The README for this library has an example how to instantiate ImpersonatedCredentials, have you tried that? |
requilifying as question |
Hello, @TimurSadykov the answer is not satisfying as it's saying to either look at domain-wide delegation or impersonation separately, but there is no example on how to do them together. It also fails for me with "bad request" so it is a bug or just not supported at all. |
@tzhou2021 did you find a solution? |
@alamothe Please provide details of your particular issue and we try to figure it out. In the original issue the problem that @tzhou2021 misunderstood that user override is not respected by referencing GoogleCredentials. The GoogleCredentials is a base class, but actual impersonation is credential specific. If ServiceAccount is used, it has an override implementation:
|
@TimurSadykov You're mixing the part where @tzhou2021 tried to debug why it doesn't work and the problem description. Let me try to explain just the problem description.
Now, we want A to be able to perform an action on W as user U in that workspace. This should work, because permissions have been adequately set up. However it fails at runtime: val credentials = (GoogleCredentials.getApplicationDefault() as ServiceAccountCredentials)
.createScoped("https://www.googleapis.com/auth/iam")
.let {
ImpersonatedCredentials.create(
it,
null,
listOf("service-account-b@project.iam.gserviceaccount.com"),
listOf(DirectoryScopes.ADMIN_DIRECTORY_USER),
300)
}
.createDelegated("user-u@workspace-w.com")
val service = Directory.Builder(
httpTransport,
GsonFactory.getDefaultInstance(),
HttpCredentialsAdapter(credentials),
)
.setApplicationName("test")
.build()
service.users()
.list()
.setCustomer("my_customer")
.setMaxResults(10)
.setOrderBy("email")
.execute() |
@alamothe The use case is clear from the original description, but thanks for providing specific code you use. I'm trying to understand the issue you are seeing. "It fails" does not provide much data to investigate. Do you see exactly the same error like @tzhou2021? If you just do refresh token for the created credential, does it work or it throws same error? |
We are also seeing the same problem in our Appengine Java app. The details are below:
The error message we get back is
One thing we find it odd is that since ImpersonatedCredentials does not override parent's createDelegated() method, we don't have a way to set the subject's email address (user-U@our-domain.co). By the way, the python library's service account implementation is reportedly working for domain-wide delegation. The GCP professional services even has an example here. The python service_account code is closer to the Java JwtCredentials than to the ImpersonatedCredentials. Unfortunately, the JwTCredentials does not take another Credentials as signer. Is ImpersonatedCredentials meant to support domain-wide delegation, or should we make a feature request for JwTCredentials to accept another credential as signer? |
Hello,
For my use case, I have to impersonate a service account B (own by our customer) that has domain wide delegation enabled using another source service account A (own by us). The goal is to access all user emails that service account B has access to using service account A.
However, the access token retrieved doesn't have access to fetching user email, I got the error below:
By further examining the implementation of
createDelegated(String user)
ofImpersonatedCredentials
, it actually does not respect the input user, which is not what I was expecting:I'm using
I don't really know what could solve this issue for my unique use case, thoughts on this?
Thank you!
The text was updated successfully, but these errors were encountered: