How to set up GitLab SAML SSO with Google Workspace

Single sign-on (SSO) simplifies user authentication and improves security by allowing employees to access multiple applications with one set of credentials. For organizations using both GitLab and Google Workspace, integrating SAML-based SSO streamlines access management and ensures your teams can collaborate seamlessly.

In this guide, we'll walk through configuring SAML authentication between Google Workspace and GitLab.com, including automatic group synchronization that maps Google Workspace groups to GitLab roles. By the end, your users will be able to sign in to GitLab using their Google credentials, and their permissions will automatically reflect their Google group memberships.

Note: This guide focuses on GitLab.com (SaaS). If you're using GitLab Self-Managed, the setup process differs slightly. Refer to the official GitLab SAML documentation for self-managed instances for detailed instructions.

What you'll need

Before getting started, make sure you have:

• Google Workspace with Super Admin access
• GitLab.com with a Premium or Ultimate tier subscription
• Owner role on a GitLab top-level group
• Users already existing in Google Workspace (they'll be created in GitLab automatically on first login)

Understanding the architecture

When you configure SAML SSO with group synchronization, here's what happens:

1. Authentication flow: Users navigate to GitLab's SSO URL and are redirected to Google Workspace to authenticate.
2. SAML assertion: After successful authentication, Google sends a SAML response containing user details and group memberships.
3. Automatic provisioning: GitLab creates the user account (if needed) and assigns them to groups based on their Google group memberships.
4. Permission sync: Each time users sign in, GitLab updates their group memberships and roles to match their current Google groups.

This setup provides several benefits:

• Centralized access control: You can manage user access through Google Workspace groups.
• Automatic provisioning: New users gain GitLab access on their first login.
• Dynamic permissions: User roles update automatically based on group membership changes.
• Enhanced security: You can leverage Google's authentication security features.
• Reduced administrative overhead: There is no need to manually manage GitLab group memberships.

Part 1: Get your GitLab SAML configuration values

First, you'll need to gather some information from GitLab that you'll use when creating the SAML application in Google Workspace. Here are the steps to take:

Step 1: Navigate to your GitLab group SAML settings

1. Sign in to GitLab.com.
2. Navigate to your top-level group (Note: SAML SSO can only be configured at the top-level group, not in subgroups).
3. In the left sidebar, select Settings > SAML SSO.

Step 2: Copy the required URLs

On the SAML SSO settings page, you'll see three important URLs. Copy and save these somewhere accessible — you'll need them shortly:

• Assertion consumer service URL: This is where Google will send SAML responses.
  • Format: https://gitlab.com/groups/your-group/-/saml/callback
• Identifier: Also called the Entity ID, this uniquely identifies your GitLab group.
  • Format: https://gitlab.com/groups/your-group
• GitLab SSO URL: This is the URL your users will use to sign in.
  • Format: https://gitlab.com/groups/your-group/-/saml/sso

Now you'll create a custom SAML application in Google Workspace that connects to your GitLab group.

Step 3: Access the Google Admin Console

1. Open a new browser tab and sign in to the Google Admin Console with a Super Administrator account.
2. Click the Menu icon (☰) in the top-left.
3. Navigate to Apps > Web and mobile apps.
4. Click Add App > Add custom SAML app.

Step 4: Configure the application name

1. In the App name field, enter GitLab (or your preferred name).
2. Optionally upload a GitLab logo as the app icon for easy recognition.
3. Click Continue.

Step 5: Download Google identity provider details

On the Google Identity Provider details page, you'll need to capture two pieces of information:

1. SSO URL: Copy this URL. It tells GitLab where to send authentication requests.
   • Example format: https://accounts.google.com/o/saml2/idp?idpid=C1234abcd
2. Certificate: Click the Download button to save the certificate file.
   • The file will be named something like: GoogleIDPCertificate-gitlab.pem
   • Save this file somewhere you can easily find it. You'll need it in the next section
3. Click Continue.

Step 6: Configure service provider details

This is where you'll use the GitLab URLs you copied in Step 2. Enter the following:

Click Continue when complete.

Step 7: Configure attribute mapping

Attribute mapping tells Google which user information to send to GitLab. You'll configure both basic user attributes and group membership.

Basic attributes

Add these three attribute mappings by clicking Add mapping for each:

Group membership configuration

This is the critical configuration that enables automatic group synchronization:

1. Scroll down to the "Group membership (optional)" section.
2. Under "Google groups", click "Search for a group".
3. Search for and select each Google Workspace group you want to synchronize with GitLab.
   • You can select up to 75 groups
   • Examples: Engineering, DevOps, Platform-Team, Security-Team
4. Under "App attribute", enter exactly: groups.
5. Click Finish.

Critical: The app attribute name MUST be exactly groups (lowercase). This is what GitLab expects to receive in the SAML response. Any other value or capitalization will prevent group synchronization from working.

Step 8: Enable the application for users

Your SAML app is created but not yet enabled. To make it available to users:

1. In the Google Admin Console, find your GitLab app in the Web and mobile apps list.
2. Click on the app to open its details.
3. In the left sidebar, click User access.
4. Select one of the following:
   • ON for everyone - Enables the app for all users in your organization
   • ON for some organizational units - Select specific organizational units
5. Click Save.

Note: Changes can take up to 24 hours to propagate, but typically take effect within a few minutes.

Part 3: Convert the certificate to SHA-1 fingerprint format

GitLab requires a SHA-1 certificate fingerprint, but Google's certificate download doesn't include this format directly. You'll need to convert it.

Step 9: Convert your certificate

You have two options for converting the certificate to the required format.

Option 1: Online conversion tool

This is a viable method if you're comfortable using a third-party tool:

1. Locate the certificate file you downloaded in Step 5:
   • Check your Downloads folder
   • The file name will be something like: GoogleIDPCertificate-gitlab.pem
2. Open the file in a text editor:
   • Mac: Right-click > Open With > TextEdit
   • Windows: Right-click > Open With > Notepad
   • Linux: Use your preferred text editor
3. Copy ALL contents of the file, including the header and footer:

      -----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAXqD...
(multiple lines of encoded text)
...kE7RnF6yQ==
-----END CERTIFICATE-----

    

4. Navigate to: A SHA-1 fingerprint conversion tool. This one is a good example.
5. Paste the certificate content into the text box.
6. Select "SHA-1" from the algorithm dropdown (not SHA-256!).
7. Click "Calculate Fingerprint".
8. Copy the resulting fingerprint - it will be in the format: XX:XX:XX:XX:XX:....

Option 2: Command-line conversion

If you prefer using the command line:

For Mac, Linux, or Windows with WSL:

      cd ~/Downloads
openssl x509 -noout -fingerprint -sha1 -inform pem -in "GoogleIDPCertificate-gitlab.pem"

    

The output will show:

      SHA1 Fingerprint=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX

    

Copy everything after SHA1 Fingerprint=.

Part 4: Complete your GitLab SAML configuration

Now that you have the Google SSO URL and certificate fingerprint, you can complete the GitLab side of the configuration.

Step 10: Enter Google identity provider details

Return to your GitLab browser tab (Settings > SAML SSO) and do the following:

1. Identity provider SSO URL:
   • Paste the SSO URL you copied from Google in Step 5
2. Certificate fingerprint:
   • Paste the SHA-1 fingerprint you generated in Step 9
   • Verify the format is correct: 59 characters with colons (XX:XX:XX:...)
3. Enable SAML authentication for this group:
   • Check this box to activate SAML SSO

Step 11: Configure security settings (recommended)

For enhanced security, consider enabling these additional options:

• "Enforce SAML authentication for web activity for this group"
  • Requires users to authenticate via SAML to access the GitLab web interface
• "Enforce SAML authentication for Git and Dependency Proxy activity for this group"
  • Requires SAML authentication for Git operations and dependency proxy access

Click Save changes to apply your configuration.

Step 12: Test your SAML configuration

Before proceeding with group synchronization, verify that basic SAML authentication works:

1. Open an incognito or private browsing window.
2. Navigate to your GitLab SSO URL.
   • Format: https://gitlab.com/groups/your-group/-/saml/sso
3. You should be redirected to the Google sign-in page.
4. Sign in with a Google Workspace account that has access to the GitLab app.
5. After successful authentication, you should be redirected back to GitLab.

If the test succeeds, you can proceed to configure group synchronization.

If the test fails, check the following:

• Verify the certificate fingerprint is SHA-1 format (not SHA-256).
• Confirm the SSO URL is correct.
• Ensure the user has access to the GitLab SAML app in Google Admin Console.
• Check that the ACS URL and Entity ID match exactly.

Part 5: Set up SAML group synchronization

Now it's time to map your Google Workspace groups to GitLab roles so that permissions are automatically managed based on group membership.

Step 13: Configure default membership role

As a security best practice, set a minimal default role for users who log in but don't belong to any mapped groups:

1. In your GitLab group, navigate to Settings > General.
2. Expand the Permissions and group features section.
3. Under Default membership role, select Minimal Access or Guest.
4. Click Save changes.

Step 14: Create SAML group links

SAML Group Links are the mappings between Google Workspace groups and GitLab roles. Here's how to create them:

1. In your GitLab group, navigate to Settings > SAML Group Links.
2. Click "Add new SAML Group Link".

For each Google Workspace group you want to sync:

SAML Group Name:

• Enter the exact name of your Google Workspace group
• This is case-sensitive and must match perfectly
• Example: Engineering (not engineering)
• To find the exact name: Google Admin Console > Directory > Groups

Access Level: Select the appropriate GitLab role:

• Minimal Access - Can see that the group exists
• Guest - Can view issues and leave comments
• Reporter - Can pull code, view issues, and create new issues
• Developer - Can push code, create merge requests, and manage issues
• Maintainer - Can manage project settings and members
• Owner - Full administrative control over the group

3. Click Save.
4. Repeat this process for each Google Workspace group you want to map.

Note: SAML group sync rules are enforced every time a user signs in. If a user's Google group membership matches a sync rule, their GitLab role will be automatically set to the configured access level, even if you've manually changed it to something different. For example, if you set up a sync rule that grants "Maintainer" access and then manually promote a user to "Owner," they'll be automatically downgraded back to "Maintainer" on their next SAML sign-in.

Best practices: To maintain custom access levels for specific users, do one of the following:

• Use SAML group sync only on your top-level group and manually manage permissions in subgroups
• Create separate Google groups for users who need elevated permissions
• Avoid setting up sync rules that would conflict with manual role assignments

Here's a practical example of how you might structure your group mappings:

Step 15: Verify your group links

After creating all your group links:

1. Review the complete list of SAML Group Links in Settings > SAML Group Links.
2. Verify each SAML Group Name exactly matches the corresponding Google Workspace group.
3. Verify each Access Level is appropriate for the intended purpose.
4. Check for any typos or extra spaces.

Part 6: Test the complete configuration

Now it's time to test the entire setup including group synchronization.

Step 16: Test with a real user

Choose a test user who meets these criteria:

• Has a Google Workspace account
• Is a member of at least one Google Workspace group you configured
• Has the GitLab SAML app enabled in Google Admin Console
• Ideally is not you (to ensure a realistic test)

To perform the test:

1. Open an incognito or private browsing window
2. Navigate to your GitLab SSO URL:
   • https://gitlab.com/groups/your-group/-/saml/sso
3. Sign in with the test user's Google Workspace credentials
4. The user should be:
   • Authenticated successfully
   • Redirected to GitLab
   • Automatically added to the GitLab group
   • Assigned the appropriate role based on their Google group membership

Step 17: Verify group membership and role assignment

Using your GitLab administrator account:

1. Navigate to your group in GitLab.
2. Select Manage > Members from the left sidebar.
3. Find the test user in the members list.
4. Verify the following:
   • User appears in the members list
   • User has the correct Max role based on their Google group(s)
   • Source column shows a SAML indicator

Part 7: Configure subgroup access (optional)

For larger organizations, you may want to provide more granular access control using GitLab subgroups. SAML Group Links can be configured at any level of your group hierarchy, allowing you to map different Google Workspace groups to specific teams or projects.

Understanding GitLab's subgroup structure

GitLab supports nested group hierarchies that can mirror your organizational structure:

      acme-corp/                          ← Top-level group (SAML configured here)
├── engineering/                    ← Subgroup
│   ├── backend/                   ← Nested subgroup
│   └── frontend/                  ← Nested subgroup
├── marketing/                      ← Subgroup
└── operations/                     ← Subgroup

    

Creating subgroups

If you need to create additional subgroups:

1. Navigate to your parent group (e.g., acme-corp).
2. Click the New subgroup button.
3. Configure the subgroup:
   • Subgroup name: Display name (e.g., Engineering)
   • Subgroup URL: URL slug (e.g., engineering)
   • Visibility level: Choose Private, Internal, or Public
4. Click Create subgroup.
5. Repeat for other subgroups as needed.

Configuring SAML group links for subgroups

Here are the steps to configure SAML group links for subgroups.

Add new Google groups to the SAML app (if needed)

If you're introducing new Google Workspace groups for subgroup access:

1. Go to Google Admin Console > Apps > Web and mobile apps > GitLab.
2. Click SAML attribute mapping.
3. Scroll to "Group membership (optional)".
4. Add your new groups (e.g., Backend-Team, Frontend-Team).
5. Verify the "App attribute" is still groups.
6. Click Save.

Map Google groups to subgroups

1. Navigate to the specific subgroup in GitLab
   • Example: acme-corp/engineering/backend
2. Go to Settings > SAML Group Links.
3. Click "Add new SAML Group Link".
4. Configure the mapping:
   • SAML Group Name: Backend-Team (exact Google Workspace group name)
   • Access Level: Developer (or your desired role)
5. Click Save. Repeat this process for all subgroups and their corresponding Google groups.

Multi-level access example

Here's how permissions might work across different levels:

Top-level group: acme-corp

SAML Group Links:

• "Company-Admins" → Owner
• "All-Employees" → Minimal Access

Subgroup: acme-corp/engineering

SAML Group Links:

• "Engineering-Leads" → Owner
• "Engineering-Team" → Maintainer

Nested subgroup: acme-corp/engineering/backend

SAML Group Links:

• "Backend-Leads" → Maintainer
• "Backend-Team" → Developer

How permissions inherit and combine

Understanding permission behavior is important:

• Role calculation: At each level, users receive the highest role from all their Google groups.
• Inheritance: Higher permissions at parent levels flow down to child subgroups.
• Independence: Each level calculates permissions based on its own group links plus inherited permissions.
• No limitation: Lower permissions at parent levels do NOT restrict higher permissions at child levels.

Example scenarios:

User A (member of Backend-Team only):

• acme-corp: Minimal Access (from "All-Employees" default)
• acme-corp/engineering: Minimal Access (inherited from parent)
• acme-corp/engineering/backend: Developer (from "Backend-Team" mapping)

User B (member of Engineering-Leads and Backend-Team):

• acme-corp: Minimal Access (from "All-Employees" default)
• acme-corp/engineering: Owner (from "Engineering-Leads" mapping)
• acme-corp/engineering/backend: Owner (inherited from parent, which is higher than Developer)

How the synchronization works

Understanding the mechanics of SAML group synchronization helps you manage the system effectively.

Synchronization timing

• When sync occurs: Group memberships update every time a user signs in via SAML.
• Frequency: Changes are not continuous — they only happen at login.
• Direction: Synchronization is one-way from Google Workspace to GitLab.
• First login: User account is created automatically and groups are assigned.
• Subsequent logins: Existing group memberships are updated to match current Google groups.

Role priority and combination

When a user belongs to multiple Google Workspace groups:

• GitLab evaluates all the user's groups at each level of the hierarchy.
• The user receives the highest role from any of their groups.
• This calculation happens independently at each level (top-level group, subgroups, etc.).

Example:

• User in "Developers" (Developer role) + "Tech-Leads" (Maintainer role) → Gets Maintainer

Automatic role changes

The system automatically handles membership changes:

• User added to a Google group: Role upgraded on next login.
• User removed from a Google group: Role recalculated based on remaining groups on next login.
• User removed from all mapped groups: Reverts to default membership role on next login.
• User added to additional groups: Gets highest role from all groups on next login.

Propagation timing

Be aware of these timing considerations:

• Google Workspace changes: Can take up to 24 hours to propagate, though usually take only a few minutes.
• GitLab sync: Happens immediately when the user logs in after Google changes are live.
• Testing: Have users log out and log back in to test permission changes.

Understanding user lifecycle and edge cases

What happens when you remove a user from GitLab?

Removing permissions only: If you remove a user from GitLab projects but leave their account active and they're still in the authorized Google groups:

• They keep their same account (same user ID and username)
• When they log in via SAML, their group memberships are automatically restored
• They regain permissions based on their current Google group memberships

Blocking the account:

• Account exists but is locked
• User cannot log in even if in Google groups
• Can be unblocked later, preserving all history

Deleting the account:

• Account is permanently removed
• If user logs in again (while still in Google groups), GitLab creates a completely new account
• New account has different user ID with no connection to the old one

Proper offboarding process

To permanently revoke access, follow this order:

1. Remove from Google Workspace groups - Prevents authentication
2. Block in GitLab - Prevents account recreation and preserves audit trails
3. Delete account (optional) - Only if you're certain they won't return

Critical: Removing a user only from GitLab without removing them from Google groups means they can simply log back in and regain access.

Google group membership propagation

According to Google's documentation, group membership changes can take up to 24 hours to propagate, though typically occur within minutes.

Account recreation scenarios

Troubleshooting common issues

Even with careful configuration, you might encounter issues. Here are solutions to the most common problems.

Users not being added to groups

Symptom: User successfully logs in via SAML but doesn't appear in any GitLab groups, or appears with only the default role.

Possible causes and solutions:

1. Group names don't match exactly
   • Check spelling and capitalization in both Google Workspace and GitLab
   • Look for extra spaces before or after group names
   • Verify the exact name in Google Admin Console > Directory > Groups
2. User not actually in the Google group
   • Verify membership: Google Admin Console > Directory > Groups > Group > Members
   • Remember that nested group membership might not be included
3. Groups not configured in SAML app
   • Verify the groups are selected in Google SAML attribute mapping
   • Confirm "App attribute" is set to groups (lowercase)
   • Use "Test SAML Login" to inspect the SAML response
4. Timing or cache issue
   • Wait 24 hours for Google changes to fully propagate
   • Have the user log out of GitLab and Google completely
   • Clear browser cache and try again
   • User must log in via the SAML SSO URL, not regular GitLab login

User has incorrect role

Symptom: User has access but with the wrong permission level.

Possible causes and solutions:

1. User belongs to multiple groups
   • Remember: Users get the highest role from all their groups
   • Check all Google groups the user belongs to
   • Review all SAML Group Link configurations at all levels
2. SAML Group Link misconfigured
   • Verify the Access Level setting in Settings > SAML Group Links
   • Check for duplicate group mappings that might conflict
3. User hasn't logged in since changes
   • Roles only update when users log in via SAML
   • Have the user log out completely and log back in via the SSO URL
4. Inherited permissions from parent groups
   • Check SAML Group Links in parent groups
   • Remember that higher roles at parent levels flow down to children

SAML authentication fails completely

Symptom: Users cannot log in at all, or receive error messages during authentication.

Possible causes and solutions:

1. Incorrect certificate fingerprint
   • Verify you used SHA-1 format, not SHA-256
   • Check the fingerprint has the correct format with colons
   • Regenerate using the online tool or OpenSSL command
2. Wrong SSO URL
   • Double-check the SSO URL copied from Google
   • Ensure there are no extra spaces or characters
3. ACS URL or Entity ID mismatch
   • Verify the ACS URL in Google Admin Console matches GitLab exactly
   • Confirm the Entity ID matches between both systems
4. User doesn't have app access
   • Check User Access settings in Google Admin Console
   • Verify the user's organizational unit has the app enabled
   • Confirm the app is "ON" for the appropriate users
5. Certificate expired
   • Check certificate validity dates
   • Download a fresh certificate if needed

Groups attribute missing from SAML response

Symptom: Users can log in but group synchronization doesn't work at all.

Possible causes and solutions:

1. Groups not selected in Google configuration
   • Return to Google Admin > Apps > GitLab > Attribute mapping
   • Verify groups are selected under "Group membership"
   • Confirm "App attribute" is exactly groups (lowercase)
2. User not in any configured groups
   • Only groups the user belongs to are sent in the SAML response
   • Add the user to at least one selected group to test
3. Configuration hasn't propagated
   • Wait up to 24 hours for changes to take effect
   • Try logging out of Google Admin Console and back in
4. Typo in app attribute name
   • The attribute name must be exactly groups (lowercase)
   • Even a capital letter or extra space will break functionality

Best practices for managing SAML group sync

Follow these recommendations to maintain a secure and efficient setup.

Security best practices

1. Maintain emergency access
   • Keep at least one Owner account that uses password authentication (not SAML)
   • This provides emergency access if SAML configuration breaks
   • Store these credentials securely
2. Use least privilege principle
   • Set default membership to Minimal Access
   • Only grant higher permissions through explicit group mappings
   • Regularly review and audit group memberships
3. Enable enforcement options
   • Turn on "Enforce SAML authentication" options
   • This prevents users from bypassing SSO
   • Exceptions should be rare and well-documented
4. Regular security audits
   • Quarterly review of Google Workspace group memberships
   • Annual review of SAML Group Link mappings
   • Monitor GitLab audit logs for unusual access patterns

Summary and next steps

Congratulations! You've successfully configured SAML SSO and automatic group synchronization between Google Workspace and GitLab. Your setup now provides:

• Seamless authentication - Users sign in with their familiar Google Workspace credentials.
• Automatic provisioning - User accounts are created on first login without manual intervention.
• Dynamic permissions - Group memberships and roles update automatically based on Google Workspace groups.
• Centralized access control - Manage all access through your existing Google Workspace groups.
• Enhanced security - Leverage Google's authentication infrastructure and enforce consistent policies.
• Reduced administrative overhead - Eliminate manual user and permission management in GitLab.

What happens now

When users access GitLab:

1. They navigate to your GitLab SSO URL.
2. Authenticate using their Google Workspace credentials.
3. Get automatically added to appropriate GitLab groups.
4. Receive permissions based on their Google group memberships.
5. Their permissions update every time they sign in.

Additional resources

• GitLab SAML SSO Documentation
• GitLab SAML Group Sync Documentation
• Google Workspace SAML App Setup
• SAML Certificate Fingerprint Tool

Related article

• How-to: GitLab Single Sign-on with SAML, SCIM, and Azure's Entra ID