Geoとシングルサインオン（SSO）

プラン: Premium、Ultimate
提供形態: GitLab Self-Managed

このドキュメントでは、Geoに固有のSSOの考慮事項と設定についてのみ説明します。一般的な認証の詳細については、GitLabの認証と認可を参照してください。

インスタンス全体のSAMLの設定

前提要件

インスタンス全体のSAMLがプライマリGeoサイトで動作している必要があります。

プライマリサイトでのみSAMLを設定します。セカンダリサイトのgitlab.rbにあるgitlab_rails['omniauth_providers']を設定しても効果はありません。セカンダリサイトは、プライマリサイトで設定されたSAMLプロバイダーに対して認証を行います。セカンダリサイトのURLタイプによっては、プライマリサイトで追加の設定が必要になる場合があります。

セカンダリサイトで使用するURLのタイプの決定

インスタンス全体のSAMLの設定方法は、セカンダリサイトの設定によって異なります。セカンダリサイトが以下を使用しているかどうかを判断します:

統合URL。これは、external_urlがプライマリサイトのexternal_urlと完全に一致することを意味します。
プロキシが有効になっている個別のURL。GitLab 15.1以降、Geoプロキシはデフォルトで有効になっています。
プロキシが無効になっている個別のURL。

統合URLでのSAML

プライマリサイトでSAMLを正しく設定している場合は、追加の設定なしでセカンダリサイトで動作するはずです。

プロキシが有効になっている個別のURLでのSAML

プロキシが有効になっている場合、SAML IDプロバイダー（IdP）が、アプリケーションに複数のコールバックURLを設定できるようにする場合にのみ、SAMLを使用してセカンダリサイトにサインインできます。これに該当するかどうかを確認するには、IdPプロバイダーのサポートチームにお問い合わせください。

セカンダリサイトがプライマリサイトとは異なるexternal_urlを使用している場合は、セカンダリサイトのSAMLコールバックURLを許可するようにSAML IDプロバイダー（IdP）を設定します。たとえば、Oktaを設定するには:

Oktaにサインイン。
Okta Admin Dashboard > アプリケーション > Your App Name（アプリ名） > 一般に移動します。
SAML Settings（SAML設定）で、編集を選択します。
一般設定で、次へを選択して、SAML Settings（SAML設定）に移動します。
SAML Settings（SAML設定） > 一般で、Single sign-on URL（シングルサインオンURL）がプライマリサイトのSAMLコールバックURLであることを確認します。たとえばhttps://gitlab-primary.example.com/users/auth/saml/callbackなどです。そうでない場合は、このフィールドにプライマリサイトのSAMLコールバックURLを入力します。
Show Advanced Settings（高度な設定を表示）を選択します。
Other Requestable SSO URLs（リクエスト可能なその他のSSO URL）に、セカンダリサイトのSAMLコールバックURLを入力します。たとえばhttps://gitlab-secondary.example.com/users/auth/saml/callbackなどです。インデックスには任意の値設定できます。
次へ、Finish（完了）の順に選択します。

プライマリサイトのgitlab.rbのgitlab_rails['omniauth_providers']にあるSAMLプロバイダーの設定で、assertion_consumer_service_urlを指定しないでください。例:

gitlab_rails['omniauth_providers'] = [
  {
    name: "saml",
    label: "Okta", # optional label for login button, defaults to "Saml"
    args: {
      idp_cert_fingerprint: "B5:AD:AA:9E:3C:05:68:AD:3B:78:ED:31:99:96:96:43:9E:6D:79:96",
      idp_sso_target_url: "https://<dev-account>.okta.com/app/dev-account_gitlabprimary_1/exk7k2gft2VFpVFXa5d1/sso/saml",
      issuer: "https://<gitlab-primary>",
      name_identifier_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
    }
  }
]

この設定により、次のようになります:

両方のサイトで、アサーションコンシューマーサービス（ACS）URLとして/users/auth/saml/callbackを使用します。
URLのホストが、対応するサイトのホストに設定されます。

各サイトの/users/auth/saml/metadataパスにアクセスして、これを確認できます。たとえば、https://gitlab-primary.example.com/users/auth/saml/metadataにアクセスすると、次のように応答する場合があります:

<md:EntityDescriptor ID="_b9e00d84-d34e-4e3d-95de-122e3c361617" entityID="https://gitlab-primary.example.com"
  xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
  <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://gitlab-primary.example.com/users/auth/saml/callback"    index="0" isDefault="true"/>
    <md:AttributeConsumingService index="1" isDefault="true">
      <md:ServiceName xml:lang="en">Required attributes</md:ServiceName>
      <md:RequestedAttribute FriendlyName="Email address" Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
      <md:RequestedAttribute FriendlyName="Full name" Name="name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
      <md:RequestedAttribute FriendlyName="Given name" Name="first_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
      <md:RequestedAttribute FriendlyName="Family name" Name="last_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
    </md:AttributeConsumingService>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

https://gitlab-secondary.example.com/users/auth/saml/metadataにアクセスすると、次のように応答する場合があります:

<md:EntityDescriptor ID="_bf71eb57-7490-4024-bfe2-54cec716d4bf" entityID="https://gitlab-primary.example.com"
  xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
  <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://gitlab-secondary.example.com/users/auth/saml/callback"    index="0" isDefault="true"/>
    <md:AttributeConsumingService index="1" isDefault="true">
      <md:ServiceName xml:lang="en">Required attributes</md:ServiceName>
      <md:RequestedAttribute FriendlyName="Email address" Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
      <md:RequestedAttribute FriendlyName="Full name" Name="name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
      <md:RequestedAttribute FriendlyName="Given name" Name="first_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
      <md:RequestedAttribute FriendlyName="Family name" Name="last_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
    </md:AttributeConsumingService>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

md:AssertionConsumerServiceフィールドのLocation属性は、gitlab-secondary.example.comを指します。

セカンダリサイトのSAMLコールバックURLを許可するようにSAML IdPを設定すると、プライマリサイトとセカンダリサイトでSAMLを使用してサインインできるようになります。

プロキシが無効になっている個別のURLでのSAML

プライマリサイトでSAMLを正しく設定している場合は、追加の設定なしでセカンダリサイトで動作するはずです。

OpenID Connect

OpenID Connect OmniAuthプロバイダーを使用している場合、ほとんどの場合、問題なく動作します:

OIDC with Unified URL（統合URLを使用したOIDC）: プライマリサイトでOIDCを正しく設定している場合は、追加の設定なしでセカンダリサイトで動作するはずです。
OIDC with separate URL with proxying disabled（プロキシが無効になっている個別のURLを使用したOIDC）: プライマリサイトでOIDCを正しく設定している場合は、追加の設定なしでセカンダリサイトで動作するはずです。
OIDC with separate URL with proxying enabled（プロキシが有効になっている個別のURLを使用したOIDC）: プロキシが有効になっている個別のURLを使用したGeoは、OpenID Connectをサポートしていません。詳細については、issue 396745を参照してください。

LDAP

プライマリサイトでLDAPを使用している場合、セカンダリが認証に関連するリクエストをプライマリにプロキシするため、同じLDAP設定がセカンダリサイトにも適用されます。

ディザスターリカバリーのシナリオに備えて、各セカンダリサイトにセカンダリLDAPサーバーをセットアップする必要があります。この場合、セカンダリをプロモートすると、ユーザーはレプリカLDAPサービスを使用して認証できるようになります。そうでない場合、プライマリサイトに接続されているLDAPサービスが、プロモートされたセカンダリサイトで使用できない場合、ユーザーはHTTP Basic認証を使用して、セカンダリサイトでHTTP(s)経由でGit操作を実行できなくなります。ただし、LDAPサービスが利用できない場合に、アカウントが複数のログイン試行の失敗によってロックされない限り、ユーザーはSSHとパーソナルアクセストークンでGitを使用できます。

すべてのセカンダリサイトがLDAPサーバーを共有することも可能ですが、追加のレイテンシーが問題になる可能性があります。また、セカンダリサイトがプロモートされてプライマリサイトになる場合に、ディザスターリカバリーのシナリオでどのLDAPサーバーが利用可能になるかを検討してください。

LDAPサービスでのレプリケーションの設定方法については、LDAPサービスのドキュメントを確認してください。このプロセスは、使用するソフトウェアまたはサービスによって異なります。たとえば、OpenLDAPは、このレプリケーションドキュメントを提供しています。