Commit 8de1bc8a authored by Mike Jang's avatar Mike Jang
Browse files

Merge branch '298853-saml-docs' into 'master'

Deduplicate SAML docs information

See merge request gitlab-org/gitlab!56595
parents 960b6409 0d09c9fa
Pipeline #12970151 canceled with stages
......@@ -23,13 +23,11 @@ providers:
- [GitHub](../../integration/github.md)
- [GitLab.com](../../integration/gitlab.md)
- [Google OAuth](../../integration/google.md)
- [Google Workspace SSO](../../integration/google_workspace_saml.md)
- [JWT](jwt.md)
- [Kerberos](../../integration/kerberos.md)
- [LDAP](ldap/index.md): Includes Active Directory, Apple Open Directory, Open LDAP,
and 389 Server.
- [Google Secure LDAP](ldap/google_secure_ldap.md)
- [Okta](okta.md)
- [Salesforce](../../integration/salesforce.md)
- [SAML](../../integration/saml.md)
- [SAML for GitLab.com groups](../../user/group/saml_sso/index.md) **(PREMIUM SAAS)**
......
---
type: reference
stage: Manage
group: Access
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
redirect_to: '../../integration/saml.md'
---
 
# Okta SSO provider
This document was moved to [another location](../../integration/saml.md).
 
Okta is a [Single Sign-on provider](https://www.okta.com/products/single-sign-on/) that can be used to authenticate
with GitLab.
The following documentation enables Okta as a SAML provider.
## Configure the Okta application
The following guidance is based on this Okta article, on adding a [SAML Application with an Okta Developer account](https://support.okta.com/help/s/article/Why-can-t-I-add-a-SAML-Application-with-an-Okta-Developer-account?language=en_US):
1. In the Okta admin section, make sure to select Classic UI view in the top left corner. From there, choose to **Add an App**.
1. When the app screen comes up you see another button to **Create an App** and
choose SAML 2.0 on the next screen.
1. Optionally you can add a logo
(you can choose it from <https://about.gitlab.com/press/>). You'll have to
crop and resize it.
1. Next, you'll need the to fill in the SAML general configuration. Here's an example (showing the required URLs and attribute mapping):
image.
![Okta admin panel view](img/okta_admin_panel_v13_9.png)
1. The last part of the configuration is the feedback section where you can
just say you're a customer and creating an app for internal use.
1. When you have your app you'll have a few tabs on the top of the app's
profile. Click on the SAML 2.0 configuration instructions button which should
look like the following:
![Okta SAML settings](img/okta_saml_settings.png)
1. On the screen that comes up take note of the
**Identity Provider Single Sign-On URL** which you'll use for the
`idp_sso_target_url` on your GitLab configuration file.
1. **Before you leave Okta make sure you add your user and groups if any.**
---
Now that the Okta app is configured, it's time to enable it in GitLab.
## Configure GitLab
1. See [Initial OmniAuth Configuration](../../integration/omniauth.md#initial-omniauth-configuration)
for initial settings.
1. To allow your users to use Okta to sign up without having to manually create
an account first, don't forget to add the following values to your
configuration:
**For Omnibus GitLab installations**
Edit `/etc/gitlab/gitlab.rb`:
```ruby
gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
gitlab_rails['omniauth_block_auto_created_users'] = false
```
---
**For installations from source**
Edit `config/gitlab.yml`:
```yaml
allow_single_sign_on: ["saml"]
block_auto_created_users: false
```
1. You can also automatically link Okta users with existing GitLab users if
their email addresses match by adding the following setting:
**For Omnibus GitLab installations**
Edit `/etc/gitlab/gitlab.rb`:
```ruby
gitlab_rails['omniauth_auto_link_saml_user'] = true
```
---
**For installations from source**
Edit `config/gitlab.yml`:
```yaml
auto_link_saml_user: true
```
1. Add the provider configuration.
>**Notes:**
>
>- Change the value for `assertion_consumer_service_url` to match the HTTPS endpoint
> of GitLab (append `users/auth/saml/callback` to the HTTPS URL of your GitLab
> installation to generate the correct value).
>
>- To get the `idp_cert_fingerprint` fingerprint, first download the
> certificate from the Okta app you registered and then run:
> `openssl x509 -in okta.cert -noout -fingerprint`. Substitute `okta.cert`
> with the location of your certificate.
>
>- Change the value of `idp_sso_target_url`, with the value of the
> **Identity Provider Single Sign-On URL** from the step when you
> configured the Okta app.
>
>- Change the value of `issuer` to the value of the **Audience Restriction** from your Okta app configuration. This will identify GitLab
> to the IdP.
>
>- Leave `name_identifier_format` as-is.
**For Omnibus GitLab installations**
```ruby
gitlab_rails['omniauth_providers'] = [
{
name: 'saml',
args: {
assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
idp_sso_target_url: 'https://gitlab.oktapreview.com/app/gitlabdev773716_gitlabsaml_1/exk8odl81tBrjpD4B0h7/sso/saml',
issuer: 'https://gitlab.example.com',
name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'
},
label: 'Okta' # optional label for SAML login button, defaults to "Saml"
}
]
```
**For installations from source**
```yaml
- {
name: 'saml',
args: {
assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
idp_sso_target_url: 'https://gitlab.oktapreview.com/app/gitlabdev773716_gitlabsaml_1/exk8odl81tBrjpD4B0h7/sso/saml',
issuer: 'https://gitlab.example.com',
name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'
},
label: 'Okta' # optional label for SAML login button, defaults to "Saml"
}
```
1. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart](../restart_gitlab.md#installations-from-source) GitLab for Omnibus and installations
from source respectively for the changes to take effect.
You might want to try this out on an incognito browser window.
## Configuring groups
NOTE:
Make sure the groups exist and are assigned to the Okta app.
You can take a look of the [SAML documentation](../../integration/saml.md#saml-groups) on configuring groups.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
<!-- This redirect file can be deleted after 2021-06-15>. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
......@@ -20,6 +20,7 @@ They may then set up a test configuration of the desired identity provider. We i
This section includes relevant screenshots of the following example configurations of [Group SAML](../../user/group/saml_sso/index.md) and [Group SCIM](../../user/group/saml_sso/scim_setup.md):
 
- [Azure Active Directory](#azure-active-directory)
- [Okta](#okta)
- [OneLogin](#onelogin)
 
WARNING:
......@@ -59,6 +60,14 @@ IdP Links and Certificate:
 
![Okta Links and Certificate](img/Okta-linkscert.png)
 
Sign on settings:
![Okta SAML settings](img/okta_saml_settings.png)
Self-managed instance example:
![Okta admin panel view](img/okta_admin_panel_v13_9.png)
## OneLogin
 
Application details:
......
---
type: reference
stage: Manage
group: Access
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
redirect_to: 'saml.md'
---
 
# Google Workspace SSO provider
This document was moved to [another location](saml.md).
 
Google Workspace (formerly G Suite) is a [Single Sign-on provider](https://support.google.com/a/answer/60224?hl=en) that can be used to authenticate
with GitLab.
The following documentation enables Google Workspace as a SAML provider for GitLab.
## Configure the Google Workspace SAML app
The following guidance is based on this Google Workspace article, on how to [Set up your own custom SAML application](https://support.google.com/a/answer/6087519?hl=en):
Make sure you have access to a Google Workspace [Super Admin](https://support.google.com/a/answer/2405986#super_admin) account.
Follow the instructions in the linked Google Workspace article, where you'll need the following information:
| | Typical value | Description |
|------------------|--------------------------------------------------|----------------------------------------------------------|
| Name of SAML App | GitLab | Other names OK. |
| ACS URL | `https://<GITLAB_DOMAIN>/users/auth/saml/callback` | ACS is short for Assertion Consumer Service. |
| GITLAB_DOMAIN | `gitlab.example.com` | Set to the domain of your GitLab instance. |
| Entity ID | `https://gitlab.example.com` | A value unique to your SAML app, you'll set it to the `issuer` in your GitLab configuration. |
| Name ID format | EMAIL | Required value. Also known as `name_identifier_format` |
| Name ID | Primary email address | Make sure someone receives content sent to that address |
| First name | `first_name` | Required value to communicate with GitLab. |
| Last name | `last_name` | Required value to communicate with GitLab. |
You will also need to setup the following SAML attribute mappings:
| Google Directory attributes | App attributes |
|-----------------------------------|----------------|
| Basic information > Email | `email` |
| Basic Information > First name | `first_name` |
| Basic Information > Last name | `last_name` |
You may also use some of this information when you [Configure GitLab](#configure-gitlab).
When configuring the Google Workspace SAML app, be sure to record the following information:
| | Value | Description |
|-------------|--------------|-----------------------------------------------------------------------------------|
| SSO URL | Depends | Google Identity Provider details. Set to the GitLab `idp_sso_target_url` setting. |
| Certificate | Downloadable | Run `openssl x509 -in <your_certificate.crt> -noout -fingerprint` to generate the SHA1 fingerprint that can be used in the `idp_cert_fingerprint` setting. |
While the Google Workspace Admin provides IDP metadata, Entity ID and SHA-256 fingerprint,
GitLab does not need that information to connect to the Google Workspace SAML app.
---
Now that the Google Workspace SAML app is configured, it's time to enable it in GitLab.
## Configure GitLab
1. See [Initial OmniAuth Configuration](../integration/omniauth.md#initial-omniauth-configuration)
for initial settings.
1. To allow people to register for GitLab, through their Google accounts, add the following
values to your configuration:
**For Omnibus GitLab installations**
Edit `/etc/gitlab/gitlab.rb`:
```ruby
gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
gitlab_rails['omniauth_block_auto_created_users'] = false
```
---
**For installations from source**
Edit `config/gitlab.yml`:
```yaml
allow_single_sign_on: ["saml"]
block_auto_created_users: false
```
1. If an existing GitLab user has the same email address as a Google Workspace user, the registration
process automatically links their accounts, if you add the following setting:
their email addresses match by adding the following setting:
**For Omnibus GitLab installations**
Edit `/etc/gitlab/gitlab.rb`:
```ruby
gitlab_rails['omniauth_auto_link_saml_user'] = true
```
---
**For installations from source**
Edit `config/gitlab.yml`:
```yaml
auto_link_saml_user: true
```
1. Add the provider configuration.
For guidance on how to set up these values, see the [SAML General Setup steps](saml.md#general-setup).
Pay particular attention to the values for:
- `assertion_consumer_service_url`
- `idp_cert_fingerprint`
- `idp_sso_target_url`
- `issuer`
- `name_identifier_format`
**For Omnibus GitLab installations**
```ruby
gitlab_rails['omniauth_providers'] = [
{
name: 'saml',
args: {
assertion_consumer_service_url: 'https://<GITLAB_DOMAIN>/users/auth/saml/callback',
idp_cert_fingerprint: '00:00:00:00:00:00:0:00:00:00:00:00:00:00:00:00',
idp_sso_target_url: 'https://accounts.google.com/o/saml2/idp?idpid=00000000',
issuer: 'https://<GITLAB_DOMAIN>',
name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress'
},
label: 'Google Workspace' # optional label for SAML log in button, defaults to "Saml"
}
]
```
**For installations from source**
```yaml
- {
name: 'saml',
args: {
assertion_consumer_service_url: 'https://<GITLAB_DOMAIN>/users/auth/saml/callback',
idp_cert_fingerprint: '00:00:00:00:00:00:0:00:00:00:00:00:00:00:00:00',
idp_sso_target_url: 'https://accounts.google.com/o/saml2/idp?idpid=00000000',
issuer: 'https://<GITLAB_DOMAIN>',
name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress'
},
label: 'Google Workspace' # optional label for SAML log in button, defaults to "Saml"
}
```
1. [Reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart](../administration/restart_gitlab.md#installations-from-source) GitLab for Omnibus and installations
from source respectively for the changes to take effect.
To avoid caching issues, test the result on an incognito or private browser window.
## Troubleshooting
The Google Workspace documentation on [SAML app error messages](https://support.google.com/a/answer/6301076?hl=en) is helpful for debugging if you are seeing an error from Google while signing in.
Pay particular attention to the following 403 errors:
- `app_not_configured`
- `app_not_configured_for_user`
<!-- This redirect file can be deleted after 2021-06-15>. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
......@@ -11,14 +11,14 @@ This page describes instance-wide SAML for self-managed GitLab instances. For SA
 
You should also reference the [OmniAuth documentation](omniauth.md) for general settings that apply to all OmniAuth providers.
 
## Common SAML Terms
## Glossary of common terms
 
| Term | Description |
|--------------------------------|-------------|
| Identity Provider (IdP) | The service which manages your user identities, such as ADFS, Okta, OneLogin, or Ping Identity. |
| Service Provider (SP) | SAML considers GitLab to be a service provider. |
| Identity provider (IdP) | The service which manages your user identities, such as Okta or OneLogin. |
| Service provider (SP) | GitLab can be configured as a SAML 2.0 SP. |
| Assertion | A piece of information about a user's identity, such as their name or role. Also known as claims or attributes. |
| SSO | Single Sign-On. |
| Single Sign-On (SSO) | Name of authentication scheme. |
| Assertion consumer service URL | The callback on GitLab where users will be redirected after successfully authenticating with the identity provider. |
| Issuer | How GitLab identifies itself to the identity provider. Also known as a "Relying party trust identifier". |
| Certificate fingerprint | Used to confirm that communications over SAML are secure by checking that the server is signing communications with the correct certificate. Also known as a certificate thumbprint. |
......@@ -26,8 +26,8 @@ You should also reference the [OmniAuth documentation](omniauth.md) for general
## General Setup
 
GitLab can be configured to act as a SAML 2.0 Service Provider (SP). This allows
GitLab to consume assertions from a SAML 2.0 Identity Provider (IdP) such as
Microsoft ADFS to authenticate users.
GitLab to consume assertions from a SAML 2.0 Identity Provider (IdP), such as
Okta to authenticate users.
 
First configure SAML 2.0 support in GitLab, then register the GitLab application
in your SAML IdP:
......@@ -52,7 +52,7 @@ in your SAML IdP:
```
 
1. To allow your users to use SAML to sign up without having to manually create
an account first, don't forget to add the following values to your configuration:
an account first, add the following values to your configuration:
 
For Omnibus package:
 
......@@ -85,7 +85,8 @@ in your SAML IdP:
auto_link_saml_user: true
```
 
1. Ensure that the SAML [`NameID`](../user/group/saml_sso/index.md#nameid) and email address are fixed for each user, as described in the section on [Security](#security). Otherwise, your users will be able to sign in as other authorized users.
1. Ensure that the SAML [`NameID`](../user/group/saml_sso/index.md#nameid) and email address are fixed for each user,
as described in the section on [Security](#security). Otherwise, your users will be able to sign in as other authorized users.
 
1. Add the provider configuration:
 
......@@ -102,7 +103,7 @@ in your SAML IdP:
issuer: 'https://gitlab.example.com',
name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent'
},
label: 'Company Login' # optional label for SAML login button, defaults to "Saml"
label: 'Provider name' # optional label for SAML login button, defaults to "Saml"
}
]
```
......@@ -134,6 +135,7 @@ in your SAML IdP:
be a SHA1 fingerprint; check
[the OmniAuth SAML documentation](https://github.com/omniauth/omniauth-saml)
for more details on these options.
See the [notes on configuring your identity provider](#notes-on-configuring-your-identity-provider) for more information.
 
1. Change the value of `issuer` to a unique name, which will identify the application
to the IdP.
......@@ -151,16 +153,57 @@ configuration information to the IdP. To build the metadata URL for GitLab, appe
https://gitlab.example.com/users/auth/saml/metadata
```
 
At a minimum the IdP *must* provide a claim containing the user's email address, using
claim name `email` or `mail`. The email will be used to automatically generate the GitLab
username. GitLab will also use claims with name `name`, `first_name`, `last_name`
(see [the OmniAuth SAML gem](https://github.com/omniauth/omniauth-saml/blob/master/lib/omniauth/strategies/saml.rb)
for supported claims).
At a minimum the IdP *must* provide a claim containing the user's email address using `email` or `mail`.
See [the assertions list](#assertions) for other available claims.
 
On the sign in page there should now be a SAML button below the regular sign in form.
Click the icon to begin the authentication process. If everything goes well the user
will be returned to GitLab and will be signed in.
 
### Notes on configuring your identity provider
When configuring a SAML app on the IdP, you need at least:
- Assertion consumer service URL
- Issuer
- [`NameID`](../user/group/saml_sso/index.md#nameid)
- [Email address claim](#assertions)
Your identity provider may require additional configuration, such as the following:
| Field | Value | Notes |
|-------|-------|-------|
| SAML profile | Web browser SSO profile | GitLab uses SAML to sign users in through their browser. No requests are made directly to the identity provider. |
| SAML request binding | HTTP Redirect | GitLab (the service provider) redirects users to your identity provider with a base64 encoded `SAMLRequest` HTTP parameter. |
| SAML response binding | HTTP POST | Specifies how the SAML token is sent by your identity provider. Includes the `SAMLResponse`, which a user's browser submits back to GitLab. |
| Sign SAML response | Required | Prevents tampering. |
| X.509 certificate in response | Required | Signs the response and checks against the provided fingerprint. |
| Fingerprint algorithm | SHA-1 | GitLab uses a SHA-1 hash of the certificate to sign the SAML Response. |
| Signature algorithm | SHA-1/SHA-256/SHA-384/SHA-512 | Determines how a response is signed. Also known as the digest method, this can be specified in the SAML response. |
| Encrypt SAML assertion | Optional | Uses TLS between your identity provider, the user's browser, and GitLab. |
| Sign SAML assertion | Optional | Validates the integrity of a SAML assertion. When active, signs the whole response. |
| Check SAML request signature | Optional | Checks the signature on the SAML response. |
| Default RelayState | Optional | Specifies the URL users should end up on after successfully signing in through SAML at your identity provider. |
| NameID format | Persistent | See [NameID format details](../user/group/saml_sso/index.md#nameid-format). |
| Additional URLs | Optional | May include the issuer (or identifier) or the assertion consumer service URL in other fields on some providers. |
For example configurations, see the [notes on specific providers](#providers).
### Assertions
| Field | Supported keys |
|-----------------|----------------|
| Email (required)| `email`, `mail` |
| Username | `username`, `nickname` |
| Full Name | `name` |
| First Name | `first_name`, `firstname`, `firstName` |
| Last Name | `last_name`, `lastname`, `lastName` |
If a username is not specified, the email address is used to generate the GitLab username.
Please refer to [the OmniAuth SAML gem](https://github.com/omniauth/omniauth-saml/blob/master/lib/omniauth/strategies/saml.rb)
for a full list of supported assertions.
## SAML Groups
 
You can require users to be members of a certain group, or assign users [external](../user/permissions.md#external-users), admin or [auditor](../user/permissions.md#auditor-users) roles based on group membership.
......@@ -649,6 +692,81 @@ Group SAML on a self-managed instance is limited when compared to the recommende
- { name: 'group_saml' }
```
 
## Providers
GitLab support of SAML means that you can sign in to GitLab with a wide range of identity providers.
Your identity provider may have additional documentation. Some identity providers include
documentation on how to use SAML to sign in to GitLab.
Examples:
- [ADFS (Active Directory Federation Services)](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/create-a-relying-party-trust)
- [Auth0](https://auth0.com/docs/protocols/saml-protocol/configure-auth0-as-saml-identity-provider)
- [PingOne by Ping Identity](https://docs.pingidentity.com/bundle/pingone/page/xsh1564020480660-1.html)
Please note that GitLab provides the following setup notes for guidance only.
If you have any questions on configuring the SAML app, please contact your provider's support.
### Okta setup notes
The following guidance is based on this Okta article, on adding a [SAML Application with an Okta Developer account](https://support.okta.com/help/s/article/Why-can-t-I-add-a-SAML-Application-with-an-Okta-Developer-account?language=en_US):
1. In the Okta admin section, make sure to select Classic UI view in the top left corner. From there, choose to **Add an App**.
1. When the app screen comes up you see another button to **Create an App** and
choose SAML 2.0 on the next screen.
1. Optionally, you can add a logo
(you can choose it from <https://about.gitlab.com/press/>). You'll have to
crop and resize it.
1. Next, you'll need the to fill in the SAML general configuration with
the assertion consumer service URL as "Single sign-on URL" and
the issuer as "Audience URI" along with the [NameID](../user/group/saml_sso/index.md#nameid) and [assertions](#assertions).
1. The last part of the configuration is the feedback section where you can
just say you're a customer and creating an app for internal use.
1. When you have your app you'll have a few tabs on the top of the app's
profile. Click on the SAML 2.0 configuration instructions button.
1. On the screen that comes up take note of the
**Identity Provider Single Sign-On URL** which you'll use for the
`idp_sso_target_url` on your GitLab configuration file.
1. **Before you leave Okta, make sure you add your user and groups if any.**
### Google workspace setup notes
The following guidance is based on this Google Workspace article, on how to [Set up your own custom SAML application](https://support.google.com/a/answer/6087519?hl=en):
Make sure you have access to a Google Workspace [Super Admin](https://support.google.com/a/answer/2405986#super_admin) account.
Follow the instructions in the linked Google Workspace article, where you'll need the following information:
| | Typical value | Description |
|------------------|--------------------------------------------------|----------------------------------------------------------|
| Name of SAML App | GitLab | Other names OK. |
| ACS URL | `https://<GITLAB_DOMAIN>/users/auth/saml/callback` | ACS is short for Assertion Consumer Service. |
| GITLAB_DOMAIN | `gitlab.example.com` | Set to the domain of your GitLab instance. |
| Entity ID | `https://gitlab.example.com` | A value unique to your SAML app, you'll set it to the `issuer` in your GitLab configuration. |
| Name ID format | EMAIL | Required value. Also known as `name_identifier_format` |
| Name ID | Primary email address | Make sure someone receives content sent to that address |
| First name | `first_name` | Required value to communicate with GitLab. |
| Last name | `last_name` | Required value to communicate with GitLab. |
You also need to setup the following SAML attribute mappings:
| Google Directory attributes | App attributes |
|-----------------------------------|----------------|
| Basic information > Email | `email` |
| Basic Information > First name | `first_name` |
| Basic Information > Last name | `last_name` |
You may also use some of this information when you [configure GitLab](#general-setup).
When configuring the Google Workspace SAML app, be sure to record the following information:
| | Value | Description |
|-------------|--------------|-----------------------------------------------------------------------------------|
| SSO URL | Depends | Google Identity Provider details. Set to the GitLab `idp_sso_target_url` setting. |
| Certificate | Downloadable | Run `openssl x509 -in <your_certificate.crt> -noout -fingerprint` to generate the SHA1 fingerprint that can be used in the `idp_cert_fingerprint` setting. |
While the Google Workspace Admin provides IdP metadata, Entity ID and SHA-256 fingerprint,
GitLab does not need that information to connect to the Google Workspace SAML app.
## Troubleshooting
 
### SAML Response
......@@ -735,3 +853,11 @@ The following are the most likely reasons that a user is blocked when signing in
 
- In the configuration, `gitlab_rails['omniauth_block_auto_created_users'] = true` is set and this is the user's first time signing in.
- There are [`required_groups`](#required-groups) configured, but the user is not a member of one.
### Google workspace troubleshooting tips
The Google Workspace documentation on [SAML app error messages](https://support.google.com/a/answer/6301076?hl=en) is helpful for debugging if you are seeing an error from Google while signing in.
Pay particular attention to the following 403 errors:
- `app_not_configured`
- `app_not_configured_for_user`
......@@ -35,7 +35,6 @@ This page gathers all the resources for the topic **Authentication** within GitL
- [SAML OmniAuth Provider](../../integration/saml.md)
- [SAML for GitLab.com Groups](../../user/group/saml_sso/index.md) **(PREMIUM SAAS)**
- [SCIM user provisioning for GitLab.com Groups](../../user/group/saml_sso/scim_setup.md) **(PREMIUM SAAS)**
- [Okta SSO provider](../../administration/auth/okta.md)
- [Kerberos integration (GitLab EE)](../../integration/kerberos.md) **(STARTER)**
 
## API
......
......@@ -13,21 +13,24 @@ This page describes SAML for Groups. For instance-wide SAML on self-managed GitL
 
SAML on GitLab.com allows users to sign in through their SAML identity provider. If the user is not already a member, the sign-in process automatically adds the user to the appropriate group.
 
If you follow our guidance to automate user provisioning using [SCIM](scim_setup.md) or [group-managed accounts](group_managed_accounts.md), you do not need to create such accounts manually.
User synchronization of SAML SSO groups is supported through [SCIM](scim_setup.md). SCIM supports adding and removing users from the GitLab group.
User synchronization of SAML SSO groups is supported through [SCIM](scim_setup.md). SCIM supports adding and removing users from the GitLab group automatically.
For example, if you remove a user from the SCIM app, SCIM removes that same user from the GitLab group.
 
SAML SSO is only configurable at the top-level group.