SAML SSO for self-managed GitLab instances All tiers Self-managed
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.
Configure the common settings
to add saml as a single sign-on provider. This enables Just-In-Time
account provisioning for users who do not have an existing GitLab account.
To allow your users to use SAML to sign up without having to manually create
an account first, edit /etc/gitlab/gitlab.rb:
Optional. You can automatically link SAML users with existing GitLab users if their
email addresses match by adding the following setting in /etc/gitlab/gitlab.rb:
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.
Edit /etc/gitlab/gitlab.rb and add the provider configuration:
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"}}]
Where:
assertion_consumer_service_url: The GitLab HTTPS endpoint
(append /users/auth/saml/callback to the HTTPS URL of your GitLab installation).
idp_cert_fingerprint: Your IdP value. It must be a SHA1 fingerprint.
For more information on these values, see the
OmniAuth SAML documentation.
For more information on other configuration settings, see
configuring SAML on your IdP.
idp_sso_target_url: Your IdP value.
issuer: Change to a unique name, which identifies the application to the IdP.
Configure the common settings
to add saml as a single sign-on provider. This enables Just-In-Time
account provisioning for users who do not have an existing GitLab account.
Export the Helm values:
helm get values gitlab > gitlab_values.yaml
To allow your users to use SAML to sign up without having to manually create
an account first, edit gitlab_values.yaml:
Optional. You can automatically link SAML users with existing GitLab users if their
email addresses match by adding the following setting in gitlab_values.yaml:
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.
Put the following content in a file named saml.yaml to be used as a
Kubernetes Secret:
name:'saml'label:'Providername'# 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'
Where:
assertion_consumer_service_url: The GitLab HTTPS endpoint
(append /users/auth/saml/callback to the HTTPS URL of your GitLab installation).
idp_cert_fingerprint: Your IdP value. It must be a SHA1 fingerprint.
For more information on these values, see the
OmniAuth SAML documentation.
For more information on other configuration settings, see
configuring SAML on your IdP.
idp_sso_target_url: Your IdP value.
issuer: Change to a unique name, which identifies the application to the IdP.
Configure the common settings
to add saml as a single sign-on provider. This enables Just-In-Time
account provisioning for users who do not have an existing GitLab account.
To allow your users to use SAML to sign up without having to manually create
an account first, edit docker-compose.yml:
Optional. You can automatically link SAML users with existing GitLab users if their
email addresses match by adding the following setting in docker-compose.yml:
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.
Edit docker-compose.yml and add the provider configuration:
assertion_consumer_service_url: The GitLab HTTPS endpoint
(append /users/auth/saml/callback to the HTTPS URL of your GitLab installation).
idp_cert_fingerprint: Your IdP value. It must be a SHA1 fingerprint.
For more information on these values, see the
OmniAuth SAML documentation.
For more information on other configuration settings, see
configuring SAML on your IdP.
idp_sso_target_url: Your IdP value.
issuer: Change to a unique name, which identifies the application to the IdP.
Configure the common settings
to add saml as a single sign-on provider. This enables Just-In-Time
account provisioning for users who do not have an existing GitLab account.
To allow your users to use SAML to sign up without having to manually create
an account first, edit /home/git/gitlab/config/gitlab.yml:
Optional. You can automatically link SAML users with existing GitLab users if their
email addresses match by adding the following setting in /home/git/gitlab/config/gitlab.yml:
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.
Edit /home/git/gitlab/config/gitlab.yml and add the provider configuration:
omniauth:providers:-{name:'saml',label:'Providername',# 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'}}
Where:
assertion_consumer_service_url: The GitLab HTTPS endpoint
(append /users/auth/saml/callback to the HTTPS URL of your GitLab installation).
idp_cert_fingerprint: Your IdP value. It must be a SHA1 fingerprint.
For more information on these values, see the
OmniAuth SAML documentation.
For more information on other configuration settings, see
configuring SAML on your IdP.
idp_sso_target_url: Your IdP value.
issuer: Change to a unique name, which identifies the application to the IdP.
name_identifier_format: Your IdP value.
Save the file and restart GitLab:
# For systems running systemdsudo systemctl restart gitlab.target
# For systems running SysV initsudo service gitlab restart
Register GitLab in your SAML IdP
Register the GitLab SP in your SAML IdP, using the application name specified in issuer.
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. For more information on other available claims, see
configuring assertions.
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:
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 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.
gitlab_rails['omniauth_providers']=[{name: 'saml',# This must match the following name configuration parameterlabel: 'Provider 1'# Differentiate the two buttons and providers in the UIargs: {name: 'saml',# This is mandatory and must match the provider nameassertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',# URL must match the name of the providerstrategy_class: 'OmniAuth::Strategies::SAML',...# Put here all the required arguments similar to a single provider},},{name: 'saml_2',# This must match the following name configuration parameterlabel: 'Provider 2'# Differentiate the two buttons and providers in the UIargs: {name: 'saml_2',# This is mandatory and must match the provider nameassertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml_2/callback',# URL must match the name of the providerstrategy_class: 'OmniAuth::Strategies::SAML',...# Put here all the required arguments similar to a single provider},}]
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:
Put the following content in a file named saml.yaml to be used as a
Kubernetes Secret
for the first SAML provider:
name:'saml'# At least one provider must be named 'saml'label:'Provider1'# Differentiate the two buttons and providers in the UIargs:name:'saml'# This is mandatory and must match the provider nameassertion_consumer_service_url:'https://gitlab.example.com/users/auth/saml/callback'# URL must match the name of the providerstrategy_class:'OmniAuth::Strategies::SAML'# Mandatory...# Put here all the required arguments similar to a single provider
Put the following content in a file named saml_2.yaml to be used as a
Kubernetes Secret
for the second SAML provider:
name:'saml_2'label:'Provider2'# Differentiate the two buttons and providers in the UIargs:name:'saml_2'# This is mandatory and must match the provider nameassertion_consumer_service_url:'https://gitlab.example.com/users/auth/saml_2/callback'# URL must match the name of the providerstrategy_class:'OmniAuth::Strategies::SAML'# Mandatory...# Put here all the required arguments similar to a single provider
Optional. Set additional SAML providers by following the same steps.
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:
version:"3.6"services:gitlab:environment:GITLAB_OMNIBUS_CONFIG:|gitlab_rails['omniauth_allow_single_sign_on'] = ['saml', 'saml1']gitlab_rails['omniauth_providers'] = [{name: 'saml', # This must match the following name configuration parameterlabel: 'Provider 1' # Differentiate the two buttons and providers in the UIargs: {name: 'saml', # This is mandatory and must match the provider nameassertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback', # URL must match the name of the providerstrategy_class: 'OmniAuth::Strategies::SAML',... # Put here all the required arguments similar to a single provider},},{name: 'saml_2', # This must match the following name configuration parameterlabel: 'Provider 2' # Differentiate the two buttons and providers in the UIargs: {name: 'saml_2', # This is mandatory and must match the provider nameassertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml_2/callback', # URL must match the name of the providerstrategy_class: 'OmniAuth::Strategies::SAML',... # Put here all the required arguments similar to a single provider},}]
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:
production:&baseomniauth:providers:-{name:'saml',# This must match the following name configuration parameterlabel:'Provider1'# Differentiate the two buttons and providers in the UIargs:{name:'saml',# This is mandatory and must match the provider nameassertion_consumer_service_url:'https://gitlab.example.com/users/auth/saml/callback',# URL must match the name of the providerstrategy_class:'OmniAuth::Strategies::SAML',...# Put here all the required arguments similar to a single provider},}-{name:'saml_2',# This must match the following name configuration parameterlabel:'Provider2'# Differentiate the two buttons and providers in the UIargs:{name:'saml_2',# This is mandatory and must match the provider namestrategy_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},}
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:
# For systems running systemdsudo systemctl restart gitlab.target
# For systems running SysV initsudo service gitlab restart
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
In the Okta administrator section choose Applications.
On the app screen, select Create App Integration and then select
SAML 2.0 on the next screen.
Optional. Choose and add a logo from GitLab Press.
You must crop and resize the logo.
Complete the SAML general configuration. Enter:
"Single sign-on URL": Use the assertion consumer service URL.
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 -sha1 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:
Assign users external, administrator or auditor 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.
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:
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.
# For systems running systemdsudo systemctl restart gitlab.target
# For systems running SysV initsudo service gitlab restart
Automatically manage SAML Group Sync
For information on automatically managing GitLab group membership, see SAML Group Sync.
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.
Make sure that your IdP is returning the AuthnContext. For example:
# For systems running systemdsudo systemctl restart gitlab.target
# For systems running SysV initsudo service gitlab restart
Using idp_cert
If your IdP does not support configuring this using idp_cert_fingerprint, you
can instead configure GitLab directly using idp_cert.
An example configuration:
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 systems running systemdsudo systemctl restart gitlab.target
# For systems running SysV initsudo service gitlab restart
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.
To bypass the auto sign-in setting, append ?auto_sign_in=false in the sign in
URL, for example: https://gitlab.example.com/users/sign_in?auto_sign_in=false.
Map SAML response attribute names All tiers Self-managed
You can use attribute_statements to map attribute names in a SAML response to entries
in the OmniAuth info hash.
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. For example, if your IdP sends the user’s email address as EmailAddress
instead of email, let GitLab know by setting it on your configuration:
# For systems running systemdsudo systemctl restart gitlab.target
# For systems running SysV initsudo service gitlab restart
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.
gitlab_rails['omniauth_providers']=[{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',allowed_clock_drift: 1# for one second clock drift}}]
Save the file and reconfigure GitLab:
sudo gitlab-ctl reconfigure
Put the following content in a file named saml.yaml to be used as a
Kubernetes Secret:
name:'saml'label:'OurSAMLProvider'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'allowed_clock_drift:1# for one second clock drift
version:"3.6"services:gitlab:environment:GITLAB_OMNIBUS_CONFIG:|gitlab_rails['omniauth_providers'] = [{ 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',allowed_clock_drift: 1 # for one second clock drift}}]
Save the file and restart GitLab:
docker compose up -d
Edit /home/git/gitlab/config/gitlab.yml:
production:&baseomniauth:providers:-{name:'saml',label:'OurSAMLProvider',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',allowed_clock_drift:1# for one second clock drift}}
Save the file and restart GitLab:
# For systems running systemdsudo systemctl restart gitlab.target
# For systems running SysV initsudo service gitlab restart
Designate a unique attribute for the 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:
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.
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.
# For systems running systemdsudo systemctl restart gitlab.target
# For systems running SysV initsudo service gitlab restart
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.
Your IdP encrypts the assertion with the public certificate of GitLab.
GitLab decrypts the EncryptedAssertion with its private key.
This integration uses the certificate and private_key settings for both
assertion encryption and request signing.
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.
# For systems running systemdsudo systemctl restart gitlab.target
# For systems running SysV initsudo service gitlab restart
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:
Create a private key and public certificate pair for your GitLab instance to
use for SAML.
Configure the signing settings in the security section of the configuration.
For example:
gitlab_rails['omniauth_providers']=[{name: 'saml',label: 'Our SAML Provider',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 AuthNRequestwant_assertions_signed: true,# enable the requirement of signed assertionmetadata_signed: false,# enable signature on Metadatasignature_method: 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256',digest_method: 'http://www.w3.org/2001/04/xmlenc#sha256',}}}]
Save the file and reconfigure GitLab:
sudo gitlab-ctl reconfigure
Put the following content in a file named saml.yaml to be used as a
Kubernetes Secret:
name:'saml'label:'OurSAMLProvider'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:'-----BEGINCERTIFICATE-----\n<redacted>\n-----ENDCERTIFICATE-----'private_key:'-----BEGINPRIVATEKEY-----\n<redacted>\n-----ENDPRIVATEKEY-----'security:authn_requests_signed:true# enable signature on AuthNRequestwant_assertions_signed:true# enable the requirement of signed assertionmetadata_signed:false# enable signature on Metadatasignature_method:'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'digest_method:'http://www.w3.org/2001/04/xmlenc#sha256'
version:"3.6"services:gitlab:environment:GITLAB_OMNIBUS_CONFIG:|gitlab_rails['omniauth_providers'] = [{ name: 'saml',label: 'Our SAML Provider',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 AuthNRequestwant_assertions_signed: true, # enable the requirement of signed assertionmetadata_signed: false, # enable signature on Metadatasignature_method: 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256',digest_method: 'http://www.w3.org/2001/04/xmlenc#sha256',}}}]
Save the file and restart GitLab:
docker compose up -d
Edit /home/git/gitlab/config/gitlab.yml:
production:&baseomniauth:providers:-{name:'saml',label:'OurSAMLProvider',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:'-----BEGINCERTIFICATE-----\n<redacted>\n-----ENDCERTIFICATE-----',private_key:'-----BEGINPRIVATEKEY-----\n<redacted>\n-----ENDPRIVATEKEY-----',security:{authn_requests_signed:true,# enable signature on AuthNRequestwant_assertions_signed:true,# enable the requirement of signed assertionmetadata_signed:false,# enable signature on Metadatasignature_method:'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256',digest_method:'http://www.w3.org/2001/04/xmlenc#sha256',}}}
Save the file and restart GitLab:
# For systems running systemdsudo systemctl restart gitlab.target
# For systems running SysV initsudo service gitlab restart
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.
The Ruby SAML gem is used by the
OmniAuth SAML gem to implement the
client side of the SAML authentication.
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
An administrator can configure GitLab to automatically link SAML users with existing GitLab users.
For more information, see Configure SAML support in GitLab.
# For systems running systemdsudo systemctl restart gitlab.target
# For systems running SysV initsudo service gitlab restart
As a multi-tenant solution, group SAML on a self-managed instance is limited compared
to the recommended instance-wide SAML. Use
instance-wide SAML to take advantage of:
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.