AI-powered code assistant tools like GitHub Copilot have revolutionized the development landscape. We’ve observed significant Copilot adoption among Global System Integrators (GSIs), who are leading the charge in harnessing its potential. While many developers are already utilizing GitHub Copilot in their internal projects, GSI’s are eager to integrate Copilot into their own application development lifecycles. In response, several GSIs are considering extending their GitHub Copilot licenses to their end customers and partners. For some of these customers, development environments are managed within Offshore Development Centers (ODCs) located in various parts of the world.

In this article we will outline a strategic approach for enabling GitHub Copilot for developers working in ODCs, leveraging the Copilot seats provided by their employers, the GSIs. This will demonstrate how to maximize productivity and collaboration across distributed teams while utilizing this powerful tool.

How GitHub Copilot setup works?

Figure 1: GitHub Copilot authentication architecture

One of the use cases of accessing GitHub copilot is using an OIDC/SAML based single sign on technique. This pattern of accessing copilot is called as copilot account enabled as enterprise managed user connectivity. With this approach, GSIs can restrict to only managed users(employees/contractors) within their organizational boundary.

In the above diagram we assume that enterprises configure GitHub copilot Azure Entra. Other SSOs like Okta and Ping are also supported. Moreover, any IDP with SAML support is also being supported.

You can read more on enterprise managed user here.

Key Components Involved in Setup

Before we enable developers to use GitHub copilot, admins do the following setup. Detailed setup instructions on setting up Copilot with enterprise managed users can be found here.

1. Logs into copilot instance and sets up enterprise and organizations
2. Links Azure subscription for billing purpose
3. In the Azure Entra tenant, creates an enterprise application for GitHub
4. Links the GitHub Enterprise app in Azure with the copilot instance.
5. Adds users to the enterprise app and runs the user provisioning workflow. As a result, the users flow automatically to the GitHub copilot instance.
6. Assigns copilot seat to the user

All, the developer has to do is, login to their IDE or Github.com and authorize the IDE to use Copilot.

Scenario – While there are multiple scenarios on how to leverage a GitHub copilot license, we will discuss about the scenario where we have a developer from a global system integrator organization working on customer projects. We will detail out the scenario as well as the approach for using GitHub copilot by the developers of the GSI organization.

Approach – Enabling GSI’s GitHub and Azure in customer ODCs

Problem statement – In the previously mentioned scenario, we had put across the construct where a developer from GSI org is working in a customer project. GSI organizations have already procured licenses for the developer. How do we enable the licenses to be leveraged in customer environment. There are few challenges involved typically in an ODC/Customer/non-GSI managed environment, especially when the license is procured by GSIs

• Usually, GitHub copilot usage is governed by access policies within an organization. If and when GitHub copilot is integrated with IDP and security of the organization, conditional access policies are applied. One of the conditional access policies can restrict the access of GitHub copilot from a GSI unmanaged device
• When working in customer’s ODC environment, external URL access is restricted (github.com or login.microsoft.com)
• The existing GitHub instance owned by the GSIs have users who are internal developers and have internal code repositories. Sharing the same instance to the developers working in customer projects exposes the risk of moving code in an out of the internal repositories.

Figure 2: Architecture – GSI owned GitHub copilot environment

Here are some key highlights of this approach.

Key Assumption

1. GitHub Copilot Admin will be from the GSI.

Prerequisites

1. GitHub Copilot URL list needs to be whitelisted by end customer in their environment.
2. Additionally, login.microsoftonline.com/* should be also whitelisted

Approach

• A new GitHub standalone instance needs to be created and setup with Azure Subscription for billing within GSIs’ environment. Managing of copilot licenses will be done by GSIs.
• The GitHub copilot standalone instance will not have features of GitHub enterprise. This means, the new instance will not have organization’s enabled owing to which repositories cannot be created inside the GitHub copilot standalone instance.
• The new GitHub copilot standalone instance should be enabled with Enterprise managed user (EMU). This means, it needs to be integrated with an IDP. For now, let’s consider the IDP is Azure AD.
• To enable integration with Azure AD, a new instance of enterprise application of the type “GitHub Enterprise managed user” should be created in the existing Azure tenant.
• Add the users/groups, who would be part of customer organization, to the new Entra enterprise app being created.
• GSI’s (Entra) is configured with GitHub Copilot App for authentication. Configure and integrate the new enterprise application using SAML with the new GitHub copilot standalone instance created.
• IDE and copilot plugin/extension will be installed in end customer’s environment/VM/Dev machines.
• Developer will login to the GitHub copilot owned and managed by the GSI from customer ODC environment or any external laptop/desktop not managed by the GSIs.
• The new enterprise application created in the GSI’s tenant, should be excluded from conditional access policy by the Entra Admin. This can selectively allow only the new instance to be exposed to outside the organization while keep the other applications under same access policies.
• Copilot authentication will be redirected to GSI’s IDP.
• GitHub Copilot and Microsoft Entra URLs will be whitelisted on the firewall of the customer environment​

User and license Management

• Once the IDP is connected admin (from GSI) will grant or remove licenses for users by managing membership of the teams, from the IdP.
• To manage membership from your IdP, ensure the relevant identity groups have been assigned to the GitHub Enterprise Managed User application in your IdP and pushed to GitHub via SCIM.
• How to create a team – Setting up a dedicated enterprise for Copilot Business (Enterprise Managed Users) – GitHub Enterprise Cloud Docs
• How to assign license to a team – Setting up a dedicated enterprise for Copilot Busine

Advantages of this approach

• Time taken to initiate a new project is minimal
• Management of copilot instance is centralized
• User will be completely managed by GSIs IDP and doesn’t have any dependencies on external customer/partner IDPs.

Building on the outlined approach, this strategy effectively bridges the gap between organizational governance and developer flexibility when utilizing GitHub Copilot in Offshore Development Centers (ODCs) or customer environments. By implementing a standalone Copilot instance integrated with Azure Entra and managed through enterprise-managed user (EMU) connectivity, Global System Integrators (GSIs) can address critical challenges such as restricted external URL access, unmanaged devices, and repository security risks.

This solution ensures secure, scalable, and centralized management of Copilot licenses, empowering developers to work efficiently while adhering to organizational policies. Key benefits include rapid project setup, enhanced security, and independence from external customer IDPs, fostering productivity and seamless collaboration across distributed teams. With this approach, GSIs can maximize the transformative potential of GitHub Copilot, driving innovation and success in modern application development environments.