首先distributedTaskContext
,就像 Patrick Lu 的回答所暗示的那样,它没有使用 NTLM 连接到 TFS。它与Authorization:Bearer
一个令牌连接。我使用相同的令牌来调用/_api/_common/GetUserProfile
返回当前用户的端点,并取回以下身份记录:
{
"IdentityType": "user",
"FriendlyDisplayName": "Project Collection Build Service (TEAM FOUNDATION)",
"DisplayName": "Project Collection Build Service (TEAM FOUNDATION)",
"SubHeader": "Build\\233e4ccc-d129-4ba4-9c5b-ea82c7ae1d15",
"TeamFoundationId": "7a3195ee-870e-4151-ba58-1e522732086c",
"EntityId": "vss.ds.v1.ims.user.7a3195ee870e4151ba581e522732086c",
"Errors": [],
"Warnings": [],
"Domain": "Build",
"AccountName": "233e4ccc-d129-4ba4-9c5b-ea82c7ae1d15",
"IsWindowsUser": false,
"MailAddress": ""
}
它看起来像是 TFS 为此目的而创建的某种人工身份。查看表中的 TFS 数据库tbl_Identity
,有许多具有类似名称的用户记录 - 似乎每个集合一个,还有一些是特定于项目的。
此用户属于称为“安全服务组”的服务器级组(也属于同名的集合级组)。这些组分别属于 Team Foundation Valid Users 和 Project Collection Valid Users,仅此而已。
至少在集合层面,“安全服务组”是可见的,包含了很多账户。
所有这些“构建服务”用户都属于名为“构建”的域。虽然域不是安全主体,但您不能授予域的权限。
说到 OAuth 范围。我使用相同的令牌来调用自制的“这个令牌的范围是什么”页面,结果证明distributedTaskContext
令牌只有一个 - app_token
。这是一个有效的范围,可以打开所有端点和所有方法(请参阅动态范围列表)。扩展清单中的scopes
参数与此无关;它只影响客户端的贡献。
然而,当谈到池可见性时,这个故事很棘手。似乎所有“项目集合构建服务”帐户都属于有效用户,但是将所有池的读者角色授予有效用户并不会在任务中向 REST API 打开它们。明确授予读者“项目集合构建服务”。但是,有许多这样的帐户(似乎每个集合一个) - 并且授予 Reader 仅打开池以释放它所在的集合中的定义。为了让所有集合中的发布中的任务读取池,您需要遍历所有集合并将 Reader 授予每个集合的“项目集合构建服务”。