diff options
Diffstat (limited to 'doc/integration')
| -rw-r--r-- | doc/integration/advanced_search/elasticsearch.md | 97 | ||||
| -rw-r--r-- | doc/integration/advanced_search/elasticsearch_troubleshooting.md | 33 | ||||
| -rw-r--r-- | doc/integration/arkose.md | 4 | ||||
| -rw-r--r-- | doc/integration/datadog.md | 4 | ||||
| -rw-r--r-- | doc/integration/glab/img/glabgettingstarted.gif | bin | 0 -> 141528 bytes | |||
| -rw-r--r-- | doc/integration/glab/index.md | 80 | ||||
| -rw-r--r-- | doc/integration/index.md | 2 | ||||
| -rw-r--r-- | doc/integration/jenkins.md | 2 | ||||
| -rw-r--r-- | doc/integration/jira/connect-app.md | 49 | ||||
| -rw-r--r-- | doc/integration/jira/dvcs.md | 3 | ||||
| -rw-r--r-- | doc/integration/kerberos.md | 32 | ||||
| -rw-r--r-- | doc/integration/mattermost/index.md | 4 | ||||
| -rw-r--r-- | doc/integration/oauth2_generic.md | 203 | ||||
| -rw-r--r-- | doc/integration/omniauth.md | 35 | ||||
| -rw-r--r-- | doc/integration/saml.md | 739 |
15 files changed, 836 insertions, 451 deletions
diff --git a/doc/integration/advanced_search/elasticsearch.md b/doc/integration/advanced_search/elasticsearch.md index 94493aa6958..a55a56b30d6 100644 --- a/doc/integration/advanced_search/elasticsearch.md +++ b/doc/integration/advanced_search/elasticsearch.md @@ -46,13 +46,7 @@ If you are using a compatible version and after connecting to OpenSearch, you ge Elasticsearch requires additional resources to those documented in the [GitLab system requirements](../../install/requirements.md). -Memory, CPU, and storage resource amounts vary depending on the amount of data you index into the Elasticsearch cluster. Heavily used Elasticsearch clusters may require more resources. According to -[Elasticsearch official guidelines](https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html#_memory), -each node should have: - -- [Memory](https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html#_memory): 8 GiB (minimum). -- [CPU](https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html#_cpus): Modern processor with multiple cores. GitLab has minimal CPU requirements for Elasticsearch. Multiple cores provide extra concurrency, which is more beneficial than faster CPUs. -- [Storage](https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html#_disks): Use SSD storage. The total storage size of all Elasticsearch nodes is about 50% of the total size of your Git repositories. It includes one primary and one replica. The [`estimate_cluster_size`](#gitlab-advanced-search-rake-tasks) Rake task ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/221177) in GitLab 13.10) uses total repository size to estimate the Advanced Search storage requirements. +Memory, CPU, and storage resource amounts vary depending on the amount of data you index into the Elasticsearch cluster. Heavily used Elasticsearch clusters may require more resources. The [`estimate_cluster_size`](#gitlab-advanced-search-rake-tasks) Rake task ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/221177) in GitLab 13.10) uses the total repository size to estimate the Advanced Search storage requirements. ## Install Elasticsearch @@ -239,6 +233,85 @@ Sidekiq performance. Return them to their default values if you see increased `s in your Sidekiq logs. For more information, see [issue 322147](https://gitlab.com/gitlab-org/gitlab/-/issues/322147). +### Access requirements for self-managed AWS OpenSearch Service using fine-grained access control + +To use the self-managed AWS OpenSearch Service with GitLab using fine-grained access control, try one of the +[recommended configurations](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html#fgac-recommendations). + +Configure your instance's domain access policies to allow `es:ESHttp*` actions. You can customize +the following example configuration to limit principals or resources. +See [Identity and Access Management in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ac.html) for details. + +```json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "AWS": [ + "*" + ] + }, + "Action": [ + "es:ESHttp*" + ], + "Resource": "domain-arn/*" + } + ] +} +``` + +#### Connecting with a master user in the internal database + +When using fine-grained access control with a user in the internal database, you should use HTTP basic +authentication to connect to OpenSearch. You can provide the master username and password as part of the +OpenSearch URL or in the **Username** and **Password** text boxes in the Advanced Search settings. See +[Tutorial: Internal user database and HTTP basic authentication](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac-walkthrough-basic.html) for details. + +#### Connecting with an IAM user + +When using fine-grained access control with IAM credentials, you can provide the credentials in the **AWS OpenSearch IAM credentials** section in the Advanced Search settings. + +#### Permissions for fine-grained access control + +The following permissions are required for Advanced Search. See [Creating roles](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html#fgac-roles) for details. + +```json +{ + "cluster_permissions": [ + "cluster_composite_ops", + "cluster_monitor" + ], + "index_permissions": [ + { + "index_patterns": [ + "gitlab*" + ], + "allowed_actions": [ + "data_access", + "manage_aliases", + "search", + "create_index", + "delete", + "manage" + ] + }, + { + "index_patterns": [ + "*" + ], + "allowed_actions": [ + "indices:admin/aliases/get", + "indices:monitor/stats" + ] + } + ] +} +``` + +The index pattern `*` requires a few permissions for Advanced Search to work. + ### Limit the number of namespaces and projects that can be indexed If you check checkbox `Limit the number of namespaces and projects that can be indexed` @@ -486,7 +559,7 @@ The following are some available Rake tasks: | Task | Description | |:--------------------------------------------------------------------------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| [`sudo gitlab-rake gitlab:elastic:info`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Outputs debugging information for the Advanced Search intergation. | +| [`sudo gitlab-rake gitlab:elastic:info`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Outputs debugging information for the Advanced Search integration. | | [`sudo gitlab-rake gitlab:elastic:index`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Enables Elasticsearch indexing and run `gitlab:elastic:create_empty_index`, `gitlab:elastic:clear_index_status`, `gitlab:elastic:index_projects`, and `gitlab:elastic:index_snippets`. | | [`sudo gitlab-rake gitlab:elastic:pause_indexing`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Pauses Elasticsearch indexing. Changes are still tracked. Useful for cluster/index migrations. | | [`sudo gitlab-rake gitlab:elastic:resume_indexing`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Resumes Elasticsearch indexing. | @@ -783,8 +856,8 @@ additional process dedicated to indexing a set of queues (or queue group). This ensure that indexing queues always have a dedicated worker, while the rest of the queues have another dedicated worker to avoid contention. -For this purpose, use the [queue selector](../../administration/sidekiq/extra_sidekiq_processes.md#queue-selector) -option that allows a more general selection of queue groups using a [worker matching query](../../administration/sidekiq/extra_sidekiq_routing.md#worker-matching-query). +For this purpose, use the [queue selectors](../../administration/sidekiq/processing_specific_job_classes.md#queue-selectors) +option that allows a more general selection of queue groups using a [worker matching query](../../administration/sidekiq/processing_specific_job_classes.md#worker-matching-query). To handle these two queue groups, we generally recommend one of the following two options. You can either: @@ -804,8 +877,8 @@ To create both an indexing and a non-indexing Sidekiq process in one node: ```ruby sidekiq['enable'] = true - sidekiq['queue_selector'] = true - sidekiq['queue_groups'] = [ + sidekiq['queue_selector'] = true + sidekiq['queue_groups'] = [ "feature_category=global_search", "feature_category!=global_search" ] diff --git a/doc/integration/advanced_search/elasticsearch_troubleshooting.md b/doc/integration/advanced_search/elasticsearch_troubleshooting.md index aa6613d6f1a..7e2edf10c90 100644 --- a/doc/integration/advanced_search/elasticsearch_troubleshooting.md +++ b/doc/integration/advanced_search/elasticsearch_troubleshooting.md @@ -96,7 +96,7 @@ Here are some common pitfalls and how to overcome them. a Lucene index. - **Replicas**: Failover mechanisms that duplicate indices. -## How can I verify that my GitLab instance is using Elasticsearch? +## How can you verify that your GitLab instance is using Elasticsearch? There are a couple of ways to achieve that: @@ -184,13 +184,13 @@ If reindexing the project shows: - Elasticsearch errors or doesn't present any errors at all, reach out to your Elasticsearch administrator to check the instance. -### I updated GitLab and now I can't find anything +### You updated GitLab and now you can't find anything We continuously make updates to our indexing strategies and aim to support newer versions of Elasticsearch. When indexing changes are made, it may be necessary for you to [reindex](elasticsearch.md#zero-downtime-reindexing) after updating GitLab. -### I indexed all the repositories but I can't get any hits for my search term in the UI +### You indexed all the repositories but you can't get any hits for your search term in the UI Make sure you [indexed all the database data](elasticsearch.md#enable-advanced-search). @@ -220,7 +220,7 @@ The above instructions are not to be used for scenarios that only index a [subse See [Elasticsearch Index Scopes](elasticsearch.md#advanced-search-index-scopes) for more information on searching for specific types of data. -### I indexed all the repositories but then switched Elasticsearch servers and now I can't find anything +### You indexed all the repositories but then switched Elasticsearch servers and now you can't find anything You must re-run all the Rake tasks to reindex the database, repositories, and wikis. @@ -228,11 +228,11 @@ You must re-run all the Rake tasks to reindex the database, repositories, and wi The more data present in your GitLab instance, the longer the indexing process takes. -### There are some projects that weren't indexed, but I don't know which ones +### There are some projects that weren't indexed, but you don't know which ones You can run `sudo gitlab-rake gitlab:elastic:projects_not_indexed` to display projects that aren't indexed. -### No new data is added to the Elasticsearch index when I push code +### No new data is added to the Elasticsearch index when you push code NOTE: This was [fixed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35936) in GitLab 13.2 and the Rake task is not available for versions greater than that. @@ -248,7 +248,7 @@ sudo gitlab-rake gitlab:elastic:clear_locked_projects If `ElasticCommitIndexerWorker` Sidekiq workers are failing with this error during indexing, it usually means that Elasticsearch is unable to keep up with the concurrency of indexing request. To address change the following settings: - To decrease the indexing throughput you can decrease `Bulk request concurrency` (see [Advanced Search settings](elasticsearch.md#advanced-search-configuration)). This is set to `10` by default, but you change it to as low as 1 to reduce the number of concurrent indexing operations. -- If changing `Bulk request concurrency` didn't help, you can use the [queue selector](../../administration/sidekiq/extra_sidekiq_processes.md#queue-selector) option to [limit indexing jobs only to specific Sidekiq nodes](elasticsearch.md#index-large-instances-with-dedicated-sidekiq-nodes-or-processes), which should reduce the number of indexing requests. +- If changing `Bulk request concurrency` didn't help, you can use the [queue selector](../../administration/sidekiq/processing_specific_job_classes.md#queue-selectors) option to [limit indexing jobs only to specific Sidekiq nodes](elasticsearch.md#index-large-instances-with-dedicated-sidekiq-nodes-or-processes), which should reduce the number of indexing requests. ### Indexing is very slow or fails with `rejected execution of coordinating operation` messages @@ -447,24 +447,9 @@ however, searches only surface results that can be viewed by the user. Advanced Search honors all permission checks in the application by filtering out projects that a user does not have access to at search time. -## Access requirements for the self-managed AWS OpenSearch Service +### Role mapping when using fine-grained access control with AWS Elasticsearch or OpenSearch -To use the self-managed AWS OpenSearch Service with GitLab, configure your instance's domain access policies -to contain the actions below. -See [Identity and Access Management in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ac.html) for details. - -```plaintext -es:ESHttpDelete -es:ESHttpGet -es:ESHttpHead -es:ESHttpPost -es:ESHttpPut -es:ESHttpPatch -``` - -## Role-mapping when using AWS Elasticsearch or AWS OpenSearch fine-grained access control - -When using fine-grained access control with an IAM role, you might encounter the following error: +When using fine-grained access control with an IAM role or a role created using OpenSearch Dashboards, you might encounter the following error: ```plaintext {"error":{"root_cause":[{"type":"security_exception","reason":"no permissions for [indices:data/write/bulk] and User [name=arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE, backend_roles=[arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE], requestedTenant=null]"}],"type":"security_exception","reason":"no permissions for [indices:data/write/bulk] and User [name=arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE, backend_roles=[arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE], requestedTenant=null]"},"status":403} diff --git a/doc/integration/arkose.md b/doc/integration/arkose.md index aa27e3ba4a4..09a7defcff8 100644 --- a/doc/integration/arkose.md +++ b/doc/integration/arkose.md @@ -35,8 +35,8 @@ improve their risk prediction model. NOTE: Enabling the `arkose_labs_prevent_login` feature flag results in sessions with a `High` risk -score being denied access. So far, we have kept this feature flag disabled to evaluate Arkose -Protect's predictions and to make sure we are not preventing legitimate users from signing in. +score being denied access. So far, we have kept this feature flag disabled to evaluate Arkose Protect +predictions and to make sure we are not preventing legitimate users from signing in. That said, we have seen that interactive challenges are effective in preventing some malicious sign-in attempts as not completing them prevents attackers from moving on to the next sign-in step. diff --git a/doc/integration/datadog.md b/doc/integration/datadog.md index 31e254658c1..1f20bccf083 100644 --- a/doc/integration/datadog.md +++ b/doc/integration/datadog.md @@ -38,9 +38,11 @@ project, group, or instance level: Used only in advanced scenarios. 1. Optional. If you use more than one GitLab instance, provide a unique **Service** name to differentiate between your GitLab instances. +<!-- vale gitlab.Spelling = NO --> 1. Optional. If you use groups of GitLab instances (such as staging and production environments), provide an **Env** name. This value is attached to each span the integration generates. +<!-- vale gitlab.Spelling = YES --> 1. Optional. To define any custom tags for all spans at which the integration is being configured, enter one tag per line in **Tags**. Each line must be in the format `key:value`. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79665) in GitLab 14.8.) 1. Optional. Select **Test settings** to test your integration. @@ -51,4 +53,4 @@ section of your Datadog account. ## Related topics -- [Datadog's CI Visibility](https://docs.datadoghq.com/continuous_integration/) documentation. +- [Datadog CI Visibility](https://docs.datadoghq.com/continuous_integration/) documentation. diff --git a/doc/integration/glab/img/glabgettingstarted.gif b/doc/integration/glab/img/glabgettingstarted.gif Binary files differnew file mode 100644 index 00000000000..cf335294e41 --- /dev/null +++ b/doc/integration/glab/img/glabgettingstarted.gif diff --git a/doc/integration/glab/index.md b/doc/integration/glab/index.md new file mode 100644 index 00000000000..3951f38dfab --- /dev/null +++ b/doc/integration/glab/index.md @@ -0,0 +1,80 @@ +--- +stage: Create +group: Code Review +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments +--- + +# GitLab CLI - `glab` + +GLab is an open source GitLab CLI tool. It brings GitLab to your terminal: +next to where you are already working with Git and your code, without +switching between windows and browser tabs. + +- Work with issues. +- Work with merge requests. +- Watch running pipelines directly from your CLI. + + + +The GitLab CLI uses commands structured like `glab <command> <subcommand> [flags]` +to perform many of the actions you normally do from the GitLab user interface: + +```shell +# Sign in +glab auth login --stdin < token.txt + +# View a list of issues +glab issue list + +# Create merge request for issue 123 +glab mr for 123 + +# Check out the branch for merge request 243 +glab mr checkout 243 + +# Watch the pipeline in progress +glab pipeline ci view + +# View, approve, and merge the merge request +glab mr view +glab mr approve +glab mr merge +``` + +## Core commands + +- `glab alias` +- `glab api` +- `glab auth` +- `glab ci` +- `glab issue` +- `glab label` +- `glab mr` +- `glab project` +- `glab release` +- `glab snippet` +- `glab ssh-key` +- `glab user` +- `glab variable` + +## Install the CLI + +Installation instructions are available in the GLab +[`README`](https://gitlab.com/gitlab-org/cli/#installation). + +## Authenticate with GitLab + +To authenticate with your GitLab account, run `glab auth login`. +`glab` respects tokens set using `GITLAB_TOKEN`. + +## Report issues + +Open an issue in the [`gitlab-org/cli` repository](https://gitlab.com/gitlab-org/cli/issues/new) +to send us feedback. + +## Related topics + +- [Install the CLI](https://gitlab.com/gitlab-org/cli/-/blob/main/README.md#installation) +- [Documentation](https://gitlab.com/gitlab-org/cli/-/tree/main/docs/source) +- The extension source code is available in the + [`cli`](https://gitlab.com/gitlab-org/cli/) project. diff --git a/doc/integration/index.md b/doc/integration/index.md index b2a4201e88c..bdf6475b6d2 100644 --- a/doc/integration/index.md +++ b/doc/integration/index.md @@ -11,7 +11,7 @@ You can integrate GitLab with external services for enhanced functionality. ## Services -Services such as Campfire, Flowdock, Jira, Pivotal Tracker, and Slack +Services such as Campfire, Jira, Pivotal Tracker, and Slack are available as [integrations](../user/project/integrations/index.md). ## Issue trackers diff --git a/doc/integration/jenkins.md b/doc/integration/jenkins.md index 8a438dde52e..53a2fb8bbdd 100644 --- a/doc/integration/jenkins.md +++ b/doc/integration/jenkins.md @@ -179,7 +179,7 @@ If you get this error message while configuring GitLab, the following are possib - The Jenkins instance is at a local address and is not included in the [GitLab installation's allowlist](../security/webhooks.md#create-an-allowlist-for-local-requests). - The credentials for the Jenkins instance do not have sufficient access or are invalid. -- The **Enable authentication for `/project` end-point** checkbox is not selected in your [Jenkin's plugin configuration](#configure-the-jenkins-server). +- The **Enable authentication for `/project` end-point** checkbox is not selected in your [Jenkins plugin configuration](#configure-the-jenkins-server). ### Error in merge requests - "Could not connect to the CI server" diff --git a/doc/integration/jira/connect-app.md b/doc/integration/jira/connect-app.md index 171c1cbe484..513877a7b71 100644 --- a/doc/integration/jira/connect-app.md +++ b/doc/integration/jira/connect-app.md @@ -72,6 +72,55 @@ for details. If the app requires additional permissions, [the update must first be manually approved in Jira](https://developer.atlassian.com/platform/marketplace/upgrading-and-versioning-cloud-apps/#changes-that-require-manual-customer-approval). +## Connect the GitLab.com for Jira Cloud app for self-managed instances **(FREE SELF)** + +> - Introduced in GitLab 15.6 [with flags](../../administration/feature_flags.md) named [`jira_connect_oauth_self_managed_setting`](https://gitlab.com/gitlab-org/gitlab/-/issues/377679), [`jira_connect_oauth`](https://gitlab.com/gitlab-org/gitlab/-/issues/355048), and [`jira_connect_oauth_self_managed`](https://gitlab.com/gitlab-org/gitlab/-/issues/359940). Disabled by default. +> - Feature flag `jira_connect_oauth_self_managed_setting` [removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/105070) in GitLab 15.7. + +FLAG: +On self-managed GitLab, by default this feature is not available. To make it available, +ask an administrator to [enable the feature flags](../../administration/feature_flags.md) named +`jira_connect_oauth` and `jira_connect_oauth_self_managed`. On GitLab.com, this feature +is not available. The feature is not ready for production use. + +Prerequisites: + +- GitLab.com must serve as a proxy for the instance. +- The instance must be publicly available. +- The instance must be on version 15.7 or later. + +You can link self-managed instances after installing the GitLab.com for Jira Cloud app from the marketplace. +Jira apps can only link to one URL per marketplace listing. The official listing links to GitLab.com. + +### Set up your instance + +To set up your self-managed instance for the GitLab.com for Jira Cloud app in GitLab 15.7 or later: + +1. On the top bar, select **Main menu > Admin**. +1. On the left sidebar, select **Applications** (`/admin/applications`). +1. Select **New application**. +1. In **Redirect URI**, enter `https://gitlab.com/-/jira_connect/oauth_callbacks`. +1. Ensure the **Trusted** and **Confidential** checkboxes are cleared. +<!-- markdownlint-disable MD044 --> +1. In **Scopes**, select the **api** checkbox only. +<!-- markdownlint-enable MD044 --> +1. Select **Save application**. +1. Copy the **Application ID** value. +1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`). +1. Expand the **GitLab for Jira App** section. +1. Paste the **Application ID** value into **Jira Connect Application ID**. +1. In **Jira Connect Proxy URL**, enter `https://gitlab.com`. +1. Select **Save changes**. + +### Link your instance + +To link your self-managed instance to the GitLab.com for Jira Cloud app: + +1. Install the [GitLab.com for Jira Cloud app](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud?tab=overview&hosting=cloud). +1. Select **GitLab (self-managed)**. +1. Enter your GitLab instance URL. +1. Select **Save**. + ## Install the GitLab.com for Jira Cloud app for self-managed instances **(FREE SELF)** If your GitLab instance is self-managed, you must follow some diff --git a/doc/integration/jira/dvcs.md b/doc/integration/jira/dvcs.md index f33536b7b91..982c8203904 100644 --- a/doc/integration/jira/dvcs.md +++ b/doc/integration/jira/dvcs.md @@ -19,6 +19,9 @@ are accessible. - **Jira Server**: Your network must allow access to your instance. - **Jira Cloud**: Your instance must be accessible through the internet. +NOTE: +When using GitLab 15.0 and later (including GitLab.com) with Jira Server, you might experience a [session token bug in Jira](https://jira.atlassian.com/browse/JSWSERVER-21389). As a workaround, ensure Jira Server is version 9.1.0 and later or 8.20.11 and later. + ## Smart Commits When connecting GitLab with Jira with DVCS, you can process your Jira issues using diff --git a/doc/integration/kerberos.md b/doc/integration/kerberos.md index c7cbc4389f5..a0441b79490 100644 --- a/doc/integration/kerberos.md +++ b/doc/integration/kerberos.md @@ -357,6 +357,38 @@ to a larger value in [the NGINX configuration](https://nginx.org/en/docs/http/ng ## Troubleshooting +### Test connectivity between the GitLab and Kerberos servers + +You can use utilities like [`kinit`](https://web.mit.edu/kerberos/krb5-1.12/doc/user/user_commands/kinit.html) and [`klist`](https://web.mit.edu/kerberos/krb5-1.12/doc/user/user_commands/klist.html) to test connectivity between the GitLab server +and the Kerberos server. How you install these depends on your specific OS. + +Use `klist` to see the service principal names (SPN) available in your `keytab` file and the encryption type for each SPN: + +```shell +klist -ke /etc/http.keytab +``` + +On an Ubuntu server, the output would look similar to the following: + +```shell +Keytab name: FILE:/etc/http.keytab +KVNO Principal +---- -------------------------------------------------------------------------- + 3 HTTP/my.gitlab.domain@MY.REALM (des-cbc-crc) + 3 HTTP/my.gitlab.domain@MY.REALM (des-cbc-md5) + 3 HTTP/my.gitlab.domain@MY.REALM (arcfour-hmac) + 3 HTTP/my.gitlab.domain@MY.REALM (aes256-cts-hmac-sha1-96) + 3 HTTP/my.gitlab.domain@MY.REALM (aes128-cts-hmac-sha1-96) +``` + +Use `kinit` in verbose mode to test whether GitLab can use the keytab file to connect to the Kerberos server: + +```shell +KRB5_TRACE=/dev/stdout kinit -kt /etc/http.keytab HTTP/my.gitlab.domain@MY.REALM +``` + +This command shows a detailed output of the authentication process. + ### Unsupported GSSAPI mechanism With Kerberos SPNEGO authentication, the browser is expected to send a list of diff --git a/doc/integration/mattermost/index.md b/doc/integration/mattermost/index.md index 04b0157b737..df6130a7540 100644 --- a/doc/integration/mattermost/index.md +++ b/doc/integration/mattermost/index.md @@ -123,7 +123,7 @@ http://mattermost.example.com/signup/gitlab/complete http://mattermost.example.com/login/gitlab/complete ``` -Note that you do not need to select any options under **Scopes**. Choose **Save application**. +Make sure to select the **Trusted** and **Confidential** settings. Under **Scopes**, select `read_user`. Then, choose **Save application**. Once the application is created you are provided with an `Application ID` and `Secret`. One other piece of information needed is the URL of GitLab instance. Return to the server running GitLab Mattermost and edit the `/etc/gitlab/gitlab.rb` configuration file as follows using the values you received above: @@ -132,7 +132,7 @@ Return to the server running GitLab Mattermost and edit the `/etc/gitlab/gitlab. mattermost['gitlab_enable'] = true mattermost['gitlab_id'] = "12345656" mattermost['gitlab_secret'] = "123456789" -mattermost['gitlab_scope'] = "" +mattermost['gitlab_scope'] = "read_user" mattermost['gitlab_auth_endpoint'] = "http://gitlab.example.com/oauth/authorize" mattermost['gitlab_token_endpoint'] = "http://gitlab.example.com/oauth/token" mattermost['gitlab_user_api_endpoint'] = "http://gitlab.example.com/api/v4/user" diff --git a/doc/integration/oauth2_generic.md b/doc/integration/oauth2_generic.md index a337873a67e..c51400113d4 100644 --- a/doc/integration/oauth2_generic.md +++ b/doc/integration/oauth2_generic.md @@ -6,8 +6,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Generic OAuth 2.0 provider **(FREE SELF)** -The `omniauth-oauth2-generic` gem allows single sign-on (SSO) between GitLab -and your OAuth 2.0 provider, or any OAuth 2.0 provider compatible with this gem). +The [`omniauth-oauth2-generic` gem](https://gitlab.com/satorix/omniauth-oauth2-generic) allows single sign-on (SSO) between GitLab +and your OAuth 2.0 provider, or any OAuth 2.0 provider compatible with this gem. This strategy allows for the configuration of this OmniAuth SSO process: @@ -48,62 +48,149 @@ To configure the provider: appear is different for each provider. This may also be called application ID and application secret. -1. On your GitLab server, open the appropriate configuration file. - - For Omnibus GitLab: - - ```shell - sudo editor /etc/gitlab/gitlab.rb - ``` - - For installations from source: - - ```shell - cd /home/git/gitlab - sudo -u git -H editor config/gitlab.yml - ``` - -1. See [Configure initial settings](omniauth.md#configure-initial-settings) for - initial settings. - -1. Add the provider-specific configuration for your provider. For example: - - ```ruby - gitlab_rails['omniauth_providers'] = [ - { - name: "oauth2_generic", - label: "Provider name", # optional label for login button, defaults to "Oauth2 Generic" - app_id: "<your_app_client_id>", - app_secret: "<your_app_client_secret>", - args: { - client_options: { - site: "<your_auth_server_url>", - user_info_url: "/oauth2/v1/userinfo", - authorize_url: "/oauth2/v1/authorize", - token_url: "/oauth2/v1/token" - }, - user_response_structure: { - root_path: [], - id_path: ["sub"], - attributes: { - email: "email", - name: "name" - } - }, - authorize_params: { - scope: "openid profile email" - }, - strategy_class: "OmniAuth::Strategies::OAuth2Generic" - } - } - ] - ``` - - For more information about these settings, see the [gem's README](https://gitlab.com/satorix/omniauth-oauth2-generic#gitlab-config-example). - -1. Save the configuration file. - -1. For the changes to take effect, [restart GitLab](../administration/restart_gitlab.md#installations-from-source). +1. On your GitLab server, complete the following steps. + + ::Tabs + + :::TabTitle Linux package (Omnibus) + + 1. [Configure the initial settings](omniauth.md#configure-initial-settings). + 1. Edit `/etc/gitlab/gitlab.rb` to add the configuration for your provider. For example: + + ```ruby + gitlab_rails['omniauth_providers'] = [ + { + name: "oauth2_generic", + label: "Provider name", # optional label for login button, defaults to "Oauth2 Generic" + app_id: "<your_app_client_id>", + app_secret: "<your_app_client_secret>", + args: { + client_options: { + site: "<your_auth_server_url>", + user_info_url: "/oauth2/v1/userinfo", + authorize_url: "/oauth2/v1/authorize", + token_url: "/oauth2/v1/token" + }, + user_response_structure: { + root_path: [], + id_path: ["sub"], + attributes: { + email: "email", + name: "name" + } + }, + authorize_params: { + scope: "openid profile email" + }, + strategy_class: "OmniAuth::Strategies::OAuth2Generic" + } + } + ] + ``` + + 1. Save the file and reconfigure GitLab: + + ```shell + sudo gitlab-ctl reconfigure + ``` + + :::TabTitle Helm chart (Kubernetes) + + 1. [Configure the initial settings](omniauth.md#configure-initial-settings). + 1. Export the Helm values: + + ```shell + helm get values gitlab > gitlab_values.yaml + ``` + + 1. Edit `gitlab_values.yaml`. + + NOTE: + The following example exposes the `app_secret` value in the main YAML file. + You're strongly advised to use + [Helm secrets](https://docs.gitlab.com/charts/installation/secrets.html) + instead. + + ```yaml + global: + appConfig: + omniauth: + enabled: true + providers: + - name: "oauth2_generic" + label: "Provider name" # optional label for login button defaults to "Oauth2 Generic" + app_id: "<your_app_client_id>" + app_secret: "<your_app_client_secret>" + args: + client_options: + site: "<your_auth_server_url>" + user_info_url: "/oauth2/v1/userinfo" + authorize_url: "/oauth2/v1/authorize" + token_url: "/oauth2/v1/token" + user_response_structure: + root_path: [] + id_path: ["sub"] + attributes: + email: "email" + name: "name" + authorize_params: + scope: "openid profile email" + strategy_class: "OmniAuth::Strategies::OAuth2Generic" + ``` + + 1. Save the file and apply the new values: + + ```shell + helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab + ``` + + :::TabTitle Self-compiled (source) + + 1. [Configure the initial settings](omniauth.md#configure-initial-settings). + 1. Edit `/home/git/gitlab/config/gitlab.yml`: + + ```yaml + production: &base + omniauth: + providers: + - { name: "oauth2_generic", + label: "Provider name", # optional label for login button, defaults to "Oauth2 Generic" + app_id: "<your_app_client_id>", + app_secret: "<your_app_client_secret>", + args: { + client_options: { + site: "<your_auth_server_url>", + user_info_url: "/oauth2/v1/userinfo", + authorize_url: "/oauth2/v1/authorize", + token_url: "/oauth2/v1/token" + }, + user_response_structure: { + root_path: [], + id_path: ["sub"], + attributes: { + email: "email", + name: "name" + } + }, + authorize_params: { + scope: "openid profile email" + }, + strategy_class: "OmniAuth::Strategies::OAuth2Generic" + } + } + ``` + + 1. Save the file and restart GitLab: + + ```shell + # For systems running systemd + sudo systemctl restart gitlab.target + + # For systems running SysV init + sudo service gitlab restart + ``` + + ::EndTabs On the sign-in page there should now be a new icon below the regular sign-in form. Select that icon to begin your provider's authentication process. This diff --git a/doc/integration/omniauth.md b/doc/integration/omniauth.md index af039c8a009..2dd8505b558 100644 --- a/doc/integration/omniauth.md +++ b/doc/integration/omniauth.md @@ -38,7 +38,7 @@ GitLab supports the following OmniAuth providers. | [SAML](saml.md) | `saml` | | [Twitter](twitter.md) | `twitter` | -## Configure initial settings +## Initial settings Before you configure the OmniAuth provider, configure the settings that are common for all providers. @@ -49,13 +49,15 @@ Omnibus, Docker, and source | Helm chart | Description | Default value `auto_link_ldap_user` | `autoLinkLdapUser` | Creates an LDAP identity in GitLab for users that are created through an OmniAuth provider. You can enable this setting if you have [LDAP integration](../administration/auth/ldap/index.md) enabled. Requires the `uid` of the user to be the same in both LDAP and the OmniAuth provider. | `false` `block_auto_created_users` | `blockAutoCreatedUsers` | Blocks users that are automatically created from signing in until they are approved by an administrator. | `true`. If you set the value to `false`, make sure you define providers that you can control, like SAML or Google. Otherwise, any user on the internet can sign in to GitLab without an administrator's approval. -To change these settings: +### Configure initial settings + +To change the OmniAuth settings: ::Tabs - :::TabTitle Omnibus + :::TabTitle Linux package (Omnibus) - 1. Edit `/etc/gitlab/gitlab.rb` and update the following section: + 1. Edit `/etc/gitlab/gitlab.rb`: ```ruby # CAUTION! @@ -67,13 +69,13 @@ To change these settings: gitlab_rails['omniauth_block_auto_created_users'] = true ``` - 1. Reconfigure GitLab: + 1. Save the file and reconfigure GitLab: ```shell sudo gitlab-ctl reconfigure ``` - :::TabTitle Helm chart + :::TabTitle Helm chart (Kubernetes) 1. Export the Helm values: @@ -96,22 +98,15 @@ To change these settings: For more details, see the [globals documentation](https://docs.gitlab.com/charts/charts/globals.html#omniauth). - 1. Apply the new values: + 1. Save the file and apply the new values: ```shell helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab ``` - :::TabTitle Source - - 1. Open the configuration file: - - ```shell - cd /home/git/gitlab - sudo -u git -H editor config/gitlab.yml - ``` + :::TabTitle Self-compiled (source) - 1. Update the following section: + 1. Edit `/home/git/gitlab/config/gitlab.yml`: ```yaml ## OmniAuth settings @@ -132,9 +127,13 @@ To change these settings: block_auto_created_users: true ``` - 1. Restart GitLab: + 1. Save the file and restart GitLab: ```shell + # For systems running systemd + sudo systemctl restart gitlab.target + + # For systems running SysV init sudo service gitlab restart ``` @@ -283,7 +282,7 @@ for the OpenID Connect provider and the Twitter OAuth provider. This method of enabling automatic linking works for all providers [except SAML](https://gitlab.com/gitlab-org/gitlab/-/issues/338293). -To enable automatic linking for SAML, see the [SAML setup instructions](saml.md#general-setup). +To enable automatic linking for SAML, see the [SAML setup instructions](saml.md#configure-saml-support-in-gitlab). ## Create an external providers list diff --git a/doc/integration/saml.md b/doc/integration/saml.md index fd01e9e0e56..84879b7c4c7 100644 --- a/doc/integration/saml.md +++ b/doc/integration/saml.md @@ -5,41 +5,29 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: reference --- -# SAML OmniAuth Provider **(FREE SELF)** +# SAML SSO for self-managed GitLab instances **(FREE SELF)** -This page describes instance-wide SAML for self-managed GitLab instances. For -SAML on GitLab.com, see [SAML SSO for GitLab.com groups](../user/group/saml_sso/index.md). +This page describes how to set up instance-wide SAML single sign on (SSO) for +self-managed GitLab instances. -You should also reference the [OmniAuth documentation](omniauth.md) for general -settings that apply to all OmniAuth providers. +You can configure GitLab to act as a SAML service provider (SP). This allows +GitLab to consume assertions from a SAML identity provider (IdP), such as +Okta, to authenticate users. -## Glossary of common terms - -| Term | Description | -|--------------------------------|-------------| -| 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. | -| Single Sign-On (SSO) | Name of authentication scheme. | -| Assertion consumer service URL | The callback on GitLab where users are 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. | +To set up SAML on GitLab.com, see [SAML SSO for GitLab.com groups](../user/group/saml_sso/index.md). -## General Setup +For more information on: -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 -Okta to authenticate users. +- OmniAuth provider settings, see the [OmniAuth documentation](omniauth.md). +- Commonly-used terms, see the [glossary of common terms](#glossary-of-common-terms). -First configure SAML 2.0 support in GitLab, then register the GitLab application -in your SAML IdP: +## Configure SAML support in GitLab -1. Make sure GitLab is configured with HTTPS. - See [Using HTTPS](../install/installation.md#using-https) for instructions. +1. Make sure GitLab is [configured with HTTPS](../install/installation.md#using-https). 1. On your GitLab server, open the configuration file. - For Omnibus package: + For Omnibus installations: ```shell sudo editor /etc/gitlab/gitlab.rb @@ -53,11 +41,12 @@ in your SAML IdP: sudo -u git -H editor config/gitlab.yml ``` -1. See [Configure initial settings](omniauth.md#configure-initial-settings) for initial settings. +1. Edit the initial [configuration settings](omniauth.md#configure-initial-settings). + 1. To allow your users to use SAML to sign up without having to manually create - an account first, add the following values to your configuration: + an account first, add the following values to your configuration. - For Omnibus package: + For Omnibus installations: ```ruby gitlab_rails['omniauth_allow_single_sign_on'] = ['saml'] @@ -73,10 +62,10 @@ in your SAML IdP: block_auto_created_users: false ``` -1. You can also automatically link SAML users with existing GitLab users if their - email addresses match by adding the following setting: +1. Optional. You can automatically link SAML users with existing GitLab users if their + email addresses match by adding the following setting. - For Omnibus package: + For Omnibus installations: ```ruby gitlab_rails['omniauth_auto_link_saml_user'] = true @@ -88,12 +77,21 @@ 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 are able to sign in as other authorized users. + Alternatively, a user can manually link their SAML identity to an existing GitLab + account by [enabling OmniAuth for an existing user](omniauth.md#enable-omniauth-for-an-existing-user). -1. Add the provider configuration: +1. Configure the following attributes so your SAML users cannot change them: - For Omnibus package: + - [`NameID`](../user/group/saml_sso/index.md#nameid). + - `Email` when used with `omniauth_auto_link_saml_user`. + + If users can change these attributes, they can sign in as other authorized users. + See your SAML IdP documentation for information on how to make these attributes + unchangeable. + +1. Add the provider configuration. + + For Omnibus installations: ```ruby gitlab_rails['omniauth_providers'] = [ @@ -129,63 +127,118 @@ as described in the section on [Security](#security). Otherwise, your users are } ``` -1. 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). +1. Match the value for `assertion_consumer_service_url` to the HTTPS endpoint + of GitLab. To generate the correct value, append `users/auth/saml/callback` to the + HTTPS URL of your GitLab installation. -1. Change the values of `idp_cert_fingerprint`, `idp_sso_target_url`, - `name_identifier_format` to match your IdP. If a fingerprint is used it must - 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 following values to match your IdP: + - `idp_cert_fingerprint`. + - `idp_sso_target_url`. + - `name_identifier_format`. + If you use a `idp_cert_fingerprint`, it must be a SHA1 fingerprint. For more + information on these values, see the + [OmniAuth SAML documentation](https://github.com/omniauth/omniauth-saml). + For more information on other configuration settings, see + [configuring SAML on your IdP](#configure-saml-on-your-idp). 1. Change the value of `issuer` to a unique name, which identifies the application to the IdP. -1. For the changes to take effect: - - If you installed via Omnibus, [reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure). - - If you installed from source, [restart GitLab](../administration/restart_gitlab.md#installations-from-source). +1. For the changes to take effect, if you installed: + - Using Omnibus, [reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure). + - From source, [restart GitLab](../administration/restart_gitlab.md#installations-from-source). -1. Register the GitLab SP in your SAML 2.0 IdP, using the application name specified - in `issuer`. +### Register GitLab in your SAML IdP -To ease configuration, most IdP accept a metadata URL for the application to provide -configuration information to the IdP. To build the metadata URL for GitLab, append -`users/auth/saml/metadata` to the HTTPS URL of your GitLab installation, for instance: +1. Register the GitLab SP in your SAML IdP, using the application name specified in `issuer`. -```plaintext -https://gitlab.example.com/users/auth/saml/metadata -``` +1. To provide configuration information to the IdP, build a metadata URL for the + application. To build the metadata URL for GitLab, append `users/auth/saml/metadata` + to the HTTPS URL of your GitLab installation. For example: -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. + ```plaintext + https://gitlab.example.com/users/auth/saml/metadata + ``` + + At a minimum the IdP **must** provide a claim containing the user's email address + using `email` or `mail`. For more information on other available claims, see + [configuring assertions](#configure-assertions). + +1. On the sign in page there should now be a SAML icon below the regular sign in form. + Select the icon to begin the authentication process. If authentication is successful, + you are returned to GitLab and signed in. + +### Configure SAML on your IdP -On the sign in page there should now be a SAML button below the regular sign in form. -Select the icon to begin the authentication process. If everything goes well the user -is returned to GitLab and signed in. +To configure a SAML application on your IdP, you need at least the following information: -### Use multiple SAML identity providers +- Assertion consumer service URL. +- Issuer. +- [`NameID`](../user/group/saml_sso/index.md#nameid). +- [Email address claim](#configure-assertions). + +For an example configuration, see [set up identity providers](#set-up-identity-providers). + +Your IdP may need additional configuration. For more information, see +[additional configuration for SAML apps on your IdP](#additional-configuration-for-saml-apps-on-your-idp). + +### Configure GitLab to use multiple SAML IdPs > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14361) in GitLab 14.6. -You can configure GitLab to use multiple SAML identity providers if: +You can configure GitLab to use multiple SAML IdPs if: -- Each provider has a unique name set that matches a name set in `args`. At least one provider **must** have the name `saml` to mitigate a - [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/366450) in GitLab 14.6 and newer. -- The providers' names are: - - Used in OmniAuth configuration for properties based on the provider name. For example, `allowBypassTwoFactor`, `allowSingleSignOn`, and - `syncProfileFromProvider`. - - Used for association to each existing user as an additional identity. +- Each provider has a unique name set that matches a name set in `args`. At least + one provider must have the name `saml` to mitigate a + [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/366450) in GitLab + 14.6 and newer. +- The providers' names are used: + - In OmniAuth configuration for properties based on the provider name. For example, + `allowBypassTwoFactor`, `allowSingleSignOn`, and `syncProfileFromProvider`. + - For association to each existing user as an additional identity. - The `assertion_consumer_service_url` matches the provider name. -- The `strategy_class` is explicitly set because it cannot be inferred from provider name. +- The `strategy_class` is explicitly set because it cannot be inferred from provider + name. -Example multiple providers configuration for Omnibus GitLab: +Example provider's configuration for installations from source: + +```yaml +omniauth: + providers: + - { + name: 'saml', # This must match the following name configuration parameter + args: { + name: 'saml', # This is mandatory and must match the provider name + strategy_class: 'OmniAuth::Strategies::SAML', + assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml_1/callback', # URL must match the name of the provider + ... # Put here all the required arguments similar to a single provider + }, + label: 'Provider 1' # Differentiate the two buttons and providers in the UI + } + - { + name: 'saml1', # This must match the following name configuration parameter + args: { + name: 'saml1', # This is mandatory and must match the provider name + strategy_class: 'OmniAuth::Strategies::SAML', + assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml_2/callback', # URL must match the name of the provider + ... # Put here all the required arguments similar to a single provider + }, + label: 'Provider 2' # Differentiate the two buttons and providers in the UI + } +``` + +Example provider's configuration for Omnibus GitLab installations: + +To allow your users to use SAML to sign up without having to manually create an account from either of the providers, add the following values to your configuration. + +```ruby +gitlab_rails['omniauth_allow_single_sign_on'] = ['saml', 'saml1'] +``` ```ruby gitlab_rails['omniauth_providers'] = [ { - name: 'saml', + name: 'saml', # This must match the following name configuration parameter args: { name: 'saml', # This is mandatory and must match the provider name strategy_class: 'OmniAuth::Strategies::SAML', @@ -195,7 +248,7 @@ gitlab_rails['omniauth_providers'] = [ label: 'Provider 1' # Differentiate the two buttons and providers in the UI }, { - name: 'saml1', + name: 'saml1', # This must match the following name configuration parameter args: { name: 'saml1', # This is mandatory and must match the provider name strategy_class: 'OmniAuth::Strategies::SAML', @@ -207,87 +260,126 @@ gitlab_rails['omniauth_providers'] = [ ] ``` -Example providers configuration for installations from source: +To allow your users to use SAML to sign up without having to manually create an +account from either of the providers, add the following values to your configuration. -```yaml -omniauth: - providers: - - { - name: 'saml', - args: { - name: 'saml', # This is mandatory and must match the provider name - strategy_class: 'OmniAuth::Strategies::SAML', - assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml_1/callback', # URL must match the name of the provider - ... # Put here all the required arguments similar to a single provider - }, - label: 'Provider 1' # Differentiate the two buttons and providers in the UI - } - - { - name: 'saml1', - args: { - name: 'saml1', # This is mandatory and must match the provider name - strategy_class: 'OmniAuth::Strategies::SAML', - assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml_2/callback', # URL must match the name of the provider - ... # Put here all the required arguments similar to a single provider - }, - label: 'Provider 2' # Differentiate the two buttons and providers in the UI - } +```ruby +gitlab_rails['omniauth_allow_single_sign_on'] = ['saml', 'saml1'] ``` -### Notes on configuring your identity provider +## Set up identity providers -When configuring a SAML app on the IdP, you need at least: +GitLab support of SAML means you can sign in to GitLab through a wide range +of IdPs. -- Assertion consumer service URL -- Issuer -- [`NameID`](../user/group/saml_sso/index.md#nameid) -- [Email address claim](#assertions) +GitLab provides the following content on setting up the Okta and Google Workspace +IdPs for guidance only. If you have any questions on configuring either of these +IdPs, contact your provider's support. -Your identity provider may require additional configuration, such as the following: +### Set up Okta -| 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. | +1. In the Okta administrator section choose **Applications**. +1. On the app screen, select **Create App Integration** and then select + **SAML 2.0** on the next screen. +1. Optional. Choose and add a logo from [GitLab Press](https://about.gitlab.com/press/). + You must crop and resize the logo. +1. Complete the SAML general configuration. Enter: + - `"Single sign-on URL"`: Use the assertion consumer service URL. + - `"Audience URI"`: Use the issuer. + - [`NameID`](../user/group/saml_sso/index.md#nameid). + - [Assertions](#configure-assertions). +1. In the feedback section, enter that you're a customer and creating an + app for internal use. +1. At the top of your new app's profile, select **SAML 2.0 configuration instructions**. +1. Note the **Identity Provider Single Sign-On URL**. Use this URL for the + `idp_sso_target_url` on your GitLab configuration file. +1. Before you sign out of Okta, make sure you add your user and groups if any. + +### Set up Google Workspace + +Prerequisites: -For example configurations, see the [notes on specific providers](#providers). +- Make sure you have access to a +[Google Workspace Super Admin account](https://support.google.com/a/answer/2405986#super_admin). -### Assertions +1. Use the following information, and follow the instructions in +[Set up your own custom SAML application in Google Workspace](https://support.google.com/a/answer/6087519?hl=en). -| Field | Supported keys | -|-----------------|----------------| -| Email (required)| `email`, `mail` | -| Full Name | `name` | + | | Typical value | Description | + |------------------|--------------------------------------------------|----------------------------------------------------------| + | Name of SAML App | GitLab | Other names OK. | + | ACS URL | `https://<GITLAB_DOMAIN>/users/auth/saml/callback` | Assertion Consumer Service URL. | + | GITLAB_DOMAIN | `gitlab.example.com` | Your GitLab instance domain. | + | Entity ID | `https://gitlab.example.com` | A value unique to your SAML application. 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 | Your email address. Make sure someone receives content sent to that address. | + | First name | `first_name` | First name. Required value to communicate with GitLab. | + | Last name | `last_name` | Last name. Required value to communicate with GitLab. | + +1. Set up 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 might use some of this information when you + [configure SAML support in GitLab](#configure-saml-support-in-gitlab). + +When configuring the Google Workspace SAML application, 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. | + +Google Workspace Administrator also provides the IdP metadata, Entity ID, and SHA-256 +fingerprint. However, GitLab does not need this information to connect to the +Google Workspace SAML application. + +### Set up other IdPs + +Some IdPs have documentation on how to use them as the IdP in SAML configurations. +For example: + +- [Active Directory Federation Services (ADFS)](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/create-a-relying-party-trust) +- [Auth0](https://auth0.com/docs/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider) + +If you have any questions on configuring your IdP in a SAML configuration, contact +your provider's support. + +### Configure assertions + +| Field | Supported default keys | +|-----------------|------------------------| +| Email (required)| `email`, `mail` | +| Full Name | `name` | | First Name | `first_name`, `firstname`, `firstName` | -| Last Name | `last_name`, `lastname`, `lastName` | +| Last Name | `last_name`, `lastname`, `lastName` | + +See [`attribute_statements`](#map-saml-response-attribute-names) for: -See [`attribute_statements`](#attribute_statements) for examples on how custom -assertions are configured. This section also describes how to configure custom -username attributes. +- Custom assertion configuration examples. +- How to configure custom username attributes. -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. +For a full list of supported assertions, see the [OmniAuth SAML gem](https://github.com/omniauth/omniauth-saml/blob/master/lib/omniauth/strategies/saml.rb) -## SAML Groups +## Configure users based on SAML group membership -You can require users to be members of a certain group, or assign users [external](../user/permissions.md#external-users), administrator or [auditor](../user/permissions.md#auditor-users) roles based on group membership. -These groups are checked on each SAML login and user attributes updated as necessary. -This feature **does not** allow you to -automatically add users to GitLab [Groups](../user/group/index.md). +You can: -Support for these groups depends on your [subscription](https://about.gitlab.com/pricing/) -and whether you've installed [GitLab Enterprise Edition (EE)](https://about.gitlab.com/install/). +- Require users to be members of a certain group. +- Assign users [external](../user/admin_area/external_users.md), administrator or [auditor](../administration/auditor_users.md) roles based on group membership. + +GitLab checks these groups on each SAML sign in and updates user attributes as necessary. +This feature **does not** allow you to automatically add users to GitLab +[Groups](../user/group/index.md). + +Support for these groups depends on: + +- Your [subscription](https://about.gitlab.com/pricing/). +- Whether you've installed [GitLab Enterprise Edition (EE)](https://about.gitlab.com/install/). | Group | Tier | GitLab Enterprise Edition (EE) Only? | |------------------------------|--------------------|--------------------------------------| @@ -296,11 +388,11 @@ and whether you've installed [GitLab Enterprise Edition (EE)](https://about.gitl | [Admin](#administrator-groups) | **(FREE SELF)** | Yes | | [Auditor](#auditor-groups) | **(PREMIUM SELF)** | Yes | -### Requirements +### Prerequisites -First tell GitLab where to look for group information. For this, you -must make sure that your IdP server sends a specific `AttributeStatement` along -with the regular SAML response. Here is an example: +You must tell GitLab where to look for group information. To do this, make sure +that your IdP server sends a specific `AttributeStatement` along with the regular +SAML response. For example: ```xml <saml:AttributeStatement> @@ -313,22 +405,25 @@ with the regular SAML response. Here is an example: </saml:AttributeStatement> ``` -The name of the attribute can be anything you like, but it must contain the groups -to which a user belongs. To tell GitLab where to find these groups, you need -to add a `groups_attribute:` element to your SAML settings. +The name of the attribute must contain the groups that a user belongs to. +To tell GitLab where to find these groups, add a `groups_attribute:` +element to your SAML settings. ### Required groups -Your IdP passes Group information to the SP (GitLab) in the SAML Response. -To use this response, configure GitLab to identify: +Your IdP passes group information to GitLab in the SAML response. To use this +response, configure GitLab to identify: + +- Where to look for the groups in the SAML response, using the `groups_attribute` setting. +- Information about a group or user, using a group setting. -- Where to look for the groups in the SAML response via the `groups_attribute` setting -- Which group membership is requisite to sign in via the `required_groups` setting +Use the `required_groups` setting to configure GitLab to identify which group +membership is required to sign in. -When `required_groups` is empty or not set, anyone with proper authentication -is able to use the service. +If you do not set `required_groups` or leave the setting empty, anyone with proper +authentication can use the service. -Example: +Example configuration: ```yaml { name: 'saml', @@ -346,9 +441,17 @@ Example: ### External groups -SAML login supports the automatic identification of a user as an -[external user](../user/permissions.md#external-users). This is based on the user's group -membership in the SAML identity provider. +Your IdP passes group information to GitLab in the SAML response. To use this +response, configure GitLab to identify: + +- Where to look for the groups in the SAML response, using the `groups_attribute` setting. +- Information about a group or user, using a group setting. + +SAML can automatically identify a user as an +[external user](../user/admin_area/external_users.md), based on the `external_groups` +setting. + +Example configuration: ```yaml { name: 'saml', @@ -366,11 +469,16 @@ membership in the SAML identity provider. ### Administrator groups -The requirements are the same as the previous settings: +Your IdP passes group information to GitLab in the SAML response. To use this +response, configure GitLab to identify: + +- Where to look for the groups in the SAML response, using the `groups_attribute` setting. +- Information about a group or user, using a group setting. -- The IdP must pass Group information to GitLab. -- GitLab must know where to look for the groups in the SAML response, as well as - which groups grant the user administrator access. +Use the `admin_groups` setting to configure GitLab to identify which groups grant +the user administrator access. + +Example configuration: ```yaml { name: 'saml', @@ -390,11 +498,16 @@ The requirements are the same as the previous settings: > Introduced in GitLab 11.4. -The requirements are the same as the previous settings: +Your IdP passes group information to GitLab in the SAML response. To use this +response, configure GitLab to identify: + +- Where to look for the groups in the SAML response, using the `groups_attribute` setting. +- Information about a group or user, using a group setting. + +Use the `auditor_groups` setting to configure GitLab to identify which groups include +users with [auditor access](../administration/auditor_users.md). -- The IdP must pass Group information to GitLab. -- GitLab should know where to look for the groups in the SAML response, as well as which - groups include users with the [Auditor role](../user/permissions.md#auditor-users). +Example configuration: ```yaml { name: 'saml', @@ -410,17 +523,17 @@ The requirements are the same as the previous settings: } } ``` -## Group Sync +## Automatically manage SAML Group Sync For information on automatically managing GitLab group membership, see [SAML Group Sync](../user/group/saml_sso/group_sync.md). -## Bypass two factor authentication +## Bypass two-factor authentication -If you want some SAML authentication methods to count as 2FA on a per session -basis, you can register them in the `upstream_two_factor_authn_contexts` list. +To configure a SAML authentication method to count as two-factor authentication +(2FA) on a per session basis, register that method in the `upstream_two_factor_authn_contexts` +list. -In addition to the changes in GitLab, make sure that your IdP is returning the -`AuthnContext`. For example: +1. Make sure that your IdP is returning the `AuthnContext`. For example: ```xml <saml:AuthnStatement> @@ -430,7 +543,11 @@ In addition to the changes in GitLab, make sure that your IdP is returning the </saml:AuthnStatement> ``` -**For Omnibus installations:** +1. Edit your installation configuration to register the SAML authentication method + in the `upstream_two_factor_authn_contexts` list. How you edit your configuration + will differ depending on your installation type. + +### Omnibus GitLab installations 1. Edit `/etc/gitlab/gitlab.rb`: @@ -456,11 +573,10 @@ In addition to the changes in GitLab, make sure that your IdP is returning the ] ``` -1. Save the file and [reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect. - ---- +1. Save the file and [reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) + GitLab for the changes to take effect. -**For installations from source:** +### Installations from source 1. Edit `config/gitlab.yml`: @@ -486,17 +602,62 @@ In addition to the changes in GitLab, make sure that your IdP is returning the } ``` -1. Save the file and [restart GitLab](../administration/restart_gitlab.md#installations-from-source) for the changes to take effect +1. Save the file and [restart GitLab](../administration/restart_gitlab.md#installations-from-source) + for the changes to take effect. + +## Validate response signatures -## Customization +IdPs must sign SAML responses to ensure that the assertions are not tampered with. -### `auto_sign_in_with_provider` +This prevents user impersonation and privilege escalation when specific group +membership is required. + +You configure the response signature validation using `idp_cert_fingerprint`. +An example configuration: + +```yaml +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://login.example.com/idp', + issuer: 'https://gitlab.example.com', + name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent', +} +``` -You can add this setting to your GitLab configuration to automatically redirect you -to your SAML server for authentication. This removes the requirement to select a button -before actually signing in. +If your IdP does not support configuring this using `idp_cert_fingerprint`, you +can instead configure GitLab directly using `idp_cert`. An example configuration: -For Omnibus package: +```yaml +args: { + assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback', + idp_cert: '-----BEGIN CERTIFICATE----- + <redacted> + -----END CERTIFICATE-----', + idp_sso_target_url: 'https://login.example.com/idp', + issuer: 'https://gitlab.example.com', + name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent', +} +``` + +If you have configured the response signature validation incorrectly, you might see +error messages such as: + +- A key validation error. +- Digest mismatch. +- Fingerprint mismatch. + +For more information on solving these errors, see the [troubleshooting SAML guide](../user/group/saml_sso/troubleshooting.md). + +## Customize SAML settings + +### Redirect users to SAML server for authentication + +You can add the `auto_sign_in_with_provider` setting to your GitLab configuration +to automatically redirect you to your SAML server for authentication. This removes +the requirement to select an element before actually signing in. + +For Omnibus GitLab installations: ```ruby gitlab_rails['omniauth_auto_sign_in_with_provider'] = 'saml' @@ -509,31 +670,28 @@ omniauth: auto_sign_in_with_provider: saml ``` -Keep in mind that every sign in attempt redirects to the SAML server; -you cannot sign in using local credentials. Ensure at least one of the -SAML users has administrator access. +Every sign in attempt redirects to the SAML server, so you cannot sign in using +local credentials. Make sure at least one of the SAML users has administrator access. -You may also bypass the auto sign-in feature by browsing to +You can also bypass the auto sign-in feature by `https://gitlab.example.com/users/sign_in?auto_sign_in=false`. -### `attribute_statements` **(FREE SELF)** - -NOTE: -This setting should be used only to map attributes that are part of the OmniAuth -`info` hash schema. +### Map SAML response attribute names **(FREE SELF)** -`attribute_statements` is used to map Attribute Names in a SAMLResponse to entries +You can use `attribute_statements` to map attribute names in a SAML response to entries in the OmniAuth [`info` hash](https://github.com/omniauth/omniauth/wiki/Auth-Hash-Schema#schema-10-and-later). -For example, if your SAMLResponse contains an Attribute called `EmailAddress`, +NOTE: +Only use this setting to map attributes that are part of the OmniAuth `info` hash schema. + +For example, if your `SAMLResponse` contains an Attribute called `EmailAddress`, specify `{ email: ['EmailAddress'] }` to map the Attribute to the corresponding key in the `info` hash. URI-named Attributes are also supported, for example, `{ email: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'] }`. -This setting allows you tell GitLab where to look for certain attributes required -to create an account. Like mentioned above, if your IdP sends the user's email -address as `EmailAddress` instead of `email`, let GitLab know by setting it on -your configuration: +Use this setting to tell GitLab where to look for certain attributes required +to create an account. If your IdP sends the user's email address as `EmailAddress` +instead of `email`, let GitLab know by setting it on your configuration: ```yaml args: { @@ -566,7 +724,7 @@ args: { This also sets the `username` attribute in your SAML Response to the username in GitLab. -### `allowed_clock_drift` +### Allow for clock drift The clock of the Identity Provider may drift slightly ahead of your system clocks. To allow for a small amount of clock drift, you can use `allowed_clock_drift` in @@ -585,9 +743,11 @@ args: { } ``` -### `uid_attribute` +### Designate a unique attribute for the `uid` -By default, the `uid` is set as the `name_id` in the SAML response. If you'd like to designate a unique attribute for the `uid`, you can set the `uid_attribute`. In the example below, the value of `uid` attribute in the SAML response is set as the `uid_attribute`. +By default, the `uid` is set as the `name_id` in the SAML response. To designate +a unique attribute for the `uid`, you can set the `uid_attribute`. In the following +example, the value of `uid` attribute in the SAML response is set as the `uid_attribute`. ```yaml args: { @@ -600,59 +760,19 @@ args: { } ``` -Make sure you read the [Security](#security) section before changing this value. - -## Response signature validation (required) - -We require Identity Providers to sign SAML responses to ensure that the assertions are -not tampered with. - -This prevents user impersonation and prevents privilege escalation when specific group -membership is required. Typically this: +Before setting the `uid` to a unique attribute, make sure that you have configured +the following attributes so your SAML users cannot change them: -- Is configured using `idp_cert_fingerprint`. -- Includes the full certificate in the response, although if your Identity Provider - doesn't support this, you can directly configure GitLab using the `idp_cert` option. +- [`NameID`](../user/group/saml_sso/index.md#nameid). +- `Email` when used with `omniauth_auto_link_saml_user`. -Example configuration with `idp_cert_fingerprint`: - -```yaml -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://login.example.com/idp', - issuer: 'https://gitlab.example.com', - name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent', -} -``` +If users can change these attributes, they can sign in as other authorized users. +See your SAML IdP documentation for information on how to make these attributes +unchangeable. -Example configuration with `idp_cert`: +## Assertion encryption (optional) -```yaml -args: { - assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback', - idp_cert: '-----BEGIN CERTIFICATE----- - <redacted> - -----END CERTIFICATE-----', - idp_sso_target_url: 'https://login.example.com/idp', - issuer: 'https://gitlab.example.com', - name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent', -} -``` - -If the response signature validation is configured incorrectly, you can see error messages -such as: - -- A key validation error. -- Digest mismatch. -- Fingerprint mismatch. - -Refer to the [troubleshooting section](#troubleshooting) for more information on -debugging these errors. - -## Assertion Encryption (optional) - -GitLab requires the use of TLS encryption with SAML, but in some cases there can be a +GitLab requires the use of TLS encryption with SAML 2.0, but in some cases there can be a need for additional encryption of the assertions. This may be the case, for example, if you terminate TLS encryption early at a load @@ -679,7 +799,7 @@ Your Identity Provider encrypts the assertion with the public certificate of Git NOTE: This integration uses the `certificate` and `private_key` settings for both assertion encryption and request signing. -## Request signing (optional) +## Sign SAML authentication requests (optional) Another optional configuration is to sign SAML authentication requests. GitLab SAML Requests use the SAML redirect binding, so this isn't necessary (unlike the @@ -713,27 +833,21 @@ args: { GitLab signs the request with the provided private key. GitLab includes the configured public x500 certificate in the metadata for your Identity Provider to validate the signature of the received request with. For more information on this option, see the [Ruby SAML gem documentation](https://github.com/onelogin/ruby-saml/tree/v1.7.0). The Ruby SAML gem is used by the [OmniAuth SAML gem](https://github.com/omniauth/omniauth-saml) to implement the client side of the SAML authentication. -## Security - -Avoid user control of the following attributes: +## Password generation for users created through SAML -- [`NameID`](../user/group/saml_sso/index.md#nameid) -- `Email` when used with `omniauth_auto_link_saml_user` - -These attributes define the SAML user. If users can change these attributes, they can impersonate others. - -Refer to the documentation for your SAML Identity Provider for information on how to fix these attributes. +The [Generated passwords for users created through integrated authentication](../security/passwords_for_integrated_authentication_methods.md) guide provides an overview of how GitLab generates and sets passwords for users created via SAML. -## Passwords for users created via SAML +Users authenticated with SSO or SAML must not use a password for Git operations over HTTPS. These users can do one of the following instead: -The [Generated passwords for users created through integrated authentication](../security/passwords_for_integrated_authentication_methods.md) guide provides an overview of how GitLab generates and sets passwords for users created via SAML. +- Set up a [personal access token](../user/profile/personal_access_tokens.md). +- Use the [Git Credential Manager](../user/profile/account/two_factor_authentication.md#git-credential-manager) which securely authenticates using OAuth. ## Link SAML identity for an existing user A user can manually link their SAML identity to an existing GitLab account by following the steps in [Enable OmniAuth for an existing user](omniauth.md#enable-omniauth-for-an-existing-user). -## Configuring Group SAML on a self-managed GitLab instance **(PREMIUM SELF)** +## Group SAML on a self-managed GitLab instance **(PREMIUM SELF)** For information on the GitLab.com implementation, please see the [SAML SSO for GitLab.com groups page](../user/group/saml_sso). @@ -741,10 +855,10 @@ Group SAML SSO helps if you have to allow access via multiple SAML identity prov To proceed with configuring Group SAML SSO instead, enable the `group_saml` OmniAuth provider. This can be done from: -- `gitlab.rb` for [Omnibus GitLab installations](#omnibus-installations). -- `gitlab/config/gitlab.yml` for [source installations](#source-installations). +- `gitlab.rb` for Omnibus GitLab installations. +- `gitlab/config/gitlab.yml` for source installations. -### Limitations +### Self-managed instance group SAML limitations Group SAML on a self-managed instance is limited when compared to the recommended [instance-wide SAML](../user/group/saml_sso/index.md). The recommended solution allows you to take advantage of: @@ -755,7 +869,7 @@ Group SAML on a self-managed instance is limited when compared to the recommende - [Administrator groups](#administrator-groups). - [Auditor groups](#auditor-groups). -### Omnibus installations +For Omnibus installations: 1. Make sure GitLab is [configured with HTTPS](../install/installation.md#using-https). @@ -766,7 +880,7 @@ Group SAML on a self-managed instance is limited when compared to the recommende gitlab_rails['omniauth_providers'] = [{ name: 'group_saml' }] ``` -### Source installations +For installations from source: 1. Make sure GitLab is [configured with HTTPS](../install/installation.md#using-https). @@ -779,78 +893,39 @@ 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://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/create-a-relying-party-trust) -- [Auth0](https://auth0.com/docs/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-identity-provider) - -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 - -1. In the Okta administrator section choose **Applications**. -1. When the app screen comes up you see another button to **Create App Integration** 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 must - crop and resize it. -1. Next, 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 can see a few tabs on the top of the app's - profile. Select 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 can 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. - Use the information below and follow the instructions in the linked Google Workspace article. - -| | 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, 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. | +## Additional configuration for SAML apps on your IdP -You also must setup the following SAML attribute mappings: +When configuring a SAML app on the IdP, your identity provider may require additional configuration, such as the following: -| 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). +| 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. | -When configuring the Google Workspace SAML app, be sure to record the following information: +For example configurations, see the [notes on specific providers](#set-up-identity-providers). -| | 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. | +## Glossary of common terms -While the Google Workspace Administrator provides IdP metadata, Entity ID, and SHA-256 -fingerprint, they are not required. GitLab does not need that information to -connect to the Google Workspace SAML app. +| Term | Description | +|--------------------------------|-------------| +| 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. | +| Single Sign-On (SSO) | Name of authentication scheme. | +| Assertion consumer service URL | The callback on GitLab where users are 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. | ## Troubleshooting |
