• 対応プロバイダ
• 共通設定
  • 初期設定の構成
  • プロバイダーごとの設定
  • OmniAuth で作成したユーザーのパスワード
• 既存ユーザーのOmniAuthを有効にする
• インポートソースを無効にすることなく、OmniAuthプロバイダーによるサインインを有効または無効にします。
• OmniAuth を無効にします。
• 既存のユーザと OmniAuth ユーザのリンク
• 外部プロバイダ・リストの作成
• カスタムOmniAuthプロバイダの使用
  • カスタム OmniAuth プロバイダの例
• OmniAuthユーザープロファイルを最新の状態に保つために
• 二要素認証のバイパス
• プロバイダによる自動サインイン
• カスタムOmniAuthプロバイダアイコンを使用
• アプリや設定の変更
• 既知のイシュー

オムニアス

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

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

対応プロバイダ

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

共通設定

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

初期設定の構成

OmniAuthの設定を変更します：

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

プロバイダーごとの設定

GitLab 15.3 で導入されました。

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

• username.
• nickname.
• email.

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

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 で作成したユーザーのパスワード

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 プロバイダのサインインを有効または無効にできます。

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

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

OmniAuth を無効にします。

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

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

gitlab_rails['omniauth_enabled'] = false

omniauth:
  enabled: false

既存のユーザと OmniAuth ユーザのリンク

GitLab 13.4 で導入されました。

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

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

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

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

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

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

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

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

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

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

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

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を使用して認証する場合、ユーザー名と電子メールは常に同期されます。

gitlab_rails['omniauth_sync_profile_from_provider'] = ['twitter', 'google_oauth2']
gitlab_rails['omniauth_sync_profile_attributes'] = ['name', 'email', 'location']

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 には適用されません。

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

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

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

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

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

gitlab_rails['omniauth_auto_sign_in_with_provider'] = 'azure_activedirectory_v2'

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 つの方法があります：

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

• Railsコンソールを使用します：

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

既知のイシュー

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