为什么具有委派域访问权限的服务帐户仍需要模拟？

Question

我正在考虑使用OAuth 2.0 服务帐户和域范围授权将我们的服务与Google Apps集成.一个特定的用例是:

• 当Google Apps客户注册我们的服务时,请使用客户现有的组织结构或资源(组织,组,设备,用户,文件夹,文件等)预先配置我们的服务.

• 当客户的Google Apps资源发生变化时,请将适用的更改与我们的服务同步.

我发现在使用服务帐户时,我需要为我要查询的域指定授权超级用户的电子邮件地址,如下所示:

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

如果我想要例如

1. 查询域中的所有orgunits或组
2. 查询组织拥有的所有文件夹或特定用户的文件夹

理想情况下,我不希望将我们服务器上的自动后台流程与特定的Google Apps用户结合使用,以使资源与域管理员或用户可能在Google Apps端产生的更改保持同步.

我不想指定用户.所以我的主要问题是,我正在使用正确的授权模型来实现我的目标吗？

我的第二个问题不仅仅是一个问题.当委派已授予对域资源的访问权限时,要求模拟使用Admin API的目的是什么？与普通的OAuth 2.0授权工作流程相比,我不必代表用户进行授权,我只需要指定她的电子邮件地址即可.我是否错过了服务帐户/委托访问模型的意图？

Answer 1

域范围的委派模型允许服务帐户模拟用户，从而在域中获得与授予应用程序的用户身份 + 范围集所暗示的相同权限。

对于您调用的 API，只有域管理员才能访问这些 API。凭借您被授予的范围+模拟此类管理员的能力，您可以访问这些 API。

如果任务是访问管理员拥有的单个资源（例如组织的日历），则管理员可以与服务帐户共享该资源，然后服务帐户可能能够冒充自己来访问该资源资源。但是，对于代表许多资源集合的整个 API，使用 ACL 是不可行的，唯一实用的方法是授予服务帐户直接模拟特定 API 管理员的能力。