Skip to content

Commit 3833c68

Browse files
authored
Merge branch 'main' into content/normalize-github-variables
2 parents 8da2ead + 37c03e1 commit 3833c68

File tree

16 files changed

+237
-49
lines changed

16 files changed

+237
-49
lines changed

content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-azure.md

Lines changed: 3 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -77,7 +77,6 @@ The [`azure/login`](https://github.com/Azure/login) action receives a JWT from t
7777

7878
The following example exchanges an OIDC ID token with Azure to receive an access token, which can then be used to access cloud resources.
7979

80-
8180
```yaml copy
8281
{% data reusables.actions.actions-not-certified-by-github-comment %}
8382
name: Run Azure Login with OIDC
@@ -93,9 +92,9 @@ jobs:
9392
- name: 'Az CLI login'
9493
uses: azure/login@8c334a195cbb38e46038007b304988d888bf676a
9594
with:
96-
client-id: ${{ secrets.AZURE_CLIENT_ID }}
97-
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
98-
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
95+
client-id: {% raw %}${{ secrets.AZURE_CLIENT_ID }}{% endraw %}
96+
tenant-id: {% raw %}${{ secrets.AZURE_TENANT_ID }}{% endraw %}
97+
subscription-id: {% raw %}${{ secrets.AZURE_SUBSCRIPTION_ID }}{% endraw %}
9998

10099
- name: 'Run az commands'
101100
run: |

content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-google-cloud-platform.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -103,7 +103,7 @@ jobs:
103103
- id: 'gcloud'
104104
name: 'gcloud'
105105
run: |-
106-
gcloud auth login --brief --cred-file="${{ steps.auth.outputs.credentials_file_path }}"
106+
gcloud auth login --brief --cred-file="{% raw %}${{ steps.auth.outputs.credentials_file_path }}{% endraw %}"
107107
gcloud services list
108108
```
109109

content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-jfrog.md

Lines changed: 4 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -69,7 +69,7 @@ jobs:
6969
id: setup-jfrog-cli
7070
uses: jfrog/setup-jfrog-cli@29fa5190a4123350e81e2a2e8d803b2a27fed15e
7171
with:
72-
JF_URL: ${{ env.JF_URL }}
72+
JF_URL: {% raw %}${{ env.JF_URL }}{% endraw %}
7373
oidc-provider-name: 'YOUR_PROVIDER_NAME'
7474
oidc-audience: 'YOUR_AUDIENCE' # This is optional
7575

@@ -85,20 +85,16 @@ jobs:
8585
8686
### Using OIDC Credentials in other steps
8787

88-
{% raw %}
89-
9088
```yaml
9189
{% data reusables.actions.actions-not-certified-by-github-comment %}
9290
- name: Sign in to Artifactory Docker registry
9391
uses: docker/login-action@v3
9492
with:
95-
registry: ${{ env.JF_URL }}
96-
username: ${{ steps.setup-jfrog-cli.outputs.oidc-user }}
97-
password: ${{ steps.setup-jfrog-cli.outputs.oidc-token }}
93+
registry: {% raw %}${{ env.JF_URL }}{% endraw %}
94+
username: {% raw %}${{ steps.setup-jfrog-cli.outputs.oidc-user }}{% endraw %}
95+
password: {% raw %}${{ steps.setup-jfrog-cli.outputs.oidc-token }}{% endraw %}
9896
```
9997
100-
{% endraw %}
101-
10298
## Further reading
10399
104100
* [OpenID Connect Integration](https://jfrog.com/help/r/jfrog-platform-administration-documentation/openid-connect-integration) in the JFrog documentation

content/actions/tutorials/build-and-test-code/ruby.md

Lines changed: 0 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -187,8 +187,6 @@ The `setup-ruby` actions provides a method to automatically handle the caching o
187187

188188
To enable caching, set the following.
189189

190-
{% raw %}
191-
192190
```yaml
193191
{% data reusables.actions.actions-not-certified-by-github-comment %}
194192
steps:
@@ -197,8 +195,6 @@ steps:
197195
bundler-cache: true
198196
```
199197

200-
{% endraw %}
201-
202198
This will configure bundler to install your gems to `vendor/cache`. For each successful run of your workflow, this folder will be cached by {% data variables.product.prodname_actions %} and re-downloaded for subsequent workflow runs. A hash of your `gemfile.lock` and the Ruby version are used as the cache key. If you install any new gems, or change a version, the cache will be invalidated and bundler will do a fresh install.
203199

204200
**Caching without setup-ruby**

content/actions/tutorials/build-and-test-code/swift.md

Lines changed: 0 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -124,8 +124,6 @@ jobs:
124124

125125
You can configure your job to use a single specific version of Swift, such as `5.3.3`.
126126

127-
{% raw %}
128-
129127
```yaml copy
130128
{% data reusables.actions.actions-not-certified-by-github-comment %}
131129
steps:
@@ -136,8 +134,6 @@ steps:
136134
run: swift --version # Swift 5.3.3
137135
```
138136

139-
{% endraw %}
140-
141137
## Building and testing your code
142138

143139
You can use the same commands that you use locally to build and test your code using Swift. This example demonstrates how to use `swift build` and `swift test` in a job:

content/admin/data-residency/network-details-for-ghecom.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -33,6 +33,7 @@ For more information, see [AUTOTITLE](/rest/meta/meta).
3333
* `*.githubassets.com`
3434
* `*.githubusercontent.com`
3535
* `*.blob.core.windows.net`
36+
* `auth.ghe.com`
3637

3738
## {% data variables.product.github %}'s IP addresses
3839

content/admin/guides.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -30,6 +30,7 @@ includeGuides:
3030
- /admin/concepts/identity-and-access-management/enterprise-managed-users
3131
- /admin/managing-iam/configuring-authentication-for-enterprise-managed-users/configuring-saml-single-sign-on-for-enterprise-managed-users
3232
- /admin/managing-iam/provisioning-user-accounts-with-scim/configuring-scim-provisioning-for-users
33+
- /admin/managing-iam/provisioning-user-accounts-with-scim/migrating-from-ldap-to-saml-with-scim
3334
- /admin/identity-and-access-management/provisioning-user-accounts-with-scim/configuring-scim-provisioning-using-okta
3435
- /admin/managing-iam/provisioning-user-accounts-with-scim/managing-team-memberships-with-identity-provider-groups
3536
- /admin/managing-iam/using-cas-for-enterprise-iam/using-cas

content/admin/managing-iam/provisioning-user-accounts-with-scim/index.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -13,6 +13,7 @@ topics:
1313
children:
1414
- /user-provisioning-with-scim-on-ghes
1515
- /configuring-scim-provisioning-for-users
16+
- /migrating-from-ldap-to-saml-with-scim
1617
- /configuring-authentication-and-provisioning-with-entra-id
1718
- /configuring-authentication-and-provisioning-with-pingfederate
1819
- /configuring-scim-provisioning-with-okta
Lines changed: 164 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,164 @@
1+
---
2+
title: 'Migrating from LDAP to SAML with SCIM'
3+
shortTitle: 'Migrate from LDAP'
4+
intro: 'Learn how to migrate your {% data variables.product.prodname_ghe_server %} instance from LDAP authentication to SAML single sign-on with SCIM provisioning for centralized user management.'
5+
permissions: 'Site administrators can migrate authentication methods on {% data variables.product.prodname_ghe_server %}.'
6+
versions:
7+
ghes: '>=3.17'
8+
type: how_to
9+
topics:
10+
- Accounts
11+
- Authentication
12+
- Enterprise
13+
- Identity
14+
- SSO
15+
---
16+
17+
## About migrating from LDAP to SAML and SCIM
18+
19+
If your {% data variables.product.prodname_ghe_server %} instance currently uses LDAP authentication, you can migrate to SAML single sign-on (SSO) with SCIM provisioning for enhanced user lifecycle management capabilities. This migration allows you to automatically provision, update, and deprovision user accounts from your identity provider (IdP).
20+
21+
{% data reusables.enterprise.saml-or-ldap %}
22+
23+
**Prerequisites:**
24+
25+
* You must be a site administrator on {% data variables.product.prodname_ghe_server %}.
26+
* You must have administrative access to your SAML identity provider.
27+
* Your IdP must support SAML 2.0 and SCIM 2.0 protocols.
28+
* You should complete a backup of your instance before beginning the migration.
29+
30+
SCIM provisioning requires SAML authentication as a prerequisite, so this migration involves four distinct phases:
31+
32+
1. **Migrate to SAML authentication**: Replace LDAP with SAML SSO.
33+
1. **Test and verify SAML**: Confirm authentication works and users link correctly.
34+
1. **Enable SCIM provisioning**: Add automated user management capabilities.
35+
1. **Test and verify SCIM**: Confirm provisioning links identities to existing accounts.
36+
37+
This document assumes familiarity with SAML authentication and SCIM provisioning. For more information on these topics, please see [AUTOTITLE](/admin/managing-iam/using-saml-for-enterprise-iam/configuring-saml-single-sign-on-for-your-enterprise) and [AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/user-provisioning-with-scim-on-ghes).
38+
39+
## 1. Understand LDAP vs SCIM user creation patterns
40+
41+
Before you begin the migration, it's important to understand the key differences between how LDAP and SCIM handle user management on {% data variables.product.prodname_ghe_server %}.
42+
43+
| Attribute | LDAP | SCIM |
44+
| --- | --- | --- |
45+
| **Appliance configuration** | You configure the user ID attribute (default `uid`) and other LDAP settings in the management console. This configuration determines how to map between LDAP users and GitHub users. For more information about configuring LDAP, see [AUTOTITLE](/admin/managing-iam/using-ldap-for-enterprise-iam/using-ldap#ldap-attributes). | Enable SAML authentication first, then configure SCIM provisioning with an authentication token. |
46+
| **User creation timing** | Just-in-time: Users are created on first sign-in after successful LDAP authentication. | Pre-authentication: Users must be provisioned via SCIM before they can authenticate. |
47+
| **Initial username source** | GitHub username is based on the normalized LDAP identifier configured during setup. | GitHub username is based on the normalized SCIM `userName` value from your IdP. |
48+
| **Username management** | Flexible: Administrators can change GitHub usernames independently of LDAP. Usernames can drift from LDAP identifiers over time while maintaining authentication through LDAP mappings. See [AUTOTITLE](/account-and-profile/reference/username-reference#changing-your-username). | Strict: GitHub usernames always correspond to the normalized SCIM `userName` from your IdP. Username changes on the GitHub side are not allowed. |
49+
| **User attribute control** | Hybrid: Some attributes managed by LDAP, others can be managed on the appliance. | Full IdP control: All user attributes are managed through SCIM updates from your IdP. |
50+
| **Authentication flow** | {% data variables.product.prodname_ghe_server %} authenticates with your LDAP server and looks up the existing LDAP mapping to locate the user. | During SAML SSO, an external identity lookup is performed to locate the provisioned user for authentication. |
51+
| **Key characteristic** | Hybrid system where GitHub user data (especially usernames) can be partially managed on the appliance independently of the LDAP server. | Full identity provider control: The state of GitHub users depends entirely on what the IdP sends through SCIM, and usernames cannot drift from the source system. |
52+
53+
### Username normalization and compatibility
54+
55+
{% data variables.product.prodname_ghe_server %} normalizes usernames according to specific rules that apply consistently across LDAP, SAML, and SCIM. Understanding these rules is critical for successful migration.
56+
57+
For more information about username normalization, see [AUTOTITLE](/admin/managing-iam/iam-configuration-reference/username-considerations-for-external-authentication#about-username-normalization).
58+
59+
## 2. Plan your migration
60+
61+
Before beginning the migration, you need to understand your current setup, prepare your identity provider, and establish backup access methods. The planning phase is critical to ensure a smooth transition.
62+
63+
### Preparing to map from LDAP to SCIM
64+
65+
The critical migration challenge is bridging between the LDAP and SCIM user management approaches:
66+
67+
**LDAP users (existing state)**:
68+
69+
* Have GitHub usernames that may have changed since initial creation
70+
* Retain authentication ability through LDAP mappings regardless of username changes
71+
72+
**SCIM users (target state)**:
73+
74+
* Must be provisioned before authentication
75+
* Must have GitHub usernames that match their normalized SCIM `userName` values
76+
* Can be linked to an external identity with their existing GitHub account during SCIM user provisioning, but only if the normalized SCIM `userName` matches their existing GitHub username
77+
78+
### Migration mapping requirements
79+
80+
To successfully link SCIM identities to existing LDAP users, you'll need to capture the current state of the users on your instance:
81+
82+
1. **Export existing GitHub usernames**: Use the site admin interface, API, or CLI to get a complete list of current GitHub usernames on your instance. For more information about the users API, see [AUTOTITLE](/rest/users/users?apiVersion=2022-11-28#list-users). For more information about the command-line utility to export users, see [AUTOTITLE](/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities#ghe-user-csv).
83+
1. **Map GitHub usernames to real users in your IdP**: Determine which identities correspond to each GitHub username in your enterprise.
84+
1. **Configure the SCIM `userName` attribute**: Ensure your IdP provisions SCIM users with `userName` values that match the existing GitHub usernames you would like to link.
85+
86+
**Important**: The target for mapping is always the **current GitHub username** on your instance, not the original LDAP User ID or any other identifier.
87+
88+
### Key planning considerations
89+
90+
**Important considerations:**
91+
92+
* **Downtime required**: This migration requires downtime during a maintenance window to change authentication settings.
93+
* **User impact**: After the migration, users will need to authenticate through your SAML IdP instead of LDAP credentials.
94+
* **Team membership**: LDAP team synchronization will be replaced by SCIM group provisioning if supported by your IdP. LDAP-mapped teams will need to be updated with an appropriate SCIM group where applicable.
95+
96+
### Capture the state of your LDAP configuration
97+
98+
Record your current LDAP setup to plan equivalent SAML/SCIM mappings:
99+
100+
{% data reusables.enterprise_site_admin_settings.access-settings %}
101+
{% data reusables.enterprise_site_admin_settings.management-console %}
102+
{% data reusables.enterprise_management_console.authentication %}
103+
1. Document the following LDAP settings:
104+
* **Domain base** and restricted user groups
105+
* **User ID attribute** (this was used to create GitHub usernames)
106+
* **Profile name, email, and other attribute mappings**
107+
* **Administrators group configuration**
108+
* **Team synchronization settings**
109+
1. Ensure you have saved a list of existing users on your instance that you will be linking to a SCIM identity.
110+
111+
## 3. Migrate to SAML and SCIM
112+
113+
Once you've completed planning, you can begin migrating from LDAP to SAML authentication. This involves configuring SAML on both your identity provider and {% data variables.product.prodname_ghe_server %}, then carefully testing the configuration before proceeding to SCIM.
114+
115+
**Important**: When configuring SAML, enable "Allow creation of accounts with built-in authentication" to reduce the number of steps required when enabling SCIM.
116+
117+
### Enabling SAML authentication
118+
119+
For detailed SAML configuration steps, see [AUTOTITLE](/admin/managing-iam/using-saml-for-enterprise-iam/configuring-saml-single-sign-on-for-your-enterprise).
120+
121+
After enabling SAML, test the authentication system before proceeding to SCIM. With any IdP account assigned to the SAML application configured against your instance, verify that you are able to successfully perform an SSO login.
122+
123+
**Do not proceed to SCIM until SAML authentication is working correctly.**
124+
125+
### Enable SCIM provisioning
126+
127+
After confirming SAML authentication works correctly, you can enable SCIM for automated user management. SCIM must be configured on both {% data variables.product.prodname_ghe_server %} and your identity provider.
128+
129+
For detailed steps to enable SCIM, see [AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/configuring-scim-provisioning-for-users).
130+
131+
#### Test SCIM provisioning
132+
133+
Test SCIM provisioning to ensure the SCIM provisioned users are linked to existing user accounts correctly.
134+
135+
For users who already have accounts from the LDAP/SAML migration:
136+
137+
1. **Assign user to SCIM application** in your IdP.
138+
1. **Verify automatic linking**: Check that SCIM automatically links to the existing account:
139+
* Users retain same username and account data
140+
* No duplicate accounts are created
141+
* SCIM identity shows as linked in the enterprise settings, and site admin interfaces. For more information, see [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/viewing-and-managing-a-users-saml-access-to-your-enterprise#viewing-a-linked-identity).
142+
1. **Review audit logs**: Look for `external_identity.scim_api_success` and `external_identity.provision` events showing successful linking to existing users.
143+
144+
For new users not previously in your instance:
145+
146+
1. **Verify user creation**: Check that the user appears in {% data variables.product.prodname_ghe_server %} with correct attributes.
147+
1. **Test authentication**: Confirm the new user can authenticate via SAML.
148+
1. **Test attribute updates**: Update user information in IdP and confirm changes sync.
149+
1. **Test deprovisioning**: Remove user access and confirm they are suspended.
150+
151+
### Roll out SCIM to all users
152+
153+
For all remaining users who aren't yet provisioned via SCIM:
154+
155+
1. **Gradually assign users** to the {% data variables.product.prodname_ghe_server %} application in your IdP.
156+
1. **Monitor linking process**: Watch for successful automatic linking based on username matching.
157+
1. **Track progress**: Use audit logs to monitor `external_identity` events for linking progress.
158+
1. **Address any conflicts**: Resolve username conflicts or mapping issues as they arise.
159+
160+
## 4. Update team and organization membership
161+
162+
After your migration, if you previously used LDAP group synchronization to control team memberships, you can replace those team mappings with SCIM groups. If reusing existing an team, you will need to remove all team members prior to linking an IdP group.
163+
164+
For more information, see [AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/managing-team-memberships-with-identity-provider-groups).

content/admin/managing-iam/understanding-iam-for-enterprises/changing-authentication-methods.md

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -42,3 +42,13 @@ Other issues you should take into consideration include:
4242
* **Two-factor authentication:** {% data reusables.enterprise_user_management.external_auth_disables_2fa %}
4343

4444
* **Fallback authentication for users with no account on your external authentication provider:** You can invite users to authenticate to {% data variables.location.product_location %} without adding them to your identity provider. For more information, see [AUTOTITLE](/admin/identity-and-access-management/managing-iam-for-your-enterprise/allowing-built-in-authentication-for-users-outside-your-provider).
45+
46+
{% ifversion scim-for-ghes-ga %}
47+
48+
## Migrating from LDAP to SAML and SCIM
49+
50+
If you're currently using LDAP and want to enable automated user provisioning and deprovisioning capabilities, you can migrate to SAML authentication with SCIM provisioning. This provides enhanced user lifecycle management while maintaining centralized authentication.
51+
52+
For detailed migration steps, see [AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/migrating-from-ldap-to-saml-with-scim).
53+
54+
{% endif %}

0 commit comments

Comments
 (0)