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 = "{[email protected]}"
  }.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?

Perishing

Good question +1 this has puzzled me also, I have done the domain wide delegation but ultimately I send all requests authenticated as the domain administrator... – Albertina

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).

Humph

Thanks breno. I think I understand why ACLs are impractical across many collections of resources. I think the heart of my question is why, then, if the nature of a service account is to act as an administrator, why we have to explicitly impersonate one? – Perishing

ACL enforcement is based on user accounts, not roles. Administrators can have privileges over different sets of resources. For instance, if a regular user in your domain shares a document with administrator account #1, then a service account impersonating adm. account #2 will not have access to the document. – Humph

On a related note, I've found that I need to have the domain admin go to their domain's Admin Panel > Security > 'Manage API Client Access' and add the scopes my service account is requesting in order for the service account to be able to successfully impersonate the admin. Are you guys running into this as well or were you able to automate this step? – Occultation

I was wondering about "...obtain the same privileges in the domain that the user identity + set of scopes granted to the application imply..." Does this mean an application impersonating, say, a super admin is not actually limited by its scopes? – Zephyrus