Yandex Cloud
Search
Contact UsGet started
  • Blog
  • Pricing
  • Documentation
  • All Services
  • System Status
    • Featured
    • Infrastructure & Network
    • Data Platform
    • Containers
    • Developer tools
    • Serverless
    • Security
    • Monitoring & Resources
    • ML & AI
    • Business tools
  • All Solutions
    • By industry
    • By use case
    • Economics and Pricing
    • Security
    • Technical Support
    • Customer Stories
    • Cloud credits to scale your IT product
    • Gateway to Russia
    • Cloud for Startups
    • Education and Science
    • Yandex Cloud Partner program
  • Blog
  • Pricing
  • Documentation
© 2025 Direct Cursus Technology L.L.C.
Yandex Managed Service for GitLab
  • Getting started
    • All guides
    • Getting information about instances
    • Creating and activating an instance
    • Setting up security groups and access restrictions to an instance
    • Stopping and starting an instance
    • Editing instance settings
    • Managing backups
    • Migrating from a custom GitLab installation
    • Migrating to a different availability zone
    • Cleaning up full disk space
    • Deleting an instance
    • Adding and removing users from a project
    • Setting up approval rules
    • Monitoring the instance status
    • Setting up OmniAuth
  • Access management
  • Pricing policy
  • Monitoring metrics
  • Audit Trails events
  • Release notes
  • FAQ

In this article:

  • Adding an authentication provider
  • Authentication provider parameters
  • Bitbucket Cloud
  • Github Enterprise
  • GitLab self-managed
  • Google OAuth 2.0
  • Keycloak
  • LDAP
  • Microsoft Entra ID
  • Microsoft Azure OAuth 2
  • SAML
  • Yandex ID
  • Yandex 360
  1. Step-by-step guides
  2. Setting up OmniAuth

Setting up OmniAuth

Written by
Yandex Cloud
Updated at September 25, 2024
  • Adding an authentication provider
  • Authentication provider parameters
    • Bitbucket Cloud
    • Github Enterprise
    • GitLab self-managed
    • Google OAuth 2.0
    • Keycloak
    • LDAP
    • Microsoft Entra ID
    • Microsoft Azure OAuth 2
    • SAML
    • Yandex ID
    • Yandex 360

With OmniAuth, users can get authorized in GitLab using credentials from other services.

To integrate an authentication provider for GitLab via OmniAuth, add your authentication provider and specify its parameters.

Adding an authentication providerAdding an authentication provider

  1. In the management console, go to the folder page and select Managed Service for GitLab.
  2. Click the instance name and select the OmniAuth tab.
  3. Click Configure.
  4. To add an authentication provider, click Add.
  5. Select a type and specify the authentication provider parameters.
  6. Click Create.

For more information about working with OmniAuth in GitLab, see the GitLab documentation.

Authentication provider parametersAuthentication provider parameters

Some parameters are common to all providers:

  • Allow single sign on: Allow using SSO. If set to true, when a user who has not singed up with GitLab authenticates through OmniAuth, an account in GitLab will be automatically created for them.
  • Auto link users by email: Map the username in OmniAuth to that in GitLab if they have the same email address linked.
  • Block auto-created users: Automatically switch the created accounts to Pending approval until they get approved by an administrator.
  • External provider: Set the external attribute for the provider. Users authorized through this provider will be treated as external and will have no access to internal projects.
  • Auto link LDAP user: Create an LDAP entity for automatically created accounts. This parameter only applies to instances with an LDAP provider connected.

Other parameters depend on the selected provider type.

Bitbucket CloudBitbucket Cloud

  • Label: Name of the authentication provider. You can set any name.
  • Application ID: App ID received when setting up the provider.
  • Application secret: Secret key received when setting up the provider.

You can learn how to obtain an app ID and secret key in this guide on setting up a provider.

Github EnterpriseGithub Enterprise

  • Label: Name of the authentication provider. You can set any name.
  • Application ID: App ID received when setting up the provider.
  • Application secret: Secret key received when setting up the provider.
  • URL: Link to the GitHub repository.

You can learn how to obtain an app ID and secret key in this guide on setting up a provider.

GitLab self-managedGitLab self-managed

  • Label: Name of the authentication provider. You can set any name.
  • Application ID: App ID received when setting up the provider.
  • Application secret: Secret key received when setting up the provider.
  • Site: Link to the GitLab repository.

You can learn how to obtain an app ID and secret key in this guide on setting up a provider.

Google OAuth 2.0Google OAuth 2.0

  • Label: Name of the authentication provider. You can set any name.
  • Application ID: App ID received when setting up the provider.
  • Application secret: Secret key received when setting up the provider.

You can learn how to obtain an app ID and secret key in this guide on setting up a provider.

KeycloakKeycloak

Note

To work with GitLab, the Keycloak server should use HTTPS.

  • Label: Name of the authentication provider. Specify any name.
  • Issuer: Authorization source URL, such as https://keycloak.example.com/realms/myrealm.
  • Client ID: Client ID received when setting up Keycloak.
  • Client secret: Client secret key received when setting up Keycloak.
  • Site: Link to the GitLab repository.

LDAPLDAP

Warning

Before setting up LDAP integration, make sure the users on the LDAP server cannot:

  • Change the mail, email, and userPrincipalName attributes. Users with privileges like this can potentially access any account on the GitLab server.
  • Have a shared email address. LDAP users with a shared email address can use the same account in GitLab.
  • Name: Username displayed in LDAP. It may not include spaces or punctuation marks.
  • Label: LDAP server name. Specify any name.
  • Host: LDAP server IP or domain name.
  • DB_PORT: LDAP server connection port.
  • Username ID: User ID in LDAP.
  • Encryption: Traffic encryption method.
  • Base: Name of the LDAP folder that stores user accounts.
  • Bind DN: (Optional) Unique username (DN) in LDAP.
  • User Filter: (Optional) User filter in LDAP in RFC-4515 format.

Refer to the GitLab documentation to learn how to configure the LDAP server to work with GitLab.

Microsoft Entra IDMicrosoft Entra ID

  • Label: Name of the authentication provider. Specify any name.
  • Client ID: Client ID received when registering an application.
  • Client Secret: Client secret key received when registering an application.
  • Tenant ID: Tenant ID received when registering an application.

Refer to the GitLab documentation to learn how to register an application on the Azure side.

Microsoft Azure OAuth 2Microsoft Azure OAuth 2

  • Label: Name of the authentication provider. Specify any name.
  • Client ID: Client ID received when registering an application.
  • Client Secret: Client secret key received when registering an application.
  • Tenant ID: Tenant ID received when registering an application.

Refer to the GitLab documentation to learn how to register an application on the Azure side.

SAMLSAML

  • Label: Name of the authentication provider. Specify any name.
  • Assertion consumer service URL: HTTPS endpoint of the GitLab instance. To create this URL, add /users/auth/saml/callback to your GitLab instance URL, such as https://example.gitlab.yandexcloud.net/users/auth/saml/callback.
  • IDP certificate fingerprint: SHA1 fingerprint of a public certificate key, e.g., 90:CC:16:F0:8D:.... Issued when configuring the IdP.
  • IDP SSO target URL: URL of the IdP. Issued when configuring the IdP.
  • Issuer: Unique ID of the application where user authentication will be performed, such as https://example.gitlab.yandexcloud.net.
  • Name identifier format: Format of the name identifier. Issued when configuring the IdP.

Refer to the GitLab documentation to learn how to configure SAML on the IdP side.

Yandex IDYandex ID

  • Label: Name of the authentication provider. Specify any name.
  • Client ID: Client ID received when registering an application.
  • Client Secret: Client secret key received when registering an application.
  • Site: Link to the GitLab repository.

Refer to the Yandex.OAuth documentation to learn how to register an application on the IdP side. When registering an app, permit access to the user's email address. If selecting web services as the platform, use the Redirect URI field to specify a URL in the following format:

https://<GitLab_instance_address>/users/auth/Yandex/callback

URL example:

https://my-domain.gitlab.yandexcloud.net/users/auth/Yandex/callback

Warning

When integrating with the Yandex ID service, any user with a Yandex account can log in to your instance. To prevent access by unauthorized users, set the Allow single sign on and Block auto-created users parameters to true. This will allow you to automatically create new users in GitLab but also block them at first log in.

Yandex 360Yandex 360

Yandex 360 uses Yandex ID or LDAP as authentication providers. To allow Yandex 360 users to log into your GitLab instance, add and configure one of these providers in OmniAuth.

Warning

If you use Yandex ID, the authentication process does not include checking users for membership in a Yandex 360 organization. Any user with a Yandex account can log into your GitLab instance. To prevent access by unauthorized users, set the Allow single sign on and Block auto-created users parameters to true. This will allow you to automatically create new users in GitLab but also block them at first log in.

Was the article helpful?

Previous
Monitoring the instance status
Next
All tutorials
© 2025 Direct Cursus Technology L.L.C.