Commit e407b0fc authored by Suzanne Selhorn's avatar Suzanne Selhorn

Merge branch 'kpaizee-omniauth-ctrt-part-1' into 'master'

OmniAuth CTRT edits part 1

See merge request gitlab-org/gitlab!73870
parents 4372e59b a32e84e1
......@@ -41,7 +41,7 @@ To enable the Atlassian OmniAuth provider for passwordless authentication you mu
sudo -u git -H editor /home/git/gitlab/config/gitlab.yml
```
1. See [Initial OmniAuth Configuration](../../integration/omniauth.md#initial-omniauth-configuration) for initial settings to enable single sign-on and add `atlassian_oauth2` as an OAuth provider.
1. See [Configure initial settings](../../integration/omniauth.md#configure-initial-settings) for initial settings to enable single sign-on and add `atlassian_oauth2` as an OAuth provider.
1. Add the provider configuration for Atlassian:
For Omnibus GitLab installations:
......
......@@ -27,7 +27,7 @@ Authentiq generates a Client ID and the accompanying Client Secret for you to us
sudo -u git -H editor /home/git/gitlab/config/gitlab.yml
```
1. See [Initial OmniAuth Configuration](../../integration/omniauth.md#initial-omniauth-configuration) for initial settings to enable single sign-on and add Authentiq as an OAuth provider.
1. See [Configure initial settings](../../integration/omniauth.md#configure-initial-settings) for initial settings to enable single sign-on and add Authentiq as an OAuth provider.
1. Add the provider configuration for Authentiq:
......
......@@ -40,7 +40,7 @@ The following steps enable AWS Cognito as an authentication provider:
## Configure GitLab
1. See [Initial OmniAuth Configuration](../../integration/omniauth.md#initial-omniauth-configuration) for initial settings.
1. See [Configure initial settings](../../integration/omniauth.md#configure-initial-settings) for initial settings.
1. On your GitLab server, open the configuration file.
**For Omnibus installations**
......@@ -88,4 +88,4 @@ Your sign-in page should now display a Cognito button below the regular sign-in
To begin the authentication process, click the icon, and AWS Cognito asks the user to sign in and authorize the GitLab application.
If successful, the user is redirected and signed in to your GitLab instance.
For more information, see the [Initial OmniAuth Configuration](../../integration/omniauth.md#initial-omniauth-configuration).
For more information, see [Configure initial settings](../../integration/omniauth.md#configure-initial-settings).
......@@ -36,7 +36,7 @@ this provider also allows Crowd authentication for Git-over-https requests.
sudo -u git -H editor config/gitlab.yml
```
1. See [Initial OmniAuth Configuration](../../integration/omniauth.md#initial-omniauth-configuration)
1. See [Configure initial settings](../../integration/omniauth.md#configure-initial-settings)
for initial settings.
1. Add the provider configuration:
......
......@@ -25,7 +25,7 @@ JWT will provide you with a secret key for you to use.
sudo -u git -H editor config/gitlab.yml
```
1. See [Initial OmniAuth Configuration](../../integration/omniauth.md#initial-omniauth-configuration) for initial settings.
1. See [Configure initial settings](../../integration/omniauth.md#configure-initial-settings) for initial settings.
1. Add the provider configuration.
For Omnibus GitLab:
......
......@@ -27,7 +27,7 @@ The OpenID Connect provides you with a client's details and secret for you to us
sudo -u git -H editor config/gitlab.yml
```
See [Initial OmniAuth Configuration](../../integration/omniauth.md#initial-omniauth-configuration) for initial settings.
See [Configure initial settings](../../integration/omniauth.md#configure-initial-settings) for initial settings.
1. Add the provider configuration.
......@@ -228,7 +228,7 @@ Azure B2C [offers two ways of defining the business logic for logging in a user]
While cumbersome to configure, custom policies are required because
standard Azure B2C user flows [do not send the OpenID `email` claim](https://github.com/MicrosoftDocs/azure-docs/issues/16566). In
other words, they do not work with the [`allow_single_sign_on` or `auto_link_user` parameters](../../integration/omniauth.md#initial-omniauth-configuration).
other words, they do not work with the [`allow_single_sign_on` or `auto_link_user` parameters](../../integration/omniauth.md#configure-initial-settings).
With a standard Azure B2C policy, GitLab cannot create a new account or
link to an existing one with an email address.
......
......@@ -48,7 +48,7 @@ application.
sudo -u git -H editor config/gitlab.yml
```
1. Read [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration)
1. Read [Configure initial settings](omniauth.md#configure-initial-settings)
for initial settings.
1. Add the provider configuration:
......
......@@ -48,7 +48,7 @@ As you go through the Microsoft procedure, keep the following in mind:
sudo -u git -H editor config/gitlab.yml
```
1. Refer to [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration)
1. Refer to [Configure initial settings](omniauth.md#configure-initial-settings)
for initial settings.
1. Add the provider configuration:
......@@ -154,7 +154,7 @@ After you have created an application, follow the [Microsoft Quickstart document
sudo -u git -H editor config/gitlab.yml
```
1. Refer to [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration)
1. Refer to [Configure initial settings](omniauth.md#configure-initial-settings)
for initial settings.
1. Add the provider configuration:
......
......@@ -28,7 +28,7 @@ configure CAS for back-channel logout.
sudo -u git -H editor config/gitlab.yml
```
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
1. See [Configure initial settings](omniauth.md#configure-initial-settings) for initial settings.
1. Add the provider configuration:
......
......@@ -72,7 +72,7 @@ Facebook. Facebook generates an app ID and secret key for you to use.
sudo -u git -H editor config/gitlab.yml
```
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
1. See [Configure initial settings](omniauth.md#configure-initial-settings) for initial settings.
1. Add the provider configuration:
......
......@@ -29,7 +29,7 @@ When you create an OAuth 2 app in GitHub, you need the following information:
- The URL of your GitLab instance, such as `https://gitlab.example.com`.
- The authorization callback URL; in this case, `https://gitlab.example.com/users/auth`. Include the port number if your GitLab instance uses a non-default port.
See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
See [Configure initial settings](omniauth.md#configure-initial-settings) for initial settings.
After you have configured the GitHub provider, you need the following information. You must substitute that information in the GitLab configuration file in these next steps.
......
......@@ -45,7 +45,7 @@ GitLab.com generates an application ID and secret key for you to use.
sudo -u git -H editor config/gitlab.yml
```
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
1. See [Configure initial settings](omniauth.md#configure-initial-settings) for initial settings.
1. Add the provider configuration:
For Omnibus installations authenticating against **GitLab.com**:
......
......@@ -71,7 +71,7 @@ On your GitLab server:
sudo -u git -H editor config/gitlab.yml
```
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
1. See [Configure initial settings](omniauth.md#configure-initial-settings) for initial settings.
1. Add the provider configuration:
For Omnibus GitLab:
......
......@@ -100,7 +100,7 @@ to authenticate with Kerberos tokens.
#### Enable single sign-on
See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration)
See [Configure initial settings](omniauth.md#configure-initial-settings)
for initial settings to enable single sign-on and add Kerberos servers
as an identity provider.
......@@ -137,7 +137,7 @@ with your Kerberos credentials.
The first time users sign in to GitLab with their Kerberos accounts,
GitLab creates a matching account.
Before you continue, review the [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) options in Omnibus and GitLab source. You must also include `kerberos`.
Before you continue, review the [Configure initial settings](omniauth.md#configure-initial-settings) options in Omnibus and GitLab source. You must also include `kerberos`.
With that information at hand:
......
......@@ -55,7 +55,7 @@ This strategy is designed to allow configuration of the simple OmniAuth SSO proc
sudo -u git -H editor config/gitlab.yml
```
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings
1. See [Configure initial settings](omniauth.md#configure-initial-settings) for initial settings
1. Add the provider-specific configuration for your provider, as [described in the gem's README](https://gitlab.com/satorix/omniauth-oauth2-generic#gitlab-config-example)
......
......@@ -6,25 +6,16 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# OmniAuth **(FREE SELF)**
GitLab leverages OmniAuth to allow users to sign in using Twitter, GitHub, and
other popular services. [OmniAuth](https://rubygems.org/gems/omniauth/) is a
"generalized Rack framework for multiple-provider authentication" built on Ruby.
Users can sign in to GitLab by using their credentials from Twitter, GitHub, and other popular services.
[OmniAuth](https://rubygems.org/gems/omniauth/) is the Rack
framework that GitLab uses to provide this authentication.
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.
If you configure OmniAuth, users can continue to sign in using other
mechanisms, including standard GitLab authentication or LDAP (if configured).
- [Initial OmniAuth Configuration](#initial-omniauth-configuration)
- [Supported Providers](#supported-providers)
- [Enable OmniAuth for an Existing User](#enable-omniauth-for-an-existing-user)
- [OmniAuth configuration sample when using Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master#omniauth-google-twitter-github-login)
- [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)
## Supported providers
## 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.
GitLab supports the following OmniAuth providers.
| Provider documentation | OmniAuth provider name |
|---------------------------------------------------------------------|----------------------------|
......@@ -50,54 +41,32 @@ contains some settings that are common for all providers.
| [Shibboleth](saml.md) | `shibboleth` |
| [Twitter](twitter.md) | `twitter` |
## Initial OmniAuth Configuration
The OmniAuth provider names from the table above are needed to configure a few
global settings that are in common for all providers.
## Configure initial settings
NOTE:
Starting from GitLab 11.4, OmniAuth is enabled by default. If you're using an
In GitLab 11.4 and later, OmniAuth is enabled by default. If you're using an
earlier version, you must explicitly enable it.
- `allow_single_sign_on` allows you to specify the providers that automatically
create a GitLab account. For example, if you wish to enable Azure (v2) and Google,
in Omnibus, specify a list of provider names:
```ruby
gitlab_rails['omniauth_allow_single_sign_on'] = ['azure_activedirectory_v2', 'google_oauth2']
```
The value defaults to `false`. If `false` users must be created manually, or
they can't sign in by using OmniAuth.
Before you configure the OmniAuth provider,
configure the settings that are common for all providers.
- `auto_link_ldap_user` can be used if you have [LDAP / ActiveDirectory](../administration/auth/ldap/index.md)
integration enabled. It defaults to `false`. When enabled, users automatically
created through an OmniAuth provider have their LDAP identity created in GitLab as well.
- `block_auto_created_users` defaults to `true`. If `true`, auto created users will
be blocked pending approval 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. Otherwise, set it to `true`, or any user on
the Internet can 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.
Setting | Description | Default value
---------------------------|-------------|--------------
`allow_single_sign_on` | Enables you to list the providers that automatically create a GitLab account. The provider names are available in the **OmniAuth provider name** column in the [supported providers table](#supported-providers). | The default is `false`. If `false`, users must be created manually, or they can't sign in using OmniAuth.
`auto_link_ldap_user` | If enabled, creates an LDAP identity in GitLab for users that are created through an OmniAuth provider. You can enable this setting if you have the [LDAP (ActiveDirectory)](../administration/auth/ldap/index.md) integration enabled. Requires the `uid` of the user to be the same in both LDAP and the OmniAuth provider. | The default is `false`.
`block_auto_created_users` | If enabled, blocks users that are automatically created from signing in until they are approved by an administrator. | The default is `true`. If you set the value to `false`, make sure you only define providers for `allow_single_sign_on` that you can control, like SAML, Shibboleth, Crowd, or Google. Otherwise, any user on the internet can sign in to GitLab without an administrator's approval.
To change these settings:
- **For Omnibus package**
Open the configuration file:
1. Open the configuration file:
```shell
sudo editor /etc/gitlab/gitlab.rb
```
and change:
1. Update the following section:
```ruby
# CAUTION!
......@@ -111,7 +80,7 @@ To change these settings:
- **For installations from source**
Open the configuration file:
1. Open the configuration file:
```shell
cd /home/git/gitlab
......@@ -119,7 +88,7 @@ To change these settings:
sudo -u git -H editor config/gitlab.yml
```
and change the following section:
1. Update the following section:
```yaml
## OmniAuth settings
......@@ -140,10 +109,10 @@ To change these settings:
block_auto_created_users: true
```
Now we can choose one or more of the [Supported Providers](#supported-providers)
listed above to continue the configuration process.
After configuring these settings, you can configure
your chosen [provider](#supported-providers).
## Enable OmniAuth for an Existing User
## 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
......@@ -160,7 +129,7 @@ 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
## Link existing users to OmniAuth users
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36664) in GitLab 13.4.
......@@ -185,7 +154,7 @@ feature for both an **OpenID Connect provider** and a **Twitter OAuth provider**
auto_link_user: ["openid_connect", "twitter"]
```
## Configure OmniAuth Providers as External
## Configure OmniAuth providers as external
You can define which OmniAuth providers you want to be `external`. Users
creating accounts, or logging in by using these `external` providers cannot have
......@@ -211,7 +180,7 @@ their accounts to be upgraded to full internal accounts.
external_providers: ['twitter', 'google_oauth2']
```
## Using Custom OmniAuth Providers
## Use a custom OmniAuth provider
NOTE:
The following information only applies for installations from source.
......@@ -221,8 +190,6 @@ with a few providers pre-installed, such as LDAP, GitHub, and Twitter. You may a
have to integrate with other authentication solutions. For
these cases, you can use the OmniAuth provider.
### Steps
These steps are fairly general and you must figure out the exact details
from the OmniAuth provider's documentation.
......@@ -252,7 +219,7 @@ from the OmniAuth provider's documentation.
sudo service gitlab start
```
### Examples
### Custom OmniAuth provider examples
If you have successfully set up a provider that is not shipped with GitLab itself,
please let us know.
......@@ -260,7 +227,7 @@ please let us know.
While we can't officially support every possible authentication mechanism out there,
we'd like to at least help those with specific needs.
## 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
Administrators are able to enable or disable **Sign In** by using some OmniAuth providers.
......@@ -276,7 +243,7 @@ To enable/disable an OmniAuth provider:
![Enabled OAuth Sign-In sources](img/enabled-oauth-sign-in-sources_v13_10.png)
## Disabling OmniAuth
## Disable 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).
......@@ -318,7 +285,7 @@ When authenticating using LDAP, the user's name and email are always synced.
sync_profile_attributes: ['email', 'location']
```
## Bypassing two factor authentication
## Bypass two-factor authentication
In GitLab 12.3 or later, users can sign in with specified providers _without_
using two factor authentication.
......@@ -341,7 +308,7 @@ configured only for providers which already have two factor authentication
allow_bypass_two_factor: ['twitter', 'google_oauth2']
```
## Automatically sign in with provider
## Sign in with a provider automatically
You can add the `auto_sign_in_with_provider` setting to your GitLab
configuration to redirect login requests to your OmniAuth provider for
......
......@@ -48,7 +48,7 @@ To get the credentials (a pair of Client ID and Client Secret), you must [create
sudo -u git -H editor config/gitlab.yml
```
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
1. See [Configure initial settings](omniauth.md#configure-initial-settings) for initial settings.
1. Add the provider configuration:
......
......@@ -53,7 +53,7 @@ in your SAML IdP:
sudo -u git -H editor config/gitlab.yml
```
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
1. See [Configure initial settings](omniauth.md#configure-initial-settings) for initial settings.
1. To allow your users to use SAML to sign up without having to manually create
an account first, add the following values to your configuration:
......
......@@ -53,7 +53,7 @@ Twitter. Twitter generates a client ID and secret key for you to use.
sudo -u git -H editor config/gitlab.yml
```
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
1. See [Configure initial settings](omniauth.md#configure-initial-settings) for initial settings.
1. Add the provider configuration:
......
......@@ -108,7 +108,7 @@ GitLab has several features which can help you manage the number of users:
- Enable the [**Require administrator approval for new sign ups**](../../user/admin_area/settings/sign_up_restrictions.md#require-administrator-approval-for-new-sign-ups)
option.
- Enable `block_auto_created_users` for new sign-ups via [LDAP](../../administration/auth/ldap/index.md#basic-configuration-settings) or [OmniAuth](../../integration/omniauth.md#initial-omniauth-configuration).
- Enable `block_auto_created_users` for new sign-ups via [LDAP](../../administration/auth/ldap/index.md#basic-configuration-settings) or [OmniAuth](../../integration/omniauth.md#configure-initial-settings).
- Enable the [User cap](../../user/admin_area/settings/sign_up_restrictions.md#user-cap)
option. **Available in GitLab 13.7 and later**.
- [Disable new sign-ups](../../user/admin_area/settings/sign_up_restrictions.md), and instead manage new
......
......@@ -17,7 +17,7 @@ pending approval state because an administrator has enabled any of the following
- [Require admin approval for new sign-ups](settings/sign_up_restrictions.md#require-administrator-approval-for-new-sign-ups) setting.
- [User cap](settings/sign_up_restrictions.md#user-cap).
- [Block auto-created users (OmniAuth)](../../integration/omniauth.md#initial-omniauth-configuration)
- [Block auto-created users (OmniAuth)](../../integration/omniauth.md#configure-initial-settings)
- [Block auto-created users (LDAP)](../../administration/auth/ldap/index.md#basic-configuration-settings)
When a user registers for an account while this setting is enabled:
......
......@@ -48,7 +48,7 @@ automatically approved in a background job.
NOTE:
This setting doesn't apply to LDAP or OmniAuth users. To enforce approvals for new users
signing up using OmniAuth or LDAP, set `block_auto_created_users` to `true` in the
[OmniAuth configuration](../../../integration/omniauth.md#initial-omniauth-configuration) or
[OmniAuth configuration](../../../integration/omniauth.md#configure-initial-settings) or
[LDAP configuration](../../../administration/auth/ldap/index.md#basic-configuration-settings).
## Require email confirmation
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment