OmniAuth

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

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

サポートされているプロバイダー

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

共通設定を行う

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

初期設定を行う

OmniAuth設定を変更するには、次の手順に従います:

これらの設定を終えたら、選択したプロバイダーの設定に進むことができます。

プロバイダーごとの設定

allow_single_sign_onが設定されている場合、GitLabはサインインしているユーザーのユーザー名を決定するために、OmniAuthのauth_hashで返された次のフィールドのいずれかを使用し、存在するフィールドの中で最初に見つかったものを選択します:

• username
• nickname
• email

プロバイダーごとにGitLabの設定を作成し、argsを使用してそのプロバイダーに設定を渡すことができます。あるプロバイダーに対するargsにgitlab_username_claim変数を設定すると、GitLabのユーザー名として使用する別のクレームを選択できます。指定するクレームは、競合が発生しないよう一意である必要があります。

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' }
}

OmniAuthを介して作成されたユーザーのパスワード

統合認証で作成されたユーザーのパスワードの生成に関するガイドでは、OmniAuthで作成されたユーザーに対してGitLabがパスワードを生成および設定する方法の概要を説明しています。

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

既存のユーザーの場合は、GitLabアカウントが作成された後、OmniAuthプロバイダーを有効にできます。たとえば、最初にLDAPでサインインした場合、GoogleなどのOmniAuthプロバイダーを有効にできます。

1. GitLabの認証情報、LDAP、または別のOmniAuthプロバイダーでGitLabにサインインします。
2. 左側のサイドバーで、自分のアバターを選択します。
3. プロファイルの編集を選択します。
4. 左側のサイドバーで、アカウントを選択します。
5. 接続したアカウントセクションで、GoogleなどのOmniAuthプロバイダーを選択します。
6. プロバイダーにリダイレクトされます。GitLabを承認すると、GitLabにリダイレクトされます。

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

インポートソースを無効にせずにOmniAuthプロバイダーでのサインインを有効または無効にする

管理者は、一部のOmniAuthプロバイダーのサインインを有効または無効にできます。

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

1. 左側のサイドバーの下部で、管理者を選択します。
2. 設定 > 一般を選択します。
3. サインインの制限を展開します。
4. 有効なOAuth認証ソースセクションで、有効または無効にする各プロバイダーのチェックボックスをオンまたはオフにします。

OmniAuthを無効にする

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

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

gitlab_rails['omniauth_enabled'] = false

omniauth:
  enabled: false

既存のユーザーをOmniAuthユーザーにリンクする

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

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

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

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

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

外部プロバイダーリストを作成する

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

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

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

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

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

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

• name
• email
• job_title
• location
• organization

LDAPを使用して認証する場合は、ユーザーの名前とメールアドレスは常に同期されます。

2要素認証を回避する

特定のOmniAuthプロバイダーを使用すると、ユーザーは2要素認証（2FA）を使用せずにサインインできます。

2FAを回避するには、次のいずれかを実行します:

• 配列を使用して、許可されるプロバイダーを定義する（例: ['saml', 'google_oauth2']）。
• すべてのプロバイダーを許可する場合はtrue、許可しない場合はfalseを指定する。

このオプションは、すでに2FAを備えているプロバイダーに対してのみ設定する必要があります。デフォルトはfalseです。

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

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

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

プロバイダーで自動的にサインインする

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

たとえば、Azure v2インテグレーションの自動サインインを有効にするには、次の手順に従います:

gitlab_rails['omniauth_auto_sign_in_with_provider'] = 'azure_activedirectory_v2'

omniauth:
  auto_sign_in_with_provider: azure_activedirectory_v2

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

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

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

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

独自のアイコンを使用するには、画像が64 x 64ピクセルで表示されるように最適化されていることを確認したうえで、次の2つの方法のいずれかでアイコンをオーバーライドします:

• Provide a custom image path（カスタム画像パスを指定する）:

  1. GitLabサーバーのドメインの外部で画像をホストしている場合は、画像ファイルへのアクセスを許可するようにコンテンツセキュリティポリシーを設定します。
  2. GitLabのインストール方法に応じて、GitLab設定ファイルにカスタムiconパラメータを追加します。OpenID Connectプロバイダーの例については、OpenID Connect OmniAuthプロバイダーを参照してください。

• Embed an image directly in a configuration file（設定ファイルに画像を直接埋め込む）: この例では、画像のBase64エンコードバージョンを作成します。この形式の画像は、Data URLを介して提供できます:

  1. GNU base64コマンド（例: base64 -w 0 <logo.png>）を使用して画像ファイルをエンコードします。このコマンドは、1行の<base64-data>文字列を返します。

  2. Base64エンコードされたデータを、GitLab設定ファイルのカスタムiconパラメータに追加します:

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

アプリまたは設定を変更する

GitLabのOAuthは、同じ外部認証および認可プロバイダーを複数のプロバイダーとして設定することをサポートしていないため、プロバイダーまたはアプリを変更する場合は、GitLabの設定とユーザーアイデンティティを同時に更新する必要があります。たとえば、samlとazure_activedirectory_v2を設定できますが、同じ設定内にazure_activedirectory_v2をもう1つ追加することはできません。

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

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

設定を切り替えるには、次の手順に従います:

1. gitlab.rbファイルでプロバイダーの設定を変更します。
2. 以前のプロバイダーに対応するGitLabのアイデンティティを持つすべてのユーザーのextern_uidを更新します。

extern_uidを確認するには、既存ユーザーの現在のextern_uidを調べ、同じユーザーについて、現在のプロバイダーの適切なフィールドと一致するIDを特定します。

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

• ユーザーAPIを使用する（プロバイダー名と新しいextern_uidを渡す）。

• Railsコンソールを使用する:

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

既知の問題

ほとんどのサポートされているOmniAuthプロバイダーは、HTTPパスワード認証を介したGitをサポートしていません。回避策として、パーソナルアクセストークンを使用して認証できます。