SAML OmniAuth Provider

GitLab can be configured to act as a SAML 2.0 Service Provider (SP). This allows GitLab to consume assertions from a SAML 2.0 Identity Provider (IdP) such as Microsoft ADFS to authenticate users.

First configure SAML 2.0 support in GitLab, then register the GitLab application in your SAML IdP:

Make sure GitLab is configured with HTTPS. See Using HTTPS for instructions.

On your GitLab server, open the configuration file.

For omnibus package:

  sudo editor /etc/gitlab/gitlab.rb

For installations from source:

  cd /home/git/gitlab

  sudo -u git -H editor config/gitlab.yml

See Initial OmniAuth Configuration for initial settings.
To allow your users to use SAML to sign up without having to manually create an account first, don't forget to add the following values to your configuration:

For omnibus package:
```
  gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
  gitlab_rails['omniauth_block_auto_created_users'] = false
```
For installations from source:
```
  allow_single_sign_on: ["saml"]
  block_auto_created_users: false
```
You can also automatically link SAML users with existing GitLab users if their email addresses match by adding the following setting:

For omnibus package:
```
  gitlab_rails['omniauth_auto_link_saml_user'] = true
```
For installations from source:
```
  auto_link_saml_user: true
```

Add the provider configuration:

For omnibus package:

  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:transient'
             },
      label: 'Company Login' # optional label for SAML login button, defaults to "Saml"
    }
  ]

For installations from source:

  - {
      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:transient'
           },
      label: 'Company Login' # optional label for SAML login button, defaults to "Saml"
    }

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).
Change the values of idp_cert_fingerprint, idp_sso_target_url, name_identifier_format to match your IdP. Check the omniauth-saml documentation for details on these options.
Change the value of issuer to a unique name, which will identify the application to the IdP.
Restart GitLab for the changes to take effect.
Register the GitLab SP in your SAML 2.0 IdP, using the application name specified in issuer.

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:

https://gitlab.example.com/users/auth/saml/metadata

At a minimum the IdP must provide a claim containing the user's email address, using claim name email or mail. The email will be used to automatically generate the GitLab username. GitLab will also use claims with name name, first_name, last_name (see the omniauth-saml gem for supported claims).

On the sign in page there should now be a SAML button below the regular sign in form. Click the icon to begin the authentication process. If everything goes well the user will be returned to GitLab and will be signed in.

Troubleshooting

If you see a "500 error" in GitLab when you are redirected back from the SAML sign in page, this likely indicates that GitLab could not get the email address for the SAML user.

Make sure the IdP provides a claim containing the user's email address, using claim name email or mail.

If after signing in into your SAML server you are redirected back to the sign in page and no error is displayed, check your production.log file. It will most likely contain the message Can't verify CSRF token authenticity. This means that there is an error during the SAML request, but this error never reaches GitLab due to the CSRF check.

To bypass this you can add skip_before_action :verify_authenticity_token to the omniauth_callbacks_controller.rb file. This will allow the error to hit GitLab, where it can then be seen in the usual logs, or as a flash message in the login screen.

5.5 KiB Raw Blame History

SAML OmniAuth Provider

Troubleshooting

5.5 KiB

Raw Blame History