-->

User Impersonation with Service Account using Appl

2019-09-16 01:43发布

问题:

I'm trying to use a service account with domain-wide delegation (DwD) on an App Engine deployment with Go.

I've followed the steps for using Google Application Default Credentials to use a service account with App Engine.

I got the code running locally on my dev machine but I'm stuck at retrieving the actual data from my domain.

I'm using the Admin SDK. Under the section Delegate domain-wide authority to your service account, it says that my "service account needs to impersonate one of those users to access the Admin SDK Directory API".

I've looked through the documentation for Go on using service account and user impersonation, AND I've also pored through the source code. Nowhere does it indicate where I can enter the user's email address/identity to impersonate.

Here is the error that I got:

googleapi: Error 404: Domain not found., notFound

The source code does show some clue but I faced other obstacles when trying to use something other than the Application Default Credentials.

Does anyone have any idea? Thanks in advance.

回答1:

It seems that for the Admin SDK I need to ask for the user (the administrator) permissions to access the Directory API. This is quite different from the other APIs where I simply just set the user email address to access the specified user's data.

It's understandable I guess since the Admin SDK is a far more powerful API affecting the domain and not just the individual user.



回答2:

Just come across this same problem today, but using 3-pronged OAuth2 wasn't really feasible, as we didn't want to alter the directory using the API, but rather check group membership for users who signed in via the App Engine Users API.

That led me to create this library: https://github.com/iamacarpet/go-gae-dwd-tokensource

It creates a custom JWT that supports impersonation, signs it with the default service account using the built in functionality, then fires it across to the token endpoint to get an access_token.

It isn't as efficient as the default function to get an access token, but in my testing, it was ~20ms latency vs ~450ms for a group membership check, so it wasn't an issue.

I've included an example of using it in a negroni middleware on the GitHub page.