diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-08-20 21:42:06 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-08-20 21:42:06 +0300 |
commit | 6e4e1050d9dba2b7b2523fdd1768823ab85feef4 (patch) | |
tree | 78be5963ec075d80116a932011d695dd33910b4e /doc/integration/omniauth.md | |
parent | 1ce776de4ae122aba3f349c02c17cebeaa8ecf07 (diff) |
Add latest changes from gitlab-org/gitlab@13-3-stable-ee
Diffstat (limited to 'doc/integration/omniauth.md')
-rw-r--r-- | doc/integration/omniauth.md | 62 |
1 files changed, 41 insertions, 21 deletions
diff --git a/doc/integration/omniauth.md b/doc/integration/omniauth.md index 2ace05a8320..9dd7f2cd9e1 100644 --- a/doc/integration/omniauth.md +++ b/doc/integration/omniauth.md @@ -1,7 +1,8 @@ # OmniAuth GitLab leverages OmniAuth to allow users to sign in using Twitter, GitHub, and -other popular services. +other popular services. [OmniAuth](https://rubygems.org/gems/omniauth/) is +"a generalized Rack framework for multiple-provider authentication, built on Ruby. Configuring OmniAuth does not prevent standard GitLab authentication or LDAP (if configured) from continuing to work. Users can choose to sign in using any @@ -42,9 +43,9 @@ contains some settings that are common for all providers. Before configuring individual OmniAuth providers there are a few global settings that are in common for all providers that we need to consider. -> **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. +NOTE: **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. - `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 @@ -56,16 +57,16 @@ that are in common for all providers that we need to consider. 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` 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. +NOTE: **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: **Note:** +`auto_link_ldap_user` requires the `uid` of the user to be the same in both LDAP +and the OmniAuth provider. To change these settings: @@ -139,10 +140,26 @@ OmniAuth provider for an existing user. The chosen OmniAuth provider is now active and can be used to sign in to GitLab from then on. +## Automatically Link Existing Users to OmniAuth Users + +You can automatically link OmniAuth users with existing GitLab users if their email addresses match by adding the following setting: + +**For Omnibus installations** + +```ruby +gitlab_rails['omniauth_auto_link_user'] = true +``` + +**For installations from source** + +```yaml +omniauth: + auto_link_user: true +``` + ## Configure OmniAuth Providers as External ->**Note:** -This setting was introduced with version 8.7 of GitLab +> Introduced in GitLab 8.7. You can define which OmniAuth providers you want to be `external` so that all users **creating accounts, or logging in via these providers** will not be able to have @@ -150,7 +167,7 @@ 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:** +NOTE: **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. @@ -170,7 +187,7 @@ omniauth: ## Using Custom OmniAuth Providers ->**Note:** +NOTE: **Note:** The following information only applies for installations from source. GitLab uses [OmniAuth](https://github.com/omniauth/omniauth) for authentication and already ships @@ -223,12 +240,11 @@ we'd like to at least help those with specific needs. ## Enable or disable Sign In with an OmniAuth provider without disabling import sources ->**Note:** -This setting was introduced with version 8.8 of GitLab. +> Introduced in GitLab 8.8. Administrators are able to enable or disable Sign In via some OmniAuth providers. ->**Note:** +NOTE: **Note:** By default Sign In is enabled via all the OAuth Providers that have been configured in `config/gitlab.yml`. 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. @@ -325,3 +341,7 @@ 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`. + +## Passwords for users created via OmniAuth + +The [Generated passwords for users created through integrated authentication](../security/passwords_for_integrated_authentication_methods.md) guide provides an overview of how GitLab generates and sets passwords for users created via OmniAuth. |