Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://docs.gitlab.com/ee/integration/omniauth.html below:

OmniAuth | GitLab Docs

• Tier: Free, Premium, Ultimate
• Offering: GitLab Self-Managed

Users can sign in to GitLab by using their credentials from Google, GitHub, and other popular services. OmniAuth is the Rack framework that GitLab uses to provide this authentication.

When configured, additional sign-in options are displayed on the sign-in page.

GitLab supports the following OmniAuth providers.

Before you configure the OmniAuth provider, configure the settings that are common for all providers.

To change the OmniAuth settings:

1. Edit /etc/gitlab/gitlab.rb:

   # CAUTION!
   # This allows users to sign in without having a user account first. Define the allowed providers
   # using an array, for example, ["saml", "google_oauth2"], 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', 'google_oauth2']
   gitlab_rails['omniauth_auto_link_ldap_user'] = true
   gitlab_rails['omniauth_block_auto_created_users'] = true

2. Save the file and reconfigure GitLab:

   sudo gitlab-ctl reconfigure

1. Export the Helm values:

   helm get values gitlab > gitlab_values.yaml

2. Edit gitlab_values.yaml, and update the omniauth section under globals.appConfig:

   global:
     appConfig:
       omniauth:
         enabled: true
         allowSingleSignOn: ['saml', 'google_oauth2']
         autoLinkLdapUser: false
         blockAutoCreatedUsers: true

   For more details, see the globals documentation.

3. Save the file and apply the new values:

   helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

1. Edit docker-compose.yml:

   version: "3.6"
   services:
     gitlab:
       environment:
         GITLAB_OMNIBUS_CONFIG: |
           gitlab_rails['omniauth_allow_single_sign_on'] = ['saml', 'google_oauth2']
           gitlab_rails['omniauth_auto_link_ldap_user'] = true
           gitlab_rails['omniauth_block_auto_created_users'] = true

2. Save the file and restart GitLab:

1. Edit /home/git/gitlab/config/gitlab.yml:

   ## OmniAuth settings
   omniauth:
     # Allow sign-in by using Google, GitLab, etc. using OmniAuth providers
     # Versions prior to 11.4 require this to be set to true
     # enabled: true
   
     # CAUTION!
     # This allows users to sign in without having a user account first. Define the allowed providers
     # using an array, for example, ["saml", "google_oauth2"], 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", "google_oauth2"]
   
     auto_link_ldap_user: true
   
     # Locks down those users until they have been cleared by the admin (default: true).
     block_auto_created_users: true

2. Save the file and restart GitLab:

   # For systems running systemd
   sudo systemctl restart gitlab.target
   
   # For systems running SysV init
   sudo service gitlab restart

After configuring these settings, you can configure your chosen provider.

History

• Introduced in GitLab 15.3.

If allow_single_sign_on is set, GitLab uses one of the following fields returned in the OmniAuth auth_hash to establish a username in GitLab for the user signing in, choosing the first that exists:

• username.
• nickname.
• email.

You can create GitLab configuration on a per-provider basis, which is supplied to the provider using args. If you set the gitlab_username_claim variable in args for a provider, you can select another claim to use for the GitLab username. The chosen claim must be unique to avoid collisions.

gitlab_rails['omniauth_providers'] = [

  # The generic pattern for configuring a provider with name PROVIDER_NAME

  gitlab_rails['omniauth_providers'] = {
    name: "PROVIDER_NAME"
    ...
    args: { gitlab_username_claim: 'sub' } # For users signing in with the provider you configure, the GitLab username will be set to the "sub" received from the provider
  },

  # Here are examples using GitHub and Kerberos

  gitlab_rails['omniauth_providers'] = {
    name: "github"
    ...
    args: { gitlab_username_claim: 'name' } # For users signing in with GitHub, the GitLab username will be set to the "name" received from GitHub
  },
  {
    name: "kerberos"
    ...
    args: { gitlab_username_claim: 'uid' } # For users signing in with Kerberos, the GitLab username will be set to the "uid" received from Kerberos
  },
]

- { name: 'PROVIDER_NAME',
  # ...
  args: { gitlab_username_claim: 'sub' }
}
- { name: 'github',
  # ...
  args: { gitlab_username_claim: 'name' }
}
- { name: 'kerberos',
  # ...
  args: { gitlab_username_claim: 'uid' }
}

The Generated passwords for users created through integrated authentication guide provides an overview about how GitLab generates and sets passwords for users created with OmniAuth.

If you’re an existing user, after your GitLab account is created, you can activate an OmniAuth provider. For example, if you originally signed in with LDAP, you can enable an OmniAuth provider like Google.

1. Sign in to GitLab with your GitLab credentials, LDAP, or another OmniAuth provider.
2. On the left sidebar, select your avatar.
3. Select Edit profile.
4. On the left sidebar, select Account.
5. In the Connected Accounts section, select the OmniAuth provider, such as Google.
6. You are redirected to the provider. After you authorize GitLab, you are redirected back to GitLab.

You can now use your chosen OmniAuth provider to sign in to GitLab.

Administrators can enable or disable sign-in for some OmniAuth providers.

By default, sign-in is enabled for all the OAuth providers configured in config/gitlab.yml.

To enable or disable an OmniAuth provider:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > General.
3. Expand Sign-in restrictions.
4. In the Enabled OAuth authentication sources section, select or clear the checkbox for each provider you want to enable or disable.

OmniAuth is enabled by default. However, OmniAuth only works if providers are configured and enabled.

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

gitlab_rails['omniauth_enabled'] = false

You can automatically link OmniAuth users with existing GitLab users if their email addresses match.

The following example enables automatic linking for the OpenID Connect provider and the Google OAuth provider.

gitlab_rails['omniauth_auto_link_user'] = ["openid_connect", "google_oauth2"]

omniauth:
  auto_link_user: ["openid_connect", "google_oauth2"]

This method of enabling automatic linking works for all providers except SAML. To enable automatic linking for SAML, see the SAML setup instructions.

You can define a list of external OmniAuth providers. Users who create accounts or sign in to GitLab through the listed providers do not get access to internal projects and are marked as external users.

To define the external providers list, use the full name of the provider, for example, google_oauth2 for Google. For provider names, see the OmniAuth provider name column in the supported providers table.

If you remove an OmniAuth provider from the external providers list, you must manually update the users that use this sign-in method so their accounts are upgraded to full internal accounts.

gitlab_rails['omniauth_external_providers'] = ['saml', 'google_oauth2']

omniauth:
  external_providers: ['saml', 'google_oauth2']

History

• Introduced job_title and organization attributes in GitLab 17.9.

Some providers require additional configuration to synchronize these attributes. For example, SAML providers require mapping profile attributes.

You can enable profile syncing from selected OmniAuth providers. You can sync any combination of the following user attributes:

• name
• email
• job_title
• location
• organization

When authenticating using LDAP, the user’s name and email are always synced.

1. Edit /etc/gitlab/gitlab.rb:

   gitlab_rails['omniauth_sync_profile_from_provider'] = ['saml', 'google_oauth2']
   gitlab_rails['omniauth_sync_profile_attributes'] = ['name', 'email', 'job_title', 'location', 'organization']

2. Save the file and reconfigure GitLab:

   sudo gitlab-ctl reconfigure

1. Export the Helm values:

   helm get values gitlab > values.yaml

2. Edit values.yaml:

   global:
     appConfig:
       omniauth:
         syncProfileFromProvider: ['saml', 'google_oauth2']
         syncProfileAttributes: ['name', 'email', 'job_title', 'location', 'organization']

3. Save the file and apply the new values:

   helm upgrade -f values.yaml gitlab gitlab/gitlab

1. Edit docker-compose.yml:

   version: "3.6"
   services:
     gitlab:
       environment:
         GITLAB_OMNIBUS_CONFIG: |
           gitlab_rails['omniauth_sync_profile_from_provider'] = ['saml', 'google_oauth2']
           gitlab_rails['omniauth_sync_profile_attributes'] = ['name', 'email', 'job_title', 'location', 'organization']

2. Save the file and restart GitLab:

1. Edit /home/git/gitlab/config/gitlab.yml:

   production: &base
     omniauth:
       sync_profile_from_provider: ['saml', 'google_oauth2']
       sync_profile_attributes: ['name', 'email', 'job_title', 'location', 'organization']

2. Save the file and restart GitLab:

   # For systems running systemd
   sudo systemctl restart gitlab.target
   
   # For systems running SysV init
   sudo service gitlab restart

With certain OmniAuth providers, users can sign in without using two-factor authentication (2FA).

To bypass 2FA, you can either:

• Define the allowed providers using an array (for example, ['saml', 'google_oauth2']).
• Specify true to allow all providers, or false to allow none.

This option should be configured only for providers that already have 2FA. The default is false.

This configuration doesn’t apply to SAML.

gitlab_rails['omniauth_allow_bypass_two_factor'] = ['saml', 'google_oauth2']

omniauth:
  allow_bypass_two_factor: ['saml', 'google_oauth2']

You can add the auto_sign_in_with_provider setting to your GitLab configuration to redirect login requests to your OmniAuth provider for authentication. This removes the need to select the provider before signing in.

For example, to enable automatic sign-in for the Azure v2 integration:

gitlab_rails['omniauth_auto_sign_in_with_provider'] = 'azure_activedirectory_v2'

omniauth:
  auto_sign_in_with_provider: azure_activedirectory_v2

Keep in mind that every sign-in attempt is redirected to the OmniAuth provider, so you can’t sign in using local credentials. Ensure at least one of the OmniAuth users is an administrator.

You can also bypass automatic sign-in by browsing to https://gitlab.example.com/users/sign_in?auto_sign_in=false.

Most supported providers include a built-in icon for the rendered sign-in button.

To use your own icon, ensure your image is optimized for rendering at 64 x 64 pixels, then override the icon in one of two ways:

• Provide a custom image path:

  1. If you are hosting the image outside of your GitLab server domain, ensure your content security policies are configured to allow access to the image file.
  2. Depending on your method of installing GitLab, add a custom icon parameter to your GitLab configuration file. Read OpenID Connect OmniAuth provider for an example for the OpenID Connect provider.

• Embed an image directly in a configuration file: This example creates a Base64-encoded version of your image you can serve through a Data URL:

  1. Encode your image file with a GNU base64 command (such as base64 -w 0 <logo.png>) which returns a single-line <base64-data> string.

  2. Add the Base64-encoded data to a custom icon parameter in your GitLab configuration file:

     omniauth:
       providers:
         - { name: '...'
             icon: 'data:image/png;base64,<base64-data>'
             # Additional parameters removed for readability
           }

Because OAuth in GitLab doesn’t support setting the same external authentication and authorization provider as multiple providers, GitLab configuration and user identification must be updated at the same time if the provider or app is changed. For example, you can set up saml and azure_activedirectory_v2 but cannot add a second azure_activedirectory_v2 to the same configuration.

These instructions apply to all methods of authentication where GitLab stores an extern_uid and it is the only data used for user authentication.

When changing apps within a provider, if the user extern_uid does not change, only the GitLab configuration must be updated.

To swap configurations:

1. Change provider configuration in your gitlab.rb file.
2. Update extern_uid for all users that have an identity in GitLab for the previous provider.

To find the extern_uid, look at an existing user’s current extern_uid for an ID that matches the appropriate field in your current provider for the same user.

There are two methods to update the extern_uid:

• Using the Users API. Pass the provider name and the new extern_uid.

• Using the Rails console:

  Identity.where(extern_uid: 'old-id').update!(extern_uid: 'new-id')

Most supported OmniAuth providers don’t support Git over HTTP password authentication. As a workaround, you can authenticate using a personal access token.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4