オムニアス

ユーザーはTwitterやGitHub、その他の一般的なサービスの認証情報を使ってGitLabにサインインすることができます。OmniAuthはGitLabがこの認証を提供するために使用しているRackフレームワークです。

設定すると、サインインページに追加のサインインオプションが表示されます。

対応プロバイダ

GitLabは以下のOmniAuthプロバイダをサポートしています。

プロバイダのドキュメントOmniAuth プロバイダ名
AliCloudalicloud
アトラシアンatlassian_oauth2
Auth0auth0
AWS Cognitocognito
Azure v2azure_activedirectory_v2
Azure v1azure_oauth2
Bitbucket クラウドbitbucket
DingTalkdingtalk
Facebookfacebook
汎用OAuth 2.0oauth2_generic
GitHubgithub
GitLab.comgitlab
Googlegoogle_oauth2
JWTjwt
Kerberoskerberos
OpenID Connectopenid_connect
セールスフォースsalesforce
SAMLsaml
Shibbolethshibboleth
Twittertwitter

共通設定

OmniAuth プロバイダを設定する前に、すべてのプロバイダに共通する設定を行います。

Linuxパッケージ、Docker、セルフコンパイルHelmチャート説明デフォルト値
allow_single_sign_onallowSingleSignOnGitLab アカウントを自動的に作成するプロバイダのリスト。プロバイダ名は、サポートされるプロバイダテーブルのOmniAuth プロバイダ名の列で利用可能です。 falseこれは、既存のGitLabアカウントなしでOmniAuthプロバイダアカウントを使ってサインインすることはできないことを意味します。まずGitLabアカウントを作成し、プロファイル設定からOmniAuthプロバイダーアカウントに接続する必要があります。
auto_link_ldap_userautoLinkLdapUserOmniAuthプロバイダを通して作成されたユーザーに対して、GitLabにLDAP IDを作成します。LDAPインテグレーションを有効にしている場合、この設定を有効にすることができます。ユーザーのuid が LDAP と OmniAuth プロバイダーの両方で同じであることが必要です。false
block_auto_created_usersblockAutoCreatedUsers自動作成されたユーザーを、管理者の承認が得られるまで承認保留状態(サインインできない状態)にします。 true.この値をfalse に設定する場合は、SAML や Google のように制御できるプロバイダを定義してください。そうしないと、インターネット上のどんなユーザーでも、管理者の承認なしにGitLabにサインインできてしまいます。

初期設定の構成

OmniAuthの設定を変更します:

Linux package (Omnibus)
  1. /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", "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
    
  2. ファイルを保存して GitLab を再設定してください:

    sudo gitlab-ctl reconfigure
    
Helm chart (Kubernetes)
  1. Helm の値をエクスポートします:

    helm get values gitlab > gitlab_values.yaml
    
  2. gitlab_values.yaml を編集し、globals.appConfig の下のomniauth セクションを更新します:

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

    詳細については、globalsドキュメントを参照してください。

  3. ファイルを保存して、新しい値を適用します:

    helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
    
Docker
  1. docker-compose.yml を編集します:

    version: "3.6"
    services:
      gitlab:
        environment:
          GITLAB_OMNIBUS_CONFIG: |
            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
    
  2. ファイルを保存して GitLab を再起動します:

    docker compose up -d
    
Self-compiled (source)
  1. /home/git/gitlab/config/gitlab.yml を編集します:

    ## OmniAuth settings
    omniauth:
      # Allow sign-in by using Twitter, Google, 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", "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"]
       
      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. ファイルを保存して GitLab を再起動します:

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

これらの設定を行った後、選択したプロバイダーを設定することができます。

プロバイダーごとの設定

GitLab 15.3 で導入されました

allow_single_sign_on が設定されている場合、GitLab は OmniAuthauth_hash で返される以下のフィールドのうち、サインインするユーザーの GitLab でのユーザー名を確立するために使用します:

  • username.
  • nickname.
  • email.

GitLabの設定はプロバイダごとに作成することができ、args を使ってプロバイダに提供されます。args でプロバイダに対してgitlab_username_claim 変数を設定すると、GitLab のユーザー名に使う別の claim を選択することができます。選択したクレームは、衝突を避けるために一意でなければなりません。

Linux package (Omnibus)
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
  },
]
Self-compiled (source)
- { name: 'PROVIDER_NAME',
  ...
  args: { gitlab_username_claim: 'sub' }
}
- { name: 'github',
  ...
  args: { gitlab_username_claim: 'name' }
}
- { name: 'kerberos',
  ...
  args: { gitlab_username_claim: 'uid' }
}

OmniAuth で作成したユーザーのパスワード

GitLabがOmniAuthで作成したユーザーのパスワードをどのように生成・設定するかについては、Generated passwords for users created through integrated authenticationのガイドをご覧ください。

既存ユーザーのOmniAuthを有効にする

既存のユーザーであれば、GitLabアカウントが作成された後、OmniAuthプロバイダを有効にすることができます。例えば、元々LDAPでサインインしていた場合、TwitterのようなOmniAuthプロバイダを有効にすることができます。

  1. GitLabの認証情報、LDAP、または他のOmniAuthプロバイダーを使ってGitLabにサインインします。
  2. 左のサイドバーで、自分のアバターを選択してください。
  3. プロフィールの編集を選択します。
  4. 左サイドバーで「アカウント」を選択します。
  5. Connected Accountsセクションで、OmniAuthプロバイダ(Twitterなど)を選択します。
  6. プロバイダにリダイレクトされます。GitLabを作成した後、GitLabにリダイレクトされます。

これで、選択したOmniAuthプロバイダーを使ってGitLabにサインインすることができます。

インポートソースを無効にすることなく、OmniAuthプロバイダーによるサインインを有効または無効にします。

管理者は、いくつかの OmniAuth プロバイダのサインインを有効または無効にできます。

note
デフォルトでは、config/gitlab.yml で設定されているすべての OAuth プロバイダに対してサインインが有効になっています。

OmniAuth プロバイダを有効または無効にするには、以下の手順に従います:

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーで、設定 > 一般を選択します。
  4. サインイン制限を展開します。
  5. 有効な OAuth 認証ソース] セクションで、有効または無効にする各プロバイダのチェックボックスをオンまたはオフにします。

OmniAuth を無効にします。

OmniAuth はデフォルトで有効になっています。しかし、OmniAuth はプロバイダが設定され、有効になっている場合にのみ動作します。

OmniAuth プロバイダを個別に無効にしても問題が発生する場合は、 設定ファイルを変更することでOmniAuth サブシステム全体を無効にすることができます。

Linux package (Omnibus)
gitlab_rails['omniauth_enabled'] = false
Self-compiled (source)
omniauth:
  enabled: false

GitLab 13.4 で導入されました

メールアドレスが一致すれば、OmniAuthユーザーを既存のGitLabユーザーと自動的にリンクさせることができます。

以下の例では、OpenID ConnectプロバイダとTwitter OAuthプロバイダの自動リンクを有効にしています。

Linux package (Omnibus)
gitlab_rails['omniauth_auto_link_user'] = ["openid_connect", "twitter"]
Self-compiled (source)
omniauth:
  auto_link_user: ["openid_connect", "twitter"]

自動リンクを有効にするこの方法は、SAML を除くすべてのプロバイダで機能します。SAML の自動リンクを有効にするには、SAML セットアップ手順を参照してください。

外部プロバイダ・リストの作成

外部のOmniAuthプロバイダのリストを定義することができます。リストされたプロバイダーを通してアカウントを作成したりGitLabにサインインするユーザーは、内部プロジェクトにアクセスできず、外部ユーザーとしてマークされます。

外部プロバイダーのリストを定義するには、プロバイダーのフルネームを使ってください。例えば、Googleの場合はgoogle_oauth2 。プロバイダ名については、サポートされているプロバイダ表のOmniAuth プロバイダ名の列を参照してください。

note
外部プロバイダリストから OmniAuth プロバイダを削除した場合、このサインイン方法を使用しているユーザーのアカウントが完全な内部アカウントにアップグレードされるように手動で更新する必要があります。
Linux package (Omnibus)
gitlab_rails['omniauth_external_providers'] = ['twitter', 'google_oauth2']
Self-compiled (source)
omniauth:
  external_providers: ['twitter', 'google_oauth2']

カスタムOmniAuthプロバイダの使用

note
以下の情報は自己コンパイルインストールにのみ適用されます。

GitLabに含まれているOmniAuthプロバイダ以外の認証ソリューションとインテグレーションする必要がある場合は、カスタムOmniAuthプロバイダを使うことができます。

これらの手順は一般的なものです。正確な実装の詳細については、OmniAuthプロバイダのドキュメントを読んでください。

  1. GitLab を停止します:

    sudo service gitlab stop
    
  2. Gemfileに gem を追加します:

    gem "omniauth-your-auth-provider"
    
  3. 新しい OmniAuth プロバイダ gem をインストールします:

    sudo -u git -H bundle install --without development test mysql --path vendor/bundle --no-deployment
    

    これらのコマンドは、初期インストール時にgem をインストールするコマンドと同じで、--deploymentの代わりに--path vendor/bundle --no-deployment を使用します。

  4. GitLab を起動します:

    sudo service gitlab start
    

カスタム OmniAuth プロバイダの例

GitLabにまだインテグレーションされていないプロバイダのセットアップに成功した場合は、お知らせください。

利用可能なすべての認証メカニズムを公式にサポートすることはできませんが、少なくとも特定のニーズがある場合はお手伝いしたいと思います。

OmniAuthユーザープロファイルを最新の状態に保つために

選択したOmniAuthプロバイダからのプロファイル同期を有効にすることができます。以下のユーザー属性の任意の組み合わせを同期できます:

  • name
  • email
  • location

LDAPを使用して認証する場合、ユーザー名と電子メールは常に同期されます。

Linux package (Omnibus)
gitlab_rails['omniauth_sync_profile_from_provider'] = ['twitter', 'google_oauth2']
gitlab_rails['omniauth_sync_profile_attributes'] = ['name', 'email', 'location']
Self-compiled (source)
omniauth:
  sync_profile_from_provider: ['twitter', 'google_oauth2']
  sync_profile_attributes: ['email', 'location']

二要素認証のバイパス

GitLab 12.3 で導入されました。

特定のOmniAuthプロバイダでは、ユーザーは二要素認証(2FA)を使わずにサインインすることができます。

既知のイシューのため、ユーザーは2FAをバイパスするためにGitLabアカウントで2FAを設定する必要があります。そうしないと、GitLabにサインインする際に2FAを設定するよう促されます。

2FAをバイパスするには、以下の方法があります:

  • 許可されるプロバイダを配列で定義します (たとえば、['twitter', 'google_oauth2'])。
  • すべてのプロバイダを許可する場合はtrue を、許可しない場合はfalse を指定します。

このオプションは、すでに2FAを持っているプロバイダに対してのみ設定します。デフォルトはfalse です。

この設定は SAML には適用されません。

Linux package (Omnibus)
gitlab_rails['omniauth_allow_bypass_two_factor'] = ['twitter', 'google_oauth2']
Self-compiled (source)
omniauth:
  allow_bypass_two_factor: ['twitter', 'google_oauth2']

プロバイダによる自動サインイン

GitLabの設定にauto_sign_in_with_provider の設定を追加すると、ログインリクエストを認証のためにOmniAuthプロバイダにリダイレクトすることができます。これにより、サインインする前にプロバイダを選択する必要がなくなります。

例えば、Azure v2インテグレーションで自動サインインを有効にします:

Linux package (Omnibus)
gitlab_rails['omniauth_auto_sign_in_with_provider'] = 'azure_activedirectory_v2'
Self-compiled (source)
omniauth:
  auto_sign_in_with_provider: azure_activedirectory_v2

サインインの試行はすべて OmniAuth プロバイダにリダイレクトされるため、ローカルの認証情報を使用してサインインできないことに注意してください。OmniAuth ユーザーの少なくとも一人が管理者であることを確認してください。

https://gitlab.example.com/users/sign_in?auto_sign_in=false にアクセスして、自動サインインを回避することもできます。

カスタムOmniAuthプロバイダアイコンを使用

ほとんどのサポートされているプロバイダには、レンダリングされたサインインボタンのアイコンが組み込まれています。

独自のアイコンを使用するには、画像が64 x 64ピクセルでレンダリングされるように最適化されていることを確認し、2つの方法のいずれかでアイコンを上書きします:

  • カスタム画像パスを指定します:

    1. GitLabサーバーのドメイン外でイメージをホストしている場合は、コンテンツセキュリティポリシーがイメージファイルへのアクセスを許可するように設定されていることを確認してください。
    2. GitLabのインストール方法に応じて、GitLab設定ファイルにカスタムicon パラメータを追加してください。OpenID Connectプロバイダの例については、OpenID Connect OmniAuthプロバイダをお読みください。
  • 設定ファイルに直接画像を埋め込みます:この例では、Base64エンコードされた画像を作成し、Data URLを通して提供することができます:

    1. GNUbase64 コマンド (base64 -w 0 <logo.png> など) を使って画像ファイルをエンコードします。このコマンドは、1 行の<base64-data> 文字列を返します。
    2. Base64エンコードされたデータをGitLab設定ファイルのカスタムicon パラメータに追加します:

      omniauth:
        providers:
          - { name: '...'
              icon: 'data:image/png;base64,<base64-data>'
              ...
            }
      

アプリや設定の変更

GitLabのOAuthは、同じ外部認証・認可プロバイダを複数のプロバイダとして設定することをサポートしていないため、プロバイダやアプリが変更された場合、GitLabの設定とユーザー識別を同時に更新する必要があります。例えば、saml を設定することはazure_activedirectory_v2 できますが、 azure_activedirectory_v2同じ設定にazure_activedirectory_v2 2つ目を追加することはできません azure_activedirectory_v2

これらの指示は、GitLabがextern_uid を保存し、それがユーザー認証に使用される唯一のデータである認証のすべての方法に適用されます。

プロバイダ内部でアプリを変更する場合、ユーザーextern_uid が変わらないのであれば、GitLabの設定のみを更新する必要があります。

設定を入れ替えるには

  1. gitlab.rb ファイルのプロバイダー設定を変更します。
  2. GitLab で以前のプロバイダーの ID を持っているすべてのユーザーのextern_uid を更新します。

extern_uidを見つけるには、既存のユーザーの現在のextern_uid を見て、同じユーザーの現在のプロバイダーの適切なフィールドと一致する ID を探します。

extern_uid を更新するには、2 つの方法があります:

既知のイシュー

ほとんどの OmniAuth プロバイダは Git over HTTP パスワード認証に対応していません。回避策として、個人アクセストークンを使った認証を行うことができます。