Open tzhou2021 opened 3 years ago
@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, I have the same problem. Does Google Auth not support impersonation + domain-wide delegation? If not, it's certainly a design flaw.
@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:
@Override public GoogleCredentials createDelegated(String user) { return this.toBuilder().setServiceAccountUser(user).build(); }
@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?
@TimurSadykov
We are also seeing the same problem in our Appengine Java app. The details are below:
ImpersonatedCredentials.newBuilder()
.setSourceCredentials(GoogleCredentials.getApplicationDefault())
.setTargetPrincipal(service_account_S_email)
.setScopes(requiredScopesList)
.build();
The error message we get back is
{
"code": 403,
"errors": [
{
"domain": "global",
"message": "Not Authorized to access this resource/api",
"reason": "forbidden"
}
],
"message": "Not Authorized to access this resource/api"
}
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?
Following... Our org will disallow using SA Key soon. It would be great if our APP's SA can just impersonate domain-wide delegation SA. It might be a more common case now as using SA key is discouraged as it does introduce security risks?
It's been 2+ years since this issue opened, is there any workaround? Thanks
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!