{"id":143,"date":"2019-06-24T03:03:00","date_gmt":"2019-06-24T03:03:00","guid":{"rendered":"https:\/\/blog.devopsabcs.com\/?p=143"},"modified":"2023-09-23T03:11:24","modified_gmt":"2023-09-23T03:11:24","slug":"one-project-to-rule-them-all-3","status":"publish","type":"post","link":"https:\/\/blog-dev-001-bcdr.devopsabcs.com\/index.php\/2019\/06\/24\/one-project-to-rule-them-all-3\/","title":{"rendered":"One Project To Rule Them All"},"content":{"rendered":"\n

Part 3: Security<\/h3>\n\n\n\n

In Part 1 of the series<\/a> (first showcased on Microsoft’s Premier Developer Blog<\/a>), we discussed the business value of taking a single organization, single project approach in your Azure DevOps journey. In Part 2<\/a>, we covered the fundamental techniques on which the Migration Tool<\/strong> relies. In this post, we will talk about security considerations and techniques.<\/p>\n\n\n\n

Security Requirements can vary widely from one enterprise to another. Under certain circumstances, it may even be a reason to deviate from the “One Project To Rule Them All” strategy and add another project<\/a>.<\/p>\n\n\n\n

That being said, Azure DevOps offers a high level of granularity and control<\/a> from the organization level all the way down to object-level permissions. For many enterprises, this is sufficient to adopt the “One Project To Rule Them All” approach.<\/p>\n\n\n\n

Security is the 4th stage of the Migration Tool<\/b>. In this stage, we take a simplified approach: give the migrated project’s default team the default Contributor permissions and access<\/a> to all of the project’s migrated items. Though simplified, the approach is complex enough to illustrate the main techniques in dealing with security in Azure DevOps. An enterprise can easily adopt these techniques to implement different, more complex, security configurations. Furthermore, a tailored structured approach is an opportunity to consolidate and standardize your security strategy in Azure DevOps.<\/p>\n\n\n\n

The heart of setting access control entries using the REST API is through the following HTTP POST call<\/a>:<\/p>\n\n\n\n

POST https:\/\/dev.azure.com\/{organization}\/_apis\/accesscontrolentries\/{securityNamespaceId}?api-version=5.0<\/code><\/pre>\n\n\n\n
\"\"<\/a>
Set Access Control Entries<\/figcaption><\/figure>\n\n\n\n
As with many POST calls, setting access control entries requires a request body<\/em>. The Microsoft Documentation provides this example:<\/p>\n\n\n\n
{\n  \"token\": \"newToken\",\n  \"merge\": true,\n  \"accessControlEntries\": [\n    {\n      \"descriptor\": \"Microsoft.TeamFoundation.Identity;S-1-9-1551374245-1204400969-2402986413-2179408616-0-0-0-0-2\",\n      \"allow\": 8,\n      \"deny\": 0,\n      \"extendedinfo\": {}\n    }\n  ]\n}<\/code><\/pre>\n\n\n\n
We will go over each detail, as each deserves special attention:<\/p>\n\n\n\n