8

我正在考虑使用 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. 查询域中的所有组织单位或组
  2. 查询组织拥有的所有文件夹，或特定用户的文件夹

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

我不想指定用户。所以我的主要问题是，我是否使用正确的授权模型来做我想做的事情？

我的第二个问题更多的是旁白。当委派已授予对域资源的访问权限时，要求模拟以使用管理 API 的目的是什么？与正常的 OAuth 2.0 授权工作流程相比，我不必代表用户进行授权，我只需指定她的电子邮件地址。我是否缺少服务帐户/委托访问模型的意图？

4

1 回答 1

3

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

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

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

于 2014-01-27T02:27:10.147 回答