Why does a service account with delegated domain access still need impersonation?

Question

I am considering using OAuth 2.0 service accounts and domain-wide delegation of authority to integrate our service with Google Apps. A particular use case is:

• When Google Apps customer signs up for our service, pre-provision our service leveraging the customer's existing org structure or resources (orgunits, groups, devices, users, folders, files, etc.).

• When the customer's Google Apps resources change, synchronize applicable changes to our service.

I found that when using service accounts, I need to specify the email address of an authorized super user for the domain that I'm querying, like this:

var cred = new ServiceAccountCredential( new ServiceAccountCredential.Initializer( "{SERVICEACCOUNTEMAIL}" )
  {
     Scopes = new[]
              {
                 DirectoryService.Scope.AdminDirectoryOrgunitReadonly
              },
     User = "{USERTOIMPERSONATE@customergadomain.com}"
  }.FromCertificate( x509cert ) );

if I want to e.g.

1. Query all orgunits or groups in the domain
2. Query all folders owned by the organization, or folders for a specific user

Ideally, I would not want to have to couple automated background processes on our server with a specific Google Apps user, in order to keep the resources in sync with changes that the domain's admin or users might incur on the Google Apps side.

I don't want to have to specify the user. So my main question is, am I using the correct authorization model for what I'm trying to do?

My second question is more of an aside. What is the purpose of requiring impersonation to use the Admin APIs, when delegation has already granted access to the domain's resources? In contrast to the normal OAuth 2.0 authorization workflow, I don't have to authorize on behalf of the user, I just have to specify her email address. Am I missing an intent of the service account / delegated access model?

Answer 1

The domain-wide delegation model allows a service account to impersonate a user and thus obtain the same privileges in the domain that the user identity + set of scopes granted to the application imply.

In the case of the APIs you're calling, only a domain administrator can access those APIs. By virtue of the scope you have been granted + the ability to impersonate such administrator, you can access those APIs.

If the task were to access a single resource owned by the administrator (say an organization's calendar), it'd be possible for the administrator to share that resource with the service account and then the service account might be able to impersonate itself to access that resource. However, in the case of an entire API, which represents many collections of resources, it is not feasible to use ACLs and the only practical approach is to grant the service account the ability to impersonate directly the administrator for specific API(s).