import_sources.rb
-
Jared Szechy authoredJared Szechy authored
OmniAuth
GitLab leverages OmniAuth to allow users to sign in using Twitter, GitHub, and other popular services.
Configuring OmniAuth does not prevent standard GitLab authentication or LDAP (if configured) from continuing to work. Users can choose to sign in using any of the configured mechanisms.
- Initial OmniAuth Configuration
- Supported Providers
- Enable OmniAuth for an Existing User
- OmniAuth configuration sample when using Omnibus GitLab
- Enable or disable Sign In with an OmniAuth provider without disabling import sources
Supported Providers
This is a list of the current supported OmniAuth providers. Before proceeding on each provider's documentation, make sure to first read this document as it contains some settings that are common for all providers.
Initial OmniAuth Configuration
Before configuring individual OmniAuth providers there are a few global settings that are in common for all providers that we need to consider.
- Omniauth needs to be enabled, see details below for example.
-
allow_single_sign_on
allows you to specify the providers you want to allow to automatically create an account. It defaults tofalse
. Iffalse
users must be created manually or they will not be able to sign in via OmniAuth. -
block_auto_created_users
defaults totrue
. Iftrue
auto created users will be blocked by default and will have to be unblocked by an administrator before they are able to sign in.
Note: If you set
block_auto_created_users
tofalse
, make sure to only define providers underallow_single_sign_on
that you are able to control, like SAML, Shibboleth, Crowd or Google, or set it tofalse
otherwise any user on the Internet will be able to successfully sign in to your GitLab without administrative approval.
To change these settings:
-
For omnibus package
Open the configuration file:
sudo editor /etc/gitlab/gitlab.rb
and change:
gitlab_rails['omniauth_enabled'] = true # CAUTION! # This allows users to login without having a user account first. Define the allowed providers # using an array, e.g. ["saml", "twitter"], or as true/false to allow all providers or none. # User accounts will be created automatically when authentication was successful. gitlab_rails['omniauth_allow_single_sign_on'] = ['saml', 'twitter'] gitlab_rails['omniauth_block_auto_created_users'] = true
-
For installations from source
Open the configuration file:
cd /home/git/gitlab sudo -u git -H editor config/gitlab.yml
and change the following section:
## OmniAuth settings omniauth: # Allow login via Twitter, Google, etc. using OmniAuth providers enabled: true # CAUTION! # This allows users to login without having a user account first. Define the allowed providers # using an array, e.g. ["saml", "twitter"], or as true/false to allow all providers or none. # User accounts will be created automatically when authentication was successful. allow_single_sign_on: ["saml", "twitter"] # Locks down those users until they have been cleared by the admin (default: true). block_auto_created_users: true
Now we can choose one or more of the Supported Providers listed above to continue the configuration process.
Enable OmniAuth for an Existing User
Existing users can enable OmniAuth for specific providers after the account is created. For example, if the user originally signed in with LDAP, an OmniAuth provider such as Twitter can be enabled. Follow the steps below to enable an OmniAuth provider for an existing user.
- Sign in normally - whether standard sign in, LDAP, or another OmniAuth provider.
- Go to profile settings (the silhouette icon in the top right corner).
- Select the "Account" tab.
- Under "Connected Accounts" select the desired OmniAuth provider, such as Twitter.
- The user will be redirected to the provider. Once the user authorized GitLab they will be redirected back to GitLab.
The chosen OmniAuth provider is now active and can be used to sign in to GitLab from then on.
Configure OmniAuth Providers as External
Note: This setting was introduced with version 8.7 of GitLab