1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
|
---
stage: Manage
group: Authentication and Authorization
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
type: reference
---
# SAML SSO for self-managed GitLab instances **(FREE SELF)**
This page describes how to set up instance-wide SAML single sign on (SSO) for
self-managed GitLab instances.
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.
To set up SAML on GitLab.com, see [SAML SSO for GitLab.com groups](../user/group/saml_sso/index.md).
For more information on:
- OmniAuth provider settings, see the [OmniAuth documentation](omniauth.md).
- Commonly-used terms, see the [glossary of common terms](#glossary-of-common-terms).
## Configure SAML support in GitLab
1. Make sure GitLab is [configured with HTTPS](../install/installation.md#using-https).
1. On your GitLab server, open the configuration file.
For Omnibus installations:
```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. 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.
For Omnibus installations:
```ruby
gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
gitlab_rails['omniauth_block_auto_created_users'] = false
```
For installations from source:
```yaml
omniauth:
enabled: true
allow_single_sign_on: ["saml"]
block_auto_created_users: false
```
1. Optional. You can automatically link SAML users with existing GitLab users if their
email addresses match by adding the following setting.
For Omnibus installations:
```ruby
gitlab_rails['omniauth_auto_link_saml_user'] = true
```
For installations from source:
```yaml
auto_link_saml_user: true
```
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. Configure the following attributes so your SAML users cannot change them:
- [`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'] = [
{
name: "saml",
label: "Provider name", # optional label for login button, defaults to "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://login.example.com/idp",
issuer: "https://gitlab.example.com",
name_identifier_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
}
}
]
```
For installations from source:
```yaml
omniauth:
providers:
- {
name: 'saml',
label: 'Provider name', # optional label for login button, defaults to "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://login.example.com/idp',
issuer: 'https://gitlab.example.com',
name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent'
}
}
```
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 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:
- Using Omnibus, [reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure).
- From source, [restart GitLab](../administration/restart_gitlab.md#installations-from-source).
### Register GitLab in your SAML IdP
1. Register the GitLab SP in your SAML IdP, using the application name specified in `issuer`.
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:
```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
To configure a SAML application on your IdP, you need at least the following information:
- 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 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`.
- 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.
[SAML group memberships](#configure-users-based-on-saml-group-membership) and [Group Sync](../user/group/saml_sso/group_sync.md) do not support multiple IdPs. For more information, see [issue 386605](https://gitlab.com/gitlab-org/gitlab/-/issues/386605).
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', # 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
}
]
```
## Set up identity providers
GitLab support of SAML means you can sign in to GitLab through a wide range
of IdPs.
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.
### Set up Okta
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:
- Make sure you have access to a
[Google Workspace Super Admin account](https://support.google.com/a/answer/2405986#super_admin).
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).
| | 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` |
See [`attribute_statements`](#map-saml-response-attribute-names) for:
- Custom assertion configuration examples.
- How to configure custom username attributes.
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)
## Configure users based on SAML group membership
You can:
- 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/).
- The [name of the SAML provider](#configure-saml-support-in-gitlab). Group
memberships are only supported by a single SAML provider named
`saml`. For more information, see [issue 386605](https://gitlab.com/gitlab-org/gitlab/-/issues/386605).
| Group | Tier | GitLab Enterprise Edition (EE) Only? |
|------------------------------|--------------------|--------------------------------------|
| [Required](#required-groups) | **(FREE SELF)** | Yes |
| [External](#external-groups) | **(FREE SELF)** | No |
| [Admin](#administrator-groups) | **(FREE SELF)** | Yes |
| [Auditor](#auditor-groups) | **(PREMIUM SELF)** | Yes |
### Prerequisites
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>
<saml:Attribute Name="Groups">
<saml:AttributeValue xsi:type="xs:string">Developers</saml:AttributeValue>
<saml:AttributeValue xsi:type="xs:string">Freelancers</saml:AttributeValue>
<saml:AttributeValue xsi:type="xs:string">Admins</saml:AttributeValue>
<saml:AttributeValue xsi:type="xs:string">Auditors</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
```
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 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 `required_groups` setting to configure GitLab to identify which group
membership is required to sign in.
If you do not set `required_groups` or leave the setting empty, anyone with proper
authentication can use the service.
Example configuration:
```yaml
{ name: 'saml',
label: 'Our SAML Provider',
groups_attribute: 'Groups',
required_groups: ['Developers', 'Freelancers', 'Admins', 'Auditors'],
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'
} }
```
### External groups
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',
label: 'Our SAML Provider',
groups_attribute: 'Groups',
external_groups: ['Freelancers'],
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'
} }
```
### Administrator groups
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 `admin_groups` setting to configure GitLab to identify which groups grant
the user administrator access.
Example configuration:
```yaml
{ name: 'saml',
label: 'Our SAML Provider',
groups_attribute: 'Groups',
admin_groups: ['Admins'],
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'
} }
```
### Auditor groups **(PREMIUM SELF)**
> Introduced in GitLab 11.4.
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).
Example configuration:
```yaml
{ name: 'saml',
label: 'Our SAML Provider',
groups_attribute: 'Groups',
auditor_groups: ['Auditors'],
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'
} }
```
## 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
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.
1. Make sure that your IdP is returning the `AuthnContext`. For example:
```xml
<saml:AuthnStatement>
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:MediumStrongCertificateProtectedTransport</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
```
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`:
```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://login.example.com/idp",
issuer: "https://gitlab.example.com",
name_identifier_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent",
upstream_two_factor_authn_contexts:
%w(
urn:oasis:names:tc:SAML:2.0:ac:classes:CertificateProtectedTransport
urn:oasis:names:tc:SAML:2.0:ac:classes:SecondFactorOTPSMS
urn:oasis:names:tc:SAML:2.0:ac:classes:SecondFactorIGTOKEN
)
},
label: "Company Login" # optional label for SAML login button, defaults to "Saml"
}
]
```
1. Save the file and [reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
GitLab for the changes to take effect.
### Installations from source
1. Edit `config/gitlab.yml`:
```yaml
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://login.example.com/idp',
issuer: 'https://gitlab.example.com',
name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
upstream_two_factor_authn_contexts:
[
'urn:oasis:names:tc:SAML:2.0:ac:classes:CertificateProtectedTransport',
'urn:oasis:names:tc:SAML:2.0:ac:classes:SecondFactorOTPSMS',
'urn:oasis:names:tc:SAML:2.0:ac:classes:SecondFactorIGTOKEN'
]
},
label: 'Company Login' # optional label for SAML login button, defaults to "Saml"
}
```
1. Save the file and [restart GitLab](../administration/restart_gitlab.md#installations-from-source)
for the changes to take effect.
## Validate response signatures
IdPs must sign SAML responses to ensure that the assertions are not tampered with.
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',
}
```
If your IdP does not support configuring this using `idp_cert_fingerprint`, you
can instead configure GitLab directly using `idp_cert`. An example configuration:
```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'
```
For installations from source:
```yaml
omniauth:
auto_sign_in_with_provider: saml
```
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 can also bypass the auto sign-in feature by
`https://gitlab.example.com/users/sign_in?auto_sign_in=false`.
### Map SAML response attribute names **(FREE SELF)**
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).
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'] }`.
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: {
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',
attribute_statements: { email: ['EmailAddress'] }
}
```
#### Set a username
By default, the local part of the email address in the SAML response is used to
generate the user's GitLab username.
Configure `nickname` in `attribute_statements` to specify one or more attributes that contain a user's desired username:
```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',
attribute_statements: { nickname: ['username'] }
}
```
This also sets the `username` attribute in your SAML Response to the username in GitLab.
### Allow for clock drift
The clock of the IdP may drift slightly ahead of your system clocks.
To allow for a small amount of clock drift, use `allowed_clock_drift` in
your settings. You must enter the parameter's value in a number and fraction of seconds.
The value given is added to the current time at which the response is validated.
```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',
attribute_statements: { email: ['EmailAddress'] },
allowed_clock_drift: 1 # for one second clock drift
}
```
### Designate a unique attribute for the `uid`
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: {
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',
uid_attribute: 'uid'
}
```
Before setting the `uid` to a unique attribute, make sure that you have configured
the following attributes so your SAML users cannot change them:
- [`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.
## Assertion encryption (optional)
GitLab requires the use of TLS encryption with SAML 2.0. Sometimes, GitLab needs
additional assertion encryption. For example, if you:
- Terminate TLS encryption early at a load balancer.
- Include sensitive details in assertions that you do not want appearing in logs.
Most organizations should not need additional encryption at this layer.
The SAML integration supports `EncryptedAssertion`. To encrypt your assertions,
define the private key and the public certificate of your GitLab instance in the
SAML settings.
When you define the key and certificate, replace all line feeds in the key file with `\n`.
This makes the key file one long string with no line feeds.
```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',
certificate: '-----BEGIN CERTIFICATE-----\n<redacted>\n-----END CERTIFICATE-----',
private_key: '-----BEGIN PRIVATE KEY-----\n<redacted>\n-----END PRIVATE KEY-----'
}
```
Your IdP encrypts the assertion with the public certificate of GitLab.
GitLab decrypts the `EncryptedAssertion` with its private key.
NOTE:
This integration uses the `certificate` and `private_key` settings for both
assertion encryption and request signing.
## Sign SAML authentication requests (optional)
You can configure GitLab to sign SAML authentication requests. This configuration
is optional because GitLab SAML requests use the SAML redirect binding.
To implement signing:
1. Create a private key and public certificate pair for your GitLab instance to
use for SAML.
1. Configure the signing settings in the `security` section of the configuration.
For example:
```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',
certificate: '-----BEGIN CERTIFICATE-----\n<redacted>\n-----END CERTIFICATE-----',
private_key: '-----BEGIN PRIVATE KEY-----\n<redacted>\n-----END PRIVATE KEY-----',
security: {
authn_requests_signed: true, # enable signature on AuthNRequest
want_assertions_signed: true, # enable the requirement of signed assertion
metadata_signed: false, # enable signature on Metadata
signature_method: 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256',
digest_method: 'http://www.w3.org/2001/04/xmlenc#sha256',
}
}
```
GitLab then:
- Signs the request with the provided private key.
- Includes the configured public x500 certificate in the metadata for your IdP
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.
NOTE:
The SAML redirect binding is different to the SAML POST binding. In the POST binding,
signing is required to prevent intermediaries from tampering with the requests.
## Password generation for users created through SAML
GitLab [generates and sets passwords for users created through SAML](../security/passwords_for_integrated_authentication_methods.md).
Users authenticated with SSO or SAML must not use a password for Git operations
over HTTPS. These users can instead:
- 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).
## Configure group SAML SSO on a self-managed instance **(PREMIUM SELF)**
Use group SAML SSO if you have to allow access through multiple SAML IdPs on your
self-managed instance.
To configure group SAML SSO:
1. [Configure GitLab with HTTPS](../install/installation.md#using-https).
1. Enable OmniAuth and the `group_saml` provider.
To do this for Omnibus GitLab installations, edit `gitlab.rb`:
```ruby
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_providers'] = [{ name: 'group_saml' }]
```
For installations from source, edit `gitlab/config/gitlab.yml`:
```yaml
omniauth:
enabled: true
providers:
- { name: 'group_saml' }
```
As a multi-tenant solution, group SAML on a self-managed instance is limited compared
to the recommended [instance-wide SAML](../user/group/saml_sso/index.md). Use
instance-wide SAML to take advantage of:
- [LDAP compatibility](../administration/auth/ldap/index.md).
- [LDAP Group Sync](../user/group/access_and_permissions.md#manage-group-memberships-via-ldap).
- [Required groups](#required-groups).
- [Administrator groups](#administrator-groups).
- [Auditor groups](#auditor-groups).
## Additional configuration for SAML apps on your IdP
When configuring a SAML app on the IdP, your IdP may need 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 IdP. |
| SAML request binding | HTTP Redirect | GitLab (the SP) redirects users to your IdP with a base64 encoded `SAMLRequest` HTTP parameter. |
| SAML response binding | HTTP POST | Specifies how the SAML token is sent by your IdP. 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 the response 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 IdP. |
| NameID format | Persistent | See [NameID format details](../user/group/saml_sso/index.md#nameid-format). |
| Additional URLs | Optional | May include the issuer, identifier, or assertion consumer service URL in other fields on some providers. |
For example configurations, see the [notes on specific providers](#set-up-identity-providers).
## Glossary of common terms
| Term | Description |
|--------------------------------|-------------|
| Identity provider (IdP) | The service that manages your user identities, such as Okta or OneLogin. |
| Service provider (SP) | Consumes assertions from a SAML IdP, such as Okta, to authenticate users. You can configure GitLab 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 a claim or an attribute. |
| Single Sign-On (SSO) | Name of the authentication scheme. |
| Assertion consumer service URL | The callback on GitLab where users are redirected after successfully authenticating with the IdP. |
| Issuer | How GitLab identifies itself to the IdP. Also known as a "Relying party trust identifier". |
| Certificate fingerprint | Confirms 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
See our [troubleshooting SAML guide](../user/group/saml_sso/troubleshooting.md).
|