omniauth.md 11.4 KB
Newer Older
Drew Blessing's avatar
Drew Blessing committed
1 2
# OmniAuth

3 4
GitLab leverages OmniAuth to allow users to sign in using Twitter, GitHub, and
other popular services.
Drew Blessing's avatar
Drew Blessing committed
5

6 7 8
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.
Drew Blessing's avatar
Drew Blessing committed
9

10 11 12
- [Initial OmniAuth Configuration](#initial-omniauth-configuration)
- [Supported Providers](#supported-providers)
- [Enable OmniAuth for an Existing User](#enable-omniauth-for-an-existing-user)
13
- [OmniAuth configuration sample when using Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master#omniauth-google-twitter-github-login)
14
- [Enable or disable Sign In with an OmniAuth provider without disabling import sources](#enable-or-disable-sign-in-with-an-omniauth-provider-without-disabling-import-sources)
15

16 17 18 19 20 21 22 23 24 25 26 27 28 29
## 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.

- [GitHub](github.md)
- [Bitbucket](bitbucket.md)
- [GitLab.com](gitlab.md)
- [Google](google.md)
- [Facebook](facebook.md)
- [Twitter](twitter.md)
- [Shibboleth](shibboleth.md)
- [SAML](saml.md)
30
- [Crowd](../administration/auth/crowd.md)
31
- [Azure](azure.md)
32
- [Auth0](auth0.md)
33
- [Authentiq](../administration/auth/authentiq.md)
34
- [OAuth2Generic](oauth2_generic.md)
Achilleas Pipinellis's avatar
Achilleas Pipinellis committed
35
- [JWT](../administration/auth/jwt.md)
36
- [OpenID Connect](../administration/auth/oidc.md)
37
- [UltraAuth](ultra_auth.md)
38
- [SalesForce](salesforce.md)
39

40
## Initial OmniAuth Configuration
Drew Blessing's avatar
Drew Blessing committed
41

42 43
Before configuring individual OmniAuth providers there are a few global settings
that are in common for all providers that we need to consider.
Drew Blessing's avatar
Drew Blessing committed
44

Nick Thomas's avatar
Nick Thomas committed
45 46 47 48
> **NOTE:**
> Starting from GitLab 11.4, Omniauth is enabled by default. If you're using an
> earlier version, you'll need to explicitly enable it.

49 50 51
- `allow_single_sign_on` allows you to specify the providers you want to allow to
  automatically create an account. It defaults to `false`. If `false` users must
  be created manually or they will not be able to sign in via OmniAuth.
52 53 54
- `auto_link_ldap_user` can be used if you have [LDAP / ActiveDirectory](ldap.md)
  integration enabled. It defaults to false. When enabled, users automatically
  created through OmniAuth will be linked to their LDAP entry as well.
55 56 57
- `block_auto_created_users` defaults to `true`. If `true` auto created users will
  be blocked by default and will have to be unblocked by an administrator before
  they are able to sign in.
Patricio Cano's avatar
Patricio Cano committed
58

59 60 61 62 63 64 65 66 67 68
> **Note:**
> If you set `block_auto_created_users` to `false`, make sure to only
> define providers under `allow_single_sign_on` that you are able to control, like
> SAML, Shibboleth, Crowd or Google, or set it to `false` otherwise any user on
> the Internet will be able to successfully sign in to your GitLab without
> administrative approval.
>
> **Note:**
> `auto_link_ldap_user` requires the `uid` of the user to be the same in both LDAP
> and the OmniAuth provider.
69

70
To change these settings:
71

72
- **For Omnibus package**
73

74
  Open the configuration file:
75

76 77 78
  ```sh
  sudo editor /etc/gitlab/gitlab.rb
  ```
79

80
  and change:
81

82 83 84
  ```ruby
  # Versions prior to 11.4 require this to be set to true
  # gitlab_rails['omniauth_enabled'] = nil
Patricio Cano's avatar
Patricio Cano committed
85

86 87 88 89 90 91 92 93
  # 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_auto_link_ldap_user'] = true
  gitlab_rails['omniauth_block_auto_created_users'] = true
  ```
94

95
- **For installations from source**
96

97
  Open the configuration file:
Drew Blessing's avatar
Drew Blessing committed
98

99 100
  ```sh
  cd /home/git/gitlab
Drew Blessing's avatar
Drew Blessing committed
101

102 103
  sudo -u git -H editor config/gitlab.yml
  ```
Drew Blessing's avatar
Drew Blessing committed
104

105
  and change the following section:
106

107 108 109 110 111 112
  ```yaml
  ## OmniAuth settings
   omniauth:
     # Allow login via Twitter, Google, etc. using OmniAuth providers
     # Versions prior to 11.4 require this to be set to true
     # enabled: true
Drew Blessing's avatar
Drew Blessing committed
113

114 115 116 117 118
     # 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"]
119

120
     auto_link_ldap_user: true
121

122 123 124
     # Locks down those users until they have been cleared by the admin (default: true).
     block_auto_created_users: true
  ```
125

126 127
Now we can choose one or more of the [Supported Providers](#supported-providers)
listed above to continue the configuration process.
128 129

## Enable OmniAuth for an Existing User
Drew Blessing's avatar
Drew Blessing committed
130

131
Existing users can enable OmniAuth for specific providers after the account is
Patricio Cano's avatar
Patricio Cano committed
132
created. For example, if the user originally signed in with LDAP, an OmniAuth
133 134
provider such as Twitter can be enabled. Follow the steps below to enable an
OmniAuth provider for an existing user.
Drew Blessing's avatar
Drew Blessing committed
135 136

1. Sign in normally - whether standard sign in, LDAP, or another OmniAuth provider.
137 138
1. Go to profile settings (the silhouette icon in the top right corner).
1. Select the "Account" tab.
139
1. Under "Connected Accounts" select the desired OmniAuth provider, such as Twitter.
140 141
1. The user will be redirected to the provider. Once the user authorized GitLab
   they will be redirected back to GitLab.
Drew Blessing's avatar
Drew Blessing committed
142 143

The chosen OmniAuth provider is now active and can be used to sign in to GitLab from then on.
144

Patricio Cano's avatar
Patricio Cano committed
145 146 147 148 149 150
## Configure OmniAuth Providers as External

>**Note:**
This setting was introduced with version 8.7 of GitLab

You can define which OmniAuth providers you want to be `external` so that all users
151 152 153 154 155 156 157 158 159
**creating accounts, or logging in via these providers** will not be able to have
access to internal projects. You will need to use the full name of the provider,
like `google_oauth2` for Google. Refer to the examples for the full names of the
supported providers.

>**Note:**
If you decide to remove an OmniAuth provider from the external providers list
you will need to manually update the users that use this method to login, if you
want their accounts to be upgraded to full internal accounts.
Patricio Cano's avatar
Patricio Cano committed
160 161 162 163

**For Omnibus installations**

```ruby
164
gitlab_rails['omniauth_external_providers'] = ['twitter', 'google_oauth2']
Patricio Cano's avatar
Patricio Cano committed
165 166 167 168 169
```

**For installations from source**

```yaml
170 171
omniauth:
  external_providers: ['twitter', 'google_oauth2']
Patricio Cano's avatar
Patricio Cano committed
172 173
```

Patricio Cano's avatar
Patricio Cano committed
174 175 176 177
## Using Custom Omniauth Providers

>**Note:**
The following information only applies for installations from source.
178

179
GitLab uses [Omniauth](https://github.com/omniauth/omniauth) for authentication and already ships
180 181 182
with a few providers pre-installed (e.g. LDAP, GitHub, Twitter). But sometimes that
is not enough and you need to integrate with other authentication solutions. For
these cases you can use the Omniauth provider.
183 184 185

### Steps

186 187
These steps are fairly general and you will need to figure out the exact details
from the Omniauth provider's documentation.
188

189
- Stop GitLab:
190

191 192 193
  ```sh
  sudo service gitlab stop
  ```
194

195
- Add the gem to your [Gemfile](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Gemfile):
196

197 198 199
  ```sh
  gem "omniauth-your-auth-provider"
  ```
200

201
- Install the new Omniauth provider gem by running the following command:
202

203 204 205
  ```sh
  sudo -u git -H bundle install --without development test mysql --path vendor/bundle --no-deployment
  ```
206

207
  > These are the same commands you used during initial installation in the [Install Gems section](../install/installation.md#install-gems) with `--path vendor/bundle --no-deployment` instead of `--deployment`.
208

209
- Start GitLab:
210

211 212 213
  ```sh
  sudo service gitlab start
  ```
214 215 216

### Examples

217 218
If you have successfully set up a provider that is not shipped with GitLab itself,
please let us know.
219

220 221 222
You can help others by reporting successful configurations and probably share a
few insights or provide warnings for common errors or pitfalls by sharing your
experience [in the public Wiki](https://github.com/gitlabhq/gitlab-public-wiki/wiki/Custom-omniauth-provider-configurations).
223

224 225
While we can't officially support every possible authentication mechanism out there,
we'd like to at least help those with specific needs.
226 227

## Enable or disable Sign In with an OmniAuth provider without disabling import sources
228

229
>**Note:**
230
This setting was introduced with version 8.8 of GitLab.
231 232 233 234

Administrators are able to enable or disable Sign In via some OmniAuth providers.

>**Note:**
235
By default Sign In is enabled via all the OAuth Providers that have been configured in `config/gitlab.yml`.
236

237
In order to enable/disable an OmniAuth provider, go to Admin Area -> Settings -> Sign-in Restrictions section -> Enabled OAuth Sign-In sources and select the providers you want to enable or disable.
238 239

![Enabled OAuth Sign-In sources](img/enabled-oauth-sign-in-sources.png)
240

Nick Thomas's avatar
Nick Thomas committed
241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257
## Disabling Omniauth

Starting from version 11.4 of GitLab, Omniauth is enabled by default. This only
has an effect if providers are configured and [enabled](#enable-or-disable-sign-in-with-an-omniauth-provider-without-disabling-import-sources).

If omniauth providers are causing problems even when individually disabled, you
can disable the entire omniauth subsystem by modifying the configuration file:

**For Omnibus installations**

```ruby
gitlab_rails['omniauth_enabled'] = false
```

**For installations from source**

```yaml
258 259
omniauth:
  enabled: false
Nick Thomas's avatar
Nick Thomas committed
260 261
```

262 263 264
## Keep OmniAuth user profiles up to date

You can enable profile syncing from selected OmniAuth providers and for all or for specific user information.
265

266
When authenticating using LDAP, the user's name and email are always synced.
267

268
```ruby
269 270 271
gitlab_rails['sync_profile_from_provider'] = ['twitter', 'google_oauth2']
gitlab_rails['sync_profile_attributes'] = ['name', 'email', 'location']
```
272

273
**For installations from source**
274

275
```yaml
276 277 278
omniauth:
  sync_profile_from_provider: ['twitter', 'google_oauth2']
  sync_profile_attributes: ['email', 'location']
279
```
280

281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300
## Bypassing two factor authentication

Starting with GitLab 12.3, this allows users to login with the specified
providers without two factor authentication.

Define the allowed providers using an array, e.g. `["twitter", 'google_oauth2']`, or as
`true`/`false` to allow all providers or none. This option should only be configured
for providers which already have two factor authentication (default: false).
This configration dose not apply to SAML.

```ruby
gitlab_rails['omniauth_allow_bypass_two_factor'] = ['twitter', 'google_oauth2']
```

**For installations from source**

```yaml
omniauth:
  allow_bypass_two_factor: ['twitter', 'google_oauth2']
```
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

## Automatically sign in with provider

You can add the `auto_sign_in_with_provider` setting to your
GitLab configuration to automatically redirect login requests
to your OmniAuth provider for authentication, thus removing the need to click a button
before actually signing in.

For example, when using the Azure integration, you would set the following
to enable auto sign in.

For Omnibus package:

```ruby
gitlab_rails['omniauth_auto_sign_in_with_provider'] = 'azure_oauth2'
```

For installations from source:

```yaml
omniauth:
  auto_sign_in_with_provider: azure_oauth2
```

Please keep in mind that every sign in attempt will be redirected to the OmniAuth provider,
so you will not be able to sign in using local credentials. Make sure that at least one
of the OmniAuth users has admin permissions.

You may also bypass the auto signin feature by browsing to
`https://gitlab.example.com/users/sign_in?auto_sign_in=false`.