一般的なSAML用語
一般設定
SAML グループ
二要素認証のバイパス
カスタマイズ
レスポンス署名の検証（必須）
アサーション暗号化（オプション）
署名依頼（任意）
セキュリティ
トラブルシューティング

SAML OmniAuth プロバイダ

このページでは、自己管理GitLabインスタンス用のインスタンスワイドSAMLについて説明します。 GitLab.com上のSAMLについては、SAML SSO for GitLab.comグループを参照してください。

すべての OmniAuth プロバイダに適用される一般的な設定については、OmniAuth のドキュメントも参照してください。

一般的なSAML用語

期間	説明
アイデンティティ・プロバイダ（IdP）	ADFS、Okta、Onelogin、Ping Identityなど、ユーザーIDを管理するサービス。
サービスプロバイダー(SP)	SAMLはGitLabをサービス・プロバイダとみなしています。
主張	名前やロールなど、ユーザーの身元に関する情報の一部。クレームや属性とも呼ばれます。
エスエスオー	シングルサインオン。
アサーション・コンシューマー・サービスのURL	GitLab のコールバックで、ID プロバイダとの認証に成功した後にユーザがリダイレクトされる場所。
発行者	GitLabがIDプロバイダに対して自身を識別する方法。 Relying party trust identifier “とも呼ばれます。
証明書の指紋	サーバが正しい証明書で通信に署名していることを確認することで、SAML を介した通信が安全であることを確認するために使用される。証明書サムプリントとも呼ばれる。

一般設定

GitLabは、SAML 2.0 Service Provider(SP)として動作するように設定することができます。これにより、GitLabはMicrosoft ADFSのようなSAML 2.0 Identity Provider (IdP)からアサーションを消費し、ユーザを認証することができます。

まずGitLabでSAML 2.0サポートを設定し、GitLabアプリケーションをSAML IdPに登録します：

GitLabがHTTPSで設定されていることを確認してください。手順については、HTTPSを使用するを参照してください。
GitLab サーバーで設定ファイルを開きます。
オムニバス・パッケージ用：
```
sudo editor /etc/gitlab/gitlab.rb
```
ソースからのインストールの場合：
```
cd /home/git/gitlab

sudo -u git -H editor config/gitlab.yml
```
最初に手動でアカウントを作成しなくても、ユーザが SAML を使用してサインアップできるようにするには、構成に以下の値を追加することを忘れないでください：
オムニバス・パッケージ用：
```
gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
gitlab_rails['omniauth_block_auto_created_users'] = false
```
ソースからのインストールの場合：
```
omniauth:
  enabled: true
  allow_single_sign_on: ["saml"]
  block_auto_created_users: false
```
また、以下の設定を追加することで、メールアドレスが一致する SAML ユーザーを既存の GitLab ユーザーに自動的にリンクさせることもできます：
オムニバス・パッケージ用：
```
gitlab_rails['omniauth_auto_link_saml_user'] = true
```
ソースからのインストールの場合：
```
auto_link_saml_user: true
```
セキュリティ」のセクションで説明したように、各ユーザについて、SAMLNameID と電子メール・アドレスが固定されていることを確認します。そうしないと、ユーザは他の認証済みユーザとしてサインインできます。

プロバイダの設定を追加します：

オムニバス・パッケージ用：

gitlab_rails['omniauth_providers'] = [
  {
    name: 'saml',
    args: {
             assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
             idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
             idp_sso_target_url: 'https://login.example.com/idp',
             issuer: 'https://gitlab.example.com',
             name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent'
           },
    label: 'Company Login' # optional label for SAML login button, defaults to "Saml"
  }
]

ソースからのインストールの場合：

omniauth:
  providers:
    - {
        name: 'saml',
        args: {
               assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
               idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
               idp_sso_target_url: 'https://login.example.com/idp',
               issuer: 'https://gitlab.example.com',
               name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent'
             },
        label: 'Company Login' # optional label for SAML login button, defaults to "Saml"
      }

assertion_consumer_service_url の値を GitLab の HTTPS エンドポイントに合わせて変更してください（正しい値を生成するために、GitLab インストールの HTTPS URL にusers/auth/saml/callback を追加してください）。
idp_cert_fingerprint,idp_sso_target_url,name_identifier_format の値を IdP に合わせて変更します。フィンガープリントを使用する場合は、SHA1 フィンガープリントでなければなりません。これらのオプションの詳細については、OmniAuth SAML ドキュメントを確認してください。
issuer の値を一意の名前に変更し、IdP に対してアプリケーションを識別します。
変更を有効にするには、Omnibus経由でインストールした場合はGitLabを再設定し、ソースからインストールした場合はGitLabを再起動する必要があります。
issuerで指定したアプリケーション名を使用して、GitLab SP を SAML 2.0 IdP に登録します。

設定を簡単にするために、ほとんどのIdPは、IdPに設定情報を提供するためのアプリケーションのメタデータURLを受け入れます。 GitLabのメタデータURLを構築するには、例えば、GitLabのインストールのHTTPS URLにusers/auth/saml/metadata ：

https://gitlab.example.com/users/auth/saml/metadata

最低限、IdP はユーザのメールアドレスを含むクレームを提供しなければなりません。クレーム名にはemail またはmailを使います。このメールアドレスは GitLab のユーザ名を自動生成するために使われます。GitLab はname,first_name,last_nameという名前のクレームも使います（サポートされているクレームについてはOmniAuth SAML gem を参照）。

サインインページでは、通常のサインインフォームの下に SAML ボタンがあるはずです。アイコンをクリックして認証プロセスを開始します。すべてがうまくいけば、ユーザーは GitLab に戻り、サインインされます。

SAML グループ

ユーザーに特定のグループのメンバーであることを要求したり、グループメンバーシップに基づいてユーザーにexternal、admin 、auditor ロールを割り当てることができます。この機能では、ユーザーをGitLabグループに自動的に追加することはできません。

要件

まず、GitLab にグループの情報を探す場所を教える必要があります。そのためには、IdP サーバーが通常の SAML レスポンスと一緒に特定のAttributeStatement を送信するようにする必要があります。以下に例を示します：

<saml:AttributeStatement>
  <saml:Attribute Name="Groups">
    <saml:AttributeValue xsi:type="xs:string">Developers</saml:AttributeValue>
    <saml:AttributeValue xsi:type="xs:string">Freelancers</saml:AttributeValue>
    <saml:AttributeValue xsi:type="xs:string">Admins</saml:AttributeValue>
    <saml:AttributeValue xsi:type="xs:string">Auditors</saml:AttributeValue>
  </saml:Attribute>
</saml:AttributeStatement>

属性の名前は何でもかまいませんが、ユーザーが所属するグループを含める必要があります。 GitLab にこれらのグループを見つける場所を教えるには、SAML 設定にgroups_attribute: 要素を追加する必要があります。

必須グループ

IdPはSAMLレスポンスでグループ情報をSP（GitLab）に渡します。 GitLabが識別できるように設定する必要があります：

groups_attribute 設定によって SAML レスポンスでグループを探す場所
required_groups 、どのグループに属している必要がありますか？

required_groups が設定されていない、または空の場合、適切な認証があれば誰でもサービスを利用することができます。

使用例：

{ name: 'saml',
  label: 'Our SAML Provider',
  groups_attribute: 'Groups',
  required_groups: ['Developers', 'Freelancers', 'Admins', 'Auditors'],
  args: {
          assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
          idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
          idp_sso_target_url: 'https://login.example.com/idp',
          issuer: 'https://gitlab.example.com',
          name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'
        } }

外部グループ

SAML ログインでは、ユーザを外部ユーザと見なすかどうかの自動識別がサポートされています。これは、 SAML ID プロバイダにおけるユーザのグループ・メンバシップに基づいています。

{ name: 'saml',
  label: 'Our SAML Provider',
  groups_attribute: 'Groups',
  external_groups: ['Freelancers'],
  args: {
          assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
          idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
          idp_sso_target_url: 'https://login.example.com/idp',
          issuer: 'https://gitlab.example.com',
          name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent'
        } }

管理者グループ

要件は前の設定と同じで、IdPがグループ情報をGitLabに渡す必要があり、SAMLレスポンスのどこでグループを探すか、そしてどのグループを管理ユーザーとみなすかをGitLabに伝える必要があります。

{ name: 'saml',
  label: 'Our SAML Provider',
  groups_attribute: 'Groups',
  admin_groups: ['Admins'],
  args: {
          assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
          idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
          idp_sso_target_url: 'https://login.example.com/idp',
          issuer: 'https://gitlab.example.com',
          name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'
        } }

監査役グループ

注：この設定はGitLab 11.4 EE以上でのみ有効です。

要件は前の設定と同じで、IdPがグループ情報をGitLabに渡す必要があり、SAMLレスポンスのどこでグループを探すか、そしてどのグループを監査役ユーザーとみなすかをGitLabに伝える必要があります。

{ name: 'saml',
  label: 'Our SAML Provider',
  groups_attribute: 'Groups',
  auditor_groups: ['Auditors'],
  args: {
          assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
          idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
          idp_sso_target_url: 'https://login.example.com/idp',
          issuer: 'https://gitlab.example.com',
          name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'
        } }

二要素認証のバイパス

いくつかの SAML 認証方式を、セッションごとに 2FA としてカウントしたい場合は、upstream_two_factor_authn_contexts リストに登録します。

GitLab での変更に加えて、IdP がAuthnContextを返していることを確認してください：

<saml:AuthnStatement>
    <saml:AuthnContext>
        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:MediumStrongCertificateProtectedTransport</saml:AuthnContextClassRef>
    </saml:AuthnContext>
</saml:AuthnStatement>

オムニバス・インストール用：

/etc/gitlab/gitlab.rbを編集します：

gitlab_rails['omniauth_providers'] = [
  {
    name: 'saml',
    args: {
             assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
             idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
             idp_sso_target_url: 'https://login.example.com/idp',
             issuer: 'https://gitlab.example.com',
             name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
             upstream_two_factor_authn_contexts:
               %w(
                 urn:oasis:names:tc:SAML:2.0:ac:classes:CertificateProtectedTransport
                 urn:oasis:names:tc:SAML:2.0:ac:classes:SecondFactorOTPSMS
                 urn:oasis:names:tc:SAML:2.0:ac:classes:SecondFactorIGTOKEN
               )

           },
    label: 'Company Login' # optional label for SAML login button, defaults to "Saml"
  }
]

ファイルを保存し、変更を有効にするために GitLab を再設定します。

ソースからのインストールの場合：

config/gitlab.ymlを編集します：

omniauth:
  providers:
    - {
        name: 'saml',
        args: {
                assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
                idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
                idp_sso_target_url: 'https://login.example.com/idp',
                issuer: 'https://gitlab.example.com',
                name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
                upstream_two_factor_authn_contexts:
                  [
                    'urn:oasis:names:tc:SAML:2.0:ac:classes:CertificateProtectedTransport',
                    'urn:oasis:names:tc:SAML:2.0:ac:classes:SecondFactorOTPSMS',
                    'urn:oasis:names:tc:SAML:2.0:ac:classes:SecondFactorIGTOKEN'
                  ]
              },
        label: 'Company Login' # optional label for SAML login button, defaults to "Saml"
      }

ファイルを保存し、変更を有効にするためにGitLabを再起動します。

カスタマイズ

`auto_sign_in_with_provider`

この設定をGitLabの設定に追加すると、認証のためにSAMLサーバーに自動的にリダイレクトされるようになり、実際にサインインする前にボタンをクリックする必要がなくなります。

オムニバス・パッケージ用：

gitlab_rails['omniauth_auto_sign_in_with_provider'] = 'saml'

ソースからのインストールの場合：

omniauth:
  auto_sign_in_with_provider: saml

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

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

`attribute_statements`

注意:この設定は、OmniAuthinfo ハッシュスキーマの一部である属性をマップするためにのみ使用してください。

attribute_statements は、SAMLResponse 内の Attribute Names を OmniAuthinfo ハッシュ内のエントリにマッピングするために使用されます。

たとえば、SAMLResponse に「EmailAddress」という Attribute が含まれている場合、{ email: ['EmailAddress'] } を指定して、Attribute をinfo ハッシュの対応するキーにマッピングします。 URI 名の付いた Attribute にも対応しています (例:{ email: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'] })。

この設定によって、アカウントを作成するために必要な特定の属性を探す場所をGitLabに伝えることができます。上記のように、IdPがユーザーのメールアドレスをemailの代わりにEmailAddress として送信する場合、GitLabの設定でそれを知らせます：

args: {
        assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
        idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
        idp_sso_target_url: 'https://login.example.com/idp',
        issuer: 'https://gitlab.example.com',
        name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
        attribute_statements: { email: ['EmailAddress'] }
}

ユーザー名の設定

デフォルトでは、SAML レスポンスの email を使って GitLab のユーザー名が自動生成されます。別の属性をユーザー名として設定したい場合は、nickname OmniAuthinfo ハッシュ属性に割り当てます。たとえば、SAML レスポンスのusername 属性を GitLab のユーザー名に設定したい場合は、次のように設定します：

args: {
        assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
        idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
        idp_sso_target_url: 'https://login.example.com/idp',
        issuer: 'https://gitlab.example.com',
        name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
        attribute_statements: { nickname: ['username'] }
}

`allowed_clock_drift`

Identity Provider の時計は、システム時計よりわずかに早く動くことがあります。わずかな時計のずれを許容するには、設定内でallowed_clock_drift を使用します。この値は、秒数 (または分数) で指定する必要があります。指定した値は、応答が検証される現在時刻に加算されます。

args: {
        assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
        idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
        idp_sso_target_url: 'https://login.example.com/idp',
        issuer: 'https://gitlab.example.com',
        name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
        attribute_statements: { email: ['EmailAddress'] },
        allowed_clock_drift: 1 # for one second clock drift
}

`uid_attribute`

GitLab 10.7から導入されました。

デフォルトでは、uid が SAML 応答のname_id として設定される。uidに固有の属性を指定する場合は、uid_attributeを設定することができる。以下の例では、SAML 応答のuid 属性の値がuid_attributeとして設定されている。

args: {
        assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
        idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
        idp_sso_target_url: 'https://login.example.com/idp',
        issuer: 'https://gitlab.example.com',
        name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
        uid_attribute: 'uid'
}

この値を変更する前に、セキュリティのセクションを必ずお読みください。

レスポンス署名の検証（必須）

アイデンティティ・プロバイダには、アサーションが改ざんされていないことを保証するために、 SAML 応答に署名することを要求します。

これにより、ユーザーのなりすましを防ぎ、特定のグループメンバーシップが必要な場合に特権の昇格を防ぐことができます：

idp_cert_fingerprintを使って設定します。
レスポンスに完全な証明書を含めますが、Identity Provider がこれをサポートしていない場合は、idp_cert オプションを使って GitLab を直接設定することができます。

idp_cert_fingerprintでの設定例：

args: {
  assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
  idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
  idp_sso_target_url: 'https://login.example.com/idp',
  issuer: 'https://gitlab.example.com',
  name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
}

idp_certでの設定例：

args: {
  assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
  idp_cert: '-----BEGIN CERTIFICATE-----
    <redacted>
    -----END CERTIFICATE-----',
  idp_sso_target_url: 'https://login.example.com/idp',
  issuer: 'https://gitlab.example.com',
  name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
}

レスポンスシグネチャ検証の設定が正しくない場合、以下のようなエラーメッセージが表示されることがあります：

キー検証エラー。
ダイジェスト不一致。
指紋の不一致。

これらのエラーのデバッグの詳細については、トラブルシューティングのセクションを参照してください。

アサーション暗号化（オプション）

GitLab では SAML で TLS 暗号化を使用する必要がありますが、場合によってはアサーションをさらに暗号化する必要があります。

例えば、ロードバランサーでTLS暗号化を早期に終了し、ログに表示されたくない機密情報をアサーションに含める場合などです。ほとんどの組織では、このレイヤーで追加の暗号化を行う必要はありません。

SAML インテグレーションは EncryptedAssertion をサポートしています。 SAML 設定で GitLab インスタンスの秘密鍵と公開証明書を定義する必要があります：

args: {
  assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
  idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
  idp_sso_target_url: 'https://login.example.com/idp',
  issuer: 'https://gitlab.example.com',
  name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
  certificate: '-----BEGIN CERTIFICATE-----
    <redacted>
    -----END CERTIFICATE-----',
  private_key: '-----BEGIN PRIVATE KEY-----
    <redacted>
    -----END PRIVATE KEY-----'
}

Identity Provider は、GitLab の公開証明書でアサーションを暗号化します。 GitLab は、その秘密鍵で EncryptedAssertion を復号化します。

注：このインテグレーションでは、アサーション暗号化とリクエスト署名の両方にcertificate およびprivate_key の設定を使用します。

署名依頼（任意）

GitLab SAML Requests は SAML リダイレクトバインディングを使うのでこの設定は不要ですが、SAML POST バインディングでは仲介者によるリクエストの改ざんを防ぐために署名が必要です。

署名するためには、SAMLで使うGitLabインスタンスの秘密鍵と公開証明書のペアを作成する必要があります。署名に関する設定は、設定のsecurity 。

使用例：

args: {
  assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
  idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
  idp_sso_target_url: 'https://login.example.com/idp',
  issuer: 'https://gitlab.example.com',
  name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
  certificate: '-----BEGIN CERTIFICATE-----
    <redacted>
    -----END CERTIFICATE-----',
  private_key: '-----BEGIN PRIVATE KEY-----
    <redacted>
    -----END PRIVATE KEY-----',
  security: {
    authn_requests_signed: true, # enable signature on AuthNRequest
    want_assertions_signed: true, # enable the requirement of signed assertion
    embed_sign: true, # embedded signature or HTTP GET parameter signature
    metadata_signed: false, # enable signature on Metadata
    signature_method: 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256',
    digest_method: 'http://www.w3.org/2001/04/xmlenc#sha256',
  }
}

GitLabは提供された秘密鍵を使ってリクエストに署名します。 GitLabは設定された公開x500証明書をメタデータに含め、アイデンティティプロバイダが受信したリクエストの署名を検証できるようにします。このオプションの詳細については、RubySAML gemのドキュメントを参照してください。 Ruby SAML gemは、OmniAuth SAML gemがSAML認証のクライアント側を実装するために使用します。

セキュリティ

以下の属性のユーザー制御は避けてください：

*NameID*
と併用した場合の電子メール omniauth_auto_link_saml_user

これらの属性は、SAML ユーザを定義します。ユーザがこれらの属性を変更できる場合、他のユーザになりすますことができます。

これらの属性の修正方法については、SAML ID プロバイダのドキュメントを参照してください。

トラブルシューティング

base64 エンコードされた SAML レスポンスは、production_json.logにあります。

GitLab+SAML テスト環境

トラブルシューティングが必要な場合は、Docker composerを使った完全なGitLab+SAMLのテスト環境を利用できます。

テスト用の SAML プロバイダだけが必要な場合は、プラグアンドプレイの SAML 2.0 アイデンティティ・プロバイダ（IdP）でDockerコンテナを起動するためのクイック・スタート・ガイドが用意されています。

ログイン後の500エラー

SAMLサインインページからリダイレクトされたときにGitLabで “500エラー “が表示された場合は、GitLabがSAMLユーザーのメールアドレスを取得できなかった可能性があります。

IdP が、クレーム名email またはmailを使用して、ユーザのメールアドレスを含むクレームを提供することを確認します。

SAML サーバーにサインインした後、サインインページにリダイレクトされてもエラーが表示されない場合は、production.log ファイルをチェックしてください。Can't verify CSRF token authenticityというメッセージが含まれている可能性が高いです。これは SAML リクエスト中にエラーが発生したことを意味しますが、GitLab 11.7 以前では CSRF チェックによってこのエラーが GitLab に到達することはありません。

これを回避するには、class 行の直後にomniauth_callbacks_controller.rb ファイルにskip_before_action :verify_authenticity_token を追加し、#を使ってprotect_from_forgery 行をコメントアウトします。この変更を有効にするには、Unicorn を再起動します。これにより、エラーが GitLab に反映され、通常のログやログイン画面のフラッシュメッセージで確認できるようになります。

このファイルは、 Omnibus インストールの場合は/opt/gitlab/embedded/service/gitlab-rails/app/controllersに、ソースからのインストールの場合はデフォルトで/home/git/gitlab/app/controllers にあります。 Omnibus インストールの場合はsudo gitlab-ctl restart unicornに、ソースからのインストールの場合はsudo service gitlab restart に、 Unicorn を再起動します。

デバッグには、SAML Tracer（Firefox）およびSAML Chrome Panel（Chrome）のブラウザ拡張機能も役立ちます。

無効な観客

このエラーは、IdPがGitLabをSAMLリクエストの有効な送受信者として認識していないことを意味します。 IdPサーバーの承認者リストにGitLabコールバックURLを追加してください。

クレームの行方

GitLabがアカウントを作成するか、ログイン情報を既存のアカウントと照合するために、IdPサーバーは特定の情報を渡す必要があります。emailは、渡す必要がある最小限の情報です。IdPサーバーがこの情報を提供していない場合、すべてのSAMLリクエストは失敗します。

この情報が提供されていることを確認してください。

このエラーになる可能性がある別の問題は、IdP から正しい情報が送信されているにもかかわらず、属性が OmniAuthinfo ハッシュの名前と一致しない場合です。この場合、SAML 構成でattribute_statements を設定して、SAML レスポンスの属性名を、対応する OmniAuthinfo ハッシュ名にマッピングする必要があります。

鍵検証エラー、ダイジェスト不一致、指紋不一致

これらのエラーはすべて、SAML 証明書という同じような場所から発生している。 SAML リクエストは、フィンガープリント、証明書、またはバリデータを使用して検証する必要があります。

そのためには、以下を考慮する必要があります：

フィンガープリントを使用する場合は、SHA1フィンガープリントでなければなりません。
設定で証明書が提供されていない場合、フィンガープリントまたはフィンガープリントバリデータを提供する必要があり、サーバーからの応答には証明書が含まれている必要があります (<ds:KeyInfo><ds:X509Data><ds:X509Certificate>)
設定で証明書が提供される場合、リクエストに証明書を含める必要はなくなります。この場合、フィンガープリントまたはフィンガープリント検証者は任意です。

上記のシナリオのいずれかが有効であることを確認してください。さもないと、リクエストは前述のエラーのいずれかで失敗します。

SAML OmniAuth プロバイダ

SAML OmniAuth プロバイダ

一般的なSAML用語

一般設定

SAML グループ

要件

必須グループ

外部グループ

管理者グループ

監査役グループ

二要素認証のバイパス

カスタマイズ

auto_sign_in_with_provider

attribute_statements

ユーザー名の設定

allowed_clock_drift

uid_attribute

レスポンス署名の検証（必須）

アサーション暗号化（オプション）

署名依頼（任意）

セキュリティ

トラブルシューティング

GitLab+SAML テスト環境

ログイン後の500エラー

明らかなエラーなしでログイン画面に戻るリダイレクト

無効な観客

クレームの行方

鍵検証エラー、ダイジェスト不一致、指紋不一致

クリエーションラインについて

`auto_sign_in_with_provider`

`attribute_statements`

`allowed_clock_drift`

`uid_attribute`