如何在 Azure Devops 中使用服务帐户模拟用户

Question

我创建了一个服务帐户来模拟我组织中的用户，以便以用户的名义更改工作项。我已经将该服务帐户添加到“项目收集服务帐户”组中，该组的“代表他人提出请求”设置为“允许”。服务帐户具有 Visual Studio 订阅。

然后，我使用与本地 TFS 配合使用的代码来执行模拟，并收到错误 500，提示“访问被拒绝：X 需要以下权限才能执行此操作：发出请求代表他人”

我应该怎么做才能让它工作？这是我正在使用的代码：

        var credential = new VssAadCredential("X@myoganization", "password");
        var collection = new TfsTeamProjectCollection(new Uri("my_devops_uri"), credential);
        MyTfsConnection.ProjectCollection = collection;

        MyTfsConnection.IdentityService = collection.GetService<IIdentityManagementService>();
        MyTfsConnection.WIStore = collection.GetService<WorkItemStore>();

        var adAccount = "someone@myoganization";
        var identity = MyTfsConnection.IdentityService.ReadIdentity(IdentitySearchFactor.AccountName, adAccount, MembershipQuery.None, ReadIdentityOptions.None);
        using (var impersonatedCollection = new TfsTeamProjectCollection(new Uri("my_devops_uri"), credential, identity.Descriptor))
        {

            var impersonatedWIStore = impersonatedCollection.GetService<WorkItemStore>();
        }

Answer 1

它无法做到这一点，服务帐户不打算将客户端连接与服务器签入代码或更改工作项。

服务帐户用于运行与 TFS 相关的各种服务。它应该在机器上拥有尽可能低的权限。

客户端不应使用服务帐户连接到服务器，他们应该使用自己的帐户，您授予对 TFS 中相关存储库的访问权限。例如，如果您将所有客户端都连接到服务帐户，您如何知道谁签入了每个变更集，应该将工作项分配给谁？

您也无法将工作项分配给服务帐户。

Answer 2

我一直在尝试将代码迁移到使用模拟来更改另一个用户名中的工作项的 DevOps 服务。不可思议的是它和你的相似。几乎就像我们都从这个old post on TFS impersonation 中得到了它。与您的代码一样，此代码适用于本地 DevOps Server 2019.1.1，但我在尝试使其适用于 DevOps Services 时遇到了同样的问题。

在寻找适用于 TFS/DevOps (SOAP) 客户端 API 和 DevOps 服务的答案时，我遇到了this SO question，该问题引用了以下内容。

“出于安全原因（以及合规性和许多其他原因）， Visual Studio Online 不支持模拟标头"

我还没有在文档的任何地方找到相同的信息。然而，这似乎是真的。 Azure DevOps Services 中禁用模拟。呸！

不放弃，我的搜索还出现了来自the November 2017 release notes的以下内容，看起来很有希望。

向特定用户授予绕过规则权限

通常，当从其他来源迁移工作项时，组织 想要保留工作项的所有原始属性。为了 例如，您可能想要创建一个保留原始的错误 创建日期并由系统中的值创建 起源。

更新工作项的 API 有一个 bypassrule 标志来启用它 设想。以前发出该 API 请求的身份必须是 项目集合管理员组的成员。有了这个 部署我们在项目级别添加了执行权限 带有 bypassrule 标志的 API。

但是，我在 DevOps Server 或 DevOps Services 上的集合/组织或项目权限中找不到此类权限。又来啦！这让我找到了this SO answer，其中工作项更新是直接使用 REST API 以 JSON 格式制作的。所以绕过规则选项必须仍然有效，只是没有公开为可设置的权限。

所以我再次开始查看 TFS / DevOps (SOAP) 客户端 API，并发现 WorkItemStoreFlags.BypassRules 标志在创建时传递给 WorkItemStore。以下内容应提供基本机制。

// Use a personal access token with Work Items scope
var credentials = new VssBasicCredential(String.Empty, "Your PAT");

// Connect with TFS / DevOps client libs.
// Older SOAP based client but still works with DevOps Services.
var teamProjectCollection = new TfsTeamProjectCollection(new Uri("https://dev.azure.com/your-org"), credentials);

// Don't use teamProjectCollection.GetService<WorkItemStore>().  
// New up WorkItemStore using the collection and explicitly specify the BypassRules flag.
// This allows you to set the CreatedBy field later.
var workItemStore = new WorkItemStore(teamProjectCollection, WorkItemStoreFlags.BypassRules);

// Get the project, work item type, and create the new work item.
var project = workItemStore.Projects["YourProject"];
var workItemType = project.WorkItemTypes["Product Backlog Item"];
var workItem = new WorkItem(workItemType);

// Set the work item fields
workItem.Title = "The Title";
// Without the BypassRules flag the CreatedBy value set here will be ignored on
// Save() and replaced with the user account attached to the PAT used to authenticate.
workItem.Fields[CoreField.CreatedBy].Value = "NotYourUser@yourdomain.com";
workItem.Fields[CoreField.AssignedTo].Value = "NotYourUser@yourdomain.com";
workItem.Save();