|
1 |
| -If your company is using Microsoft Entra ID or Okta as your IdP for your enterprise in GitHub's cloud, you can use team synchronization to manage team membership within each organization through IdP groups. With team synchronization enabled, changes made in an IdP group are automatically reflected on GitHub. This feature reduces the need for manual updates and custom scripts. You can centrally manage users' identities, allowing authorization, review, and revocation of permissions. |
| 1 | +If your company uses Microsoft Entra ID or Okta as your identity provider (IdP), you can manage GitHub team membership through **team synchronization**. When enabled, team sync automatically reflects changes in IdP groups on GitHub—reducing the need for manual updates or custom scripts. This centralized approach simplifies onboarding, permissions management, and access revocation. |
2 | 2 |
|
3 |
| -When you synchronize a GitHub team with an IdP group, changes to the IdP group are reflected on GitHub automatically, reducing the need for manual updates and custom scripts. You can use an IdP with team synchronization to manage administrative tasks such as onboarding new members, granting new permissions for movements within an organization, and removing member access to the organization. |
| 3 | +| Feature | Description | |
| 4 | +|-----------------------|-----------------------------------------------------------------------------| |
| 5 | +| Sync Users | Keep GitHub `Teams` aligned with IdP (e.g., Active Directory) group membership | |
| 6 | +| Sync on New Team | Automatically populate teams at creation | |
| 7 | +| Custom Team Mapping | Use `syncmap.yml` to define custom mappings between team slugs and group names | |
| 8 | +| Dynamic Config | Use a `settings` file to derive sync settings from your directory structure | |
4 | 9 |
|
5 |
| -Managing a team via your service provider allows you to save time and resources that you'd otherwise spend duplicating in GitHub the information about your team that's already captured in your IdP. The Administrator of your IdP will need to enable SAML SSO and SCIM to implement team synchronization. |
| 10 | +## Team Synchronization Use Cases |
| 11 | + |
| 12 | +Team sync is ideal for enterprises looking to streamline membership management within GitHub organizations. Admins can map GitHub teams to IdP groups and manage memberships automatically. This is particularly useful for: |
| 13 | + |
| 14 | +- Onboarding new employees |
| 15 | +- Adjusting access as users move between teams |
| 16 | +- Removing users who leave the organization |
| 17 | + |
| 18 | +> ⚠️ To use team sync, your IdP admin must enable **SAML SSO** and **SCIM**. |
6 | 19 |
|
7 |
| -| Features | Description | |
8 |
| -| ---------------------- | ------------------------------------------------------------ | |
9 |
| -| Sync Users | Add or remove users from `Teams` in GitHub to keep in sync with Active Directory groups | |
10 |
| -| Sync on new team | Synchronize users when a new team is created | |
11 |
| -| Custom team/group maps | The team `slug` and group name will be matched automatically, unless you define a custom mapping with `syncmap.yml` | |
12 |
| -| Dynamic Config | Utilize a `settings` file to derive Active Directory and GitHub settings | |
13 | 20 |
|
14 | 21 | ## Enterprise Managed Users
|
15 | 22 |
|
16 |
| -Team synchronization is also available for organizations and enterprise accounts that use GitHub Enterprise Cloud. Enterprise Managed Users is a feature of GitHub Enterprise Cloud that provides even greater control over enterprise members and resources. |
| 23 | +If you're using **Enterprise Managed Users** in GitHub Enterprise Cloud, all members are provisioned through your IdP. Users do not self-manage GitHub accounts and cannot access resources outside the enterprise. |
| 24 | + |
| 25 | +With this model, you can: |
| 26 | + |
| 27 | +- Manage organization/team membership directly through your IdP |
| 28 | +- Ensure GitHub users are enterprise-scoped and isolated |
| 29 | + |
| 30 | +For more, see [Getting started with GitHub Enterprise Cloud](https://docs.github.com/get-started/onboarding/getting-started-with-github-enterprise-cloud). |
| 31 | + |
17 | 32 |
|
18 |
| -When you use Enterprise Managed Users, all members are provisioned and managed through your IdP. Users don't create their own accounts on GitHub. You can manage organization and team membership by using groups on your IdP. Managed user accounts are restricted to their enterprise and can't push code, collaborate, or interact with users, repositories, or organizations outside of their enterprise. For more information, see [Getting started with GitHub Enterprise Cloud](https://docs.github.com/get-started/onboarding/getting-started-with-github-enterprise-cloud). |
19 | 33 |
|
20 |
| -## Usage limits |
| 34 | +## Team Synchronization vs. SCIM for GHES |
21 | 35 |
|
22 |
| -When using the team synchronization feature, there are specific usage limits you need to know about. Exceeding these limits can lead to unexpected performance, and might cause synchronization failures. |
| 36 | +In GitHub Enterprise Server (GHES), managing user access and team memberships can be achieved through various methods, including team synchronization and System for Cross-domain Identity Management (SCIM). Understanding these methods is essential for effective administration. |
23 | 37 |
|
24 |
| -- Maximum number of members in a GitHub team: 5,000 |
25 |
| -- Maximum number of members in a GitHub organization: 10,000 |
26 |
| -- Maximum number of teams in a GitHub organization: 1,500 |
| 38 | +### Team Sync in GHES |
27 | 39 |
|
28 |
| -## Enable team synchronization |
| 40 | +Team synchronization allows you to link GitHub teams with groups in your Identity Provider (IdP). This integration ensures that any changes in the IdP group—such as adding or removing members—are automatically reflected in the corresponding GitHub team. This approach streamlines team management by centralizing user access control within the IdP. |
29 | 41 |
|
30 |
| -With team synchronization, you can use your IdP to manage administrative tasks like onboarding new members, granting new permissions in your organization, and removing member access. When you synchronize a GitHub team with an IdP group, changes made to the IdP group are reflected on GitHub automatically, reducing the need for manual updates and custom scripts. The steps to enable team synchronization depend on the IdP you use. |
| 42 | +However, it's important to note that team synchronization is not a user provisioning service and does not invite non-members to join organizations in most cases. This means a user will only be successfully added to a team if they are already an organization member. |
31 | 43 |
|
32 |
| -You can enable and use team synchronization, but only with the following supported IdPs: |
| 44 | +Consider the following scenario to understand how team synchronization works in practice: |
33 | 45 |
|
34 |
| -- Microsoft Entra ID |
35 |
| -- Okta |
| 46 | +- Azure AD group "DevOps Engineers" maps to GitHub team "DevOps" |
| 47 | +- Alice is added to the IdP group → automatically added to the GitHub team |
| 48 | +- If she leaves the group → automatically removed from the team |
36 | 49 |
|
37 |
| -The steps to enable team synchronization depend on the IdP you want to use. There are prerequisites to enable team synchronization that apply to each IdP. To enable team synchronization with your IdP, you must obtain administrative access or work with your IdP administrator to configure the IdP integration and groups. After you enable team synchronization, team maintainers and organization owners can connect a team to an IdP group on GitHub or through the API. |
| 50 | +**Note:** Team Sync in GHES doesn’t provision accounts. Users must already be GitHub organization members. |
38 | 51 |
|
39 |
| -**Microsoft Entra ID**: The GitHub System Admin for the GitHub organization will need to identify and work with the Microsoft Entra Administrator to configure Team Synchronization. On the Microsoft Entra ID side, the service is called "automatic user account provisioning." To enable team synchronization for Microsoft Entra ID, the installation needs the following permissions: |
| 52 | +### Team Sync Configuration |
40 | 53 |
|
41 |
| -- Read all users’ full profiles |
42 |
| -- Sign in and read user profiles |
43 |
| -- Read directory data |
| 54 | +1. Enable SAML SSO and SCIM in your IdP. |
| 55 | +2. Map GitHub teams to IdP groups via GitHub UI or API. |
| 56 | +3. Changes in group membership sync automatically to GitHub. |
44 | 57 |
|
45 |
| -**Okta**: To enable team synchronization for Okta, you or your IdP administrator must: |
| 58 | +Supported IdPs: |
| 59 | +- **Microsoft Entra ID**: Requires permissions for profile reading and directory access. |
| 60 | +- **Okta**: Requires SAML SSO, SCIM, tenant URL, and SSWS token with read-only admin access. |
46 | 61 |
|
47 |
| -- Enable SAML SSO and SCIM for your organization using Okta. |
48 |
| -- Provide the tenant URL for your Okta instance. |
49 |
| -- Generate a valid SSWS token with read-only admin permissions for your Okta installation as a service user. |
| 62 | +### Disable Team Sync |
50 | 63 |
|
51 |
| -## Disable team synchronization |
| 64 | +To disable: |
52 | 65 |
|
53 |
| -When you disable team synchronization, any team members who were assigned to a GitHub team through the IdP group are removed from the team and may lose access to your organization's repositories. You can disable this feature through the organization settings by selecting **Your organization** and selecting **Settings**. Next, select **Organization security** and choose **Disable team synchronization**. |
| 66 | +1. Navigate to **Settings** > **Organization security** |
| 67 | +2. Click **Disable team synchronization** |
54 | 68 |
|
55 | 69 | :::image type="content" source="../media/disable-team-synchronization.png" alt-text="Screenshot of the organization setting to disable team synchronization." :::
|
| 70 | + |
| 71 | +> Note: Disabling sync removes users from teams if they were added via IdP mapping. |
| 72 | +
|
| 73 | +### SCIM in GHES |
| 74 | +SCIM is an open standard protocol designed to automate the exchange of user identity information between identity domains and IT systems. In the context of GHES, SCIM enables administrators to provision, update, and deprovision user accounts directly through the GitHub API. This means you can create, update, and delete user accounts, and sync group information to map GitHub team memberships. |
| 75 | + |
| 76 | +SCIM is particularly useful for managing user lifecycles at scale, ensuring that user data remains consistent across systems. |
| 77 | + |
| 78 | +Consider the following scenario to understand how SCIM works in practice: |
| 79 | +- Okta SCIM integration provisions GitHub users automatically |
| 80 | +- Bob is added to Okta → GitHub account is provisioned |
| 81 | +- Bob changes roles → access and teams update |
| 82 | +- Bob leaves → account is deprovisioned |
| 83 | + |
| 84 | +**Key Benefit:** Full automation for account lifecycle management. |
| 85 | + |
| 86 | +## Team Sync vs. Group SCIM |
| 87 | + |
| 88 | +GitHub supports two primary identity integration approaches: |
| 89 | + |
| 90 | +- **Team Sync**: Focused on syncing group membership to GitHub teams |
| 91 | +- **Group SCIM**: Focused on full lifecycle management of users and groups |
| 92 | + |
| 93 | +### Differences Between Team Sync and Group SCIM |
| 94 | + |
| 95 | +| Feature | Team Sync | Group SCIM | |
| 96 | +|--------------------------|-----------------------------------------------|----------------------------------------------| |
| 97 | +| Focus | Team-level mapping | User and group provisioning | |
| 98 | +| Setup | Manual group-to-team mapping | Automated via IdP SCIM config | |
| 99 | +| Automation Level | Syncs group membership only | Full lifecycle automation | |
| 100 | +| Ideal Use Case | GitHub Teams management | Large orgs with high user turnover | |
| 101 | +| Deprovisioning | Manual or IdP-group dependent | Fully automated | |
| 102 | +| Identity Model | Classic | Managed Users | |
| 103 | + |
| 104 | + |
| 105 | +## Choosing the Right Approach |
| 106 | +The choice between Team Sync and Group SCIM depends on your organization’s needs, size, and existing identity management infrastructure: |
| 107 | + |
| 108 | +| Use Case | Recommended Solution | |
| 109 | +|----------------------------------|----------------------| |
| 110 | +| Manage repository access by teams| Team Sync | |
| 111 | +| Automate user lifecycle | Group SCIM | |
| 112 | +| Need full IdP-based governance | Group SCIM | |
| 113 | +| GitHub Teams are core to workflow| Team Sync | |
| 114 | + |
| 115 | + |
| 116 | +## Usage Limits |
| 117 | + |
| 118 | +When using team synchronization, observe these limits: |
| 119 | + |
| 120 | +- Max members per team: **5,000** |
| 121 | +- Max members per organization: **10,000** |
| 122 | +- Max teams per organization: **1,500** |
| 123 | + |
| 124 | +Exceeding these may result in performance issues or sync failures. |
0 commit comments