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

问题描述

我正在考虑使用OAuth 2.0 服务帐户和，以将我们的服务与Google Apps集成.一个特殊的用例是:

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

• 当客户的Google Apps资源发生更改时，将适用的更改同步到我们的服务.

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

  var cred = new ServiceAccountCredential(new ServiceAccountCredential.Initializer("{SERVICEACCOUNTEMAIL}"){范围=新[]{DirectoryService.Scope.AdminDirectoryOrgunitReadonly}，用户="{[email protected]}"} .FromCertificate(x509cert)); 

如果我想

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

理想情况下，我不想将服务器上的自动后台进程与特定的Google Apps用户结合使用，以使资源与域管理员或用户可能在Google Apps方面进行的更改保持同步.

我不想指定用户.所以我的主要问题是，我要使用正确的授权模型进行尝试吗?

我的第二个问题更多地放在一边.委托已授予对域资源的访问权限时，要求模拟使用Admin API的目的是什么?与普通的OAuth 2.0授权工作流程相反，我不必代表用户 authorize ，我只需要指定她的电子邮件地址即可.我是否缺少服务帐户/委托访问模型的意图?

解决方案

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

对于您要调用的API，只有域管理员才能访问这些API.凭借您被授予的范围以及模仿该管理员的能力，您可以访问这些API.

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

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?

解决方案

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

这篇关于为什么具有委派域访问权限的服务帐户仍需要模拟?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！