Question

我正在考虑使用OAuth 2.0 service accounts和domain-wide delegation of authority将我们的服务与Google Apps集成。一个特定的用例是：

当Google Apps客户注册我们的服务时，请使用客户现有的组织结构或资源（orgunits，组，设备，用户，文件夹，文件等）预先配置我们的服务。
当客户的Google Apps资源发生变化时，请将适用的更改与我们的服务同步。

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

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

如果我想要，例如

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

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

我不想指定用户。所以我的主要问题是，我是否正在使用正确的授权模式来实现我的目标？

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

Answer 1

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

对于您要调用的API，只有域管理员才能访问这些API。根据您获得的范围+模仿此类管理员的能力，您可以访问这些API。

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

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

1 个答案: