Geo with Single Sign On (SSO)

Tier: Premium, Ultimate Offering: Self-managed

이 문서에서는 Geo 전용 SSO 고려사항 및 구성에 대해서만 논의합니다. 일반 인증에 대한 자세한 내용은 GitLab 인증 및 권한 부여를 참조하세요.

인스턴스 전체 SAML 구성

전제 조건

인스턴스 전체 SAML이 기본 Geo 사이트에서 작동해야 합니다.

SAML은 기본 사이트에서만 구성합니다. 보조 사이트의 gitlab_rails['omniauth_providers']gitlab.rb에 구성해도 효과가 없습니다. 보조 사이트는 기본 사이트에 구성된 SAML 공급자를 통해 인증됩니다. 보조 사이트의 URL 형식에 따라 기본 사이트에서 추가 구성이 필요할 수 있습니다.

보조 사이트에서 사용하는 URL 유형 결정

인스턴스 전체 SAML을 구성하는 방법은 보조 사이트 구성에 따라 다릅니다. 보조 사이트가 다음 중 하나를 사용하는지 확인하세요:

  • 통합 URL: 즉, external_url이 기본 사이트의 external_url과 정확히 일치합니다.
  • 프록시가 활성화된 개별 URL. 프록시는 GitLab 15.1 이상에서 기본적으로 활성화되어 있습니다.
  • 프록시가 비활성화된 개별 URL.

통합 URL로 SAML 사용

기본 사이트에서 SAML을 올바르게 구성했다면, 추가 구성 없이 보조 사이트에서도 작동해야 합니다.

프록시가 활성화된 개별 URL로 SAML 사용

note
프록시가 활성화된 경우, SAML Identity Provider (IdP)가 여러 콜백 URL을 구성할 수 있도록 허용해야 보조 사이트에 로그인하는 데 SAML을 사용할 수 있습니다. 이 경우를 확인하려면 IdP 제공업체 지원팀에 문의하세요.

보조 사이트가 기본 사이트와 다른 external_url을 사용하면, 보조 사이트의 SAML 콜백 URL을 허용하도록 SAML Identity Provider (IdP)를 구성해야 합니다. 예를 들어, Okta를 구성하려면:

  1. Okta에 로그인합니다.
  2. Okta 관리 대시보드 > 응용 프로그램 > 앱 이름 > 일반으로 이동합니다.
  3. SAML 설정에서 편집을 선택합니다.
  4. 일반 설정에서 다음을 선택하여 SAML 설정으로 이동합니다.
  5. SAML 설정 > 일반에서 단일 로그인 URL이 기본 사이트의 SAML 콜백 URL인지 확인합니다. 예: https://gitlab-primary.example.com/users/auth/saml/callback. 그렇지 않은 경우 이 필드에 기본 사이트의 SAML 콜백 URL을 입력하세요.
  6. 고급 설정 표시를 선택합니다.
  7. 기타 요청 가능한 SSO URL에 보조 사이트의 SAML 콜백 URL을 입력합니다. 예: https://gitlab-secondary.example.com/users/auth/saml/callback. Index를 아무 값으로 설정할 수 있습니다.
  8. 다음을 선택한 다음 마침을 선택합니다.

기본 사이트의 gitlab.rb에서 SAML 공급자 구성의 gitlab_rails['omniauth_providers']assertion_consumer_service_url을 지정해서는 안 됩니다. 예:

gitlab_rails['omniauth_providers'] = [  
  {  
    name: "saml",  
    label: "Okta", # 로그인 버튼에 대한 선택적 레이블, 기본값은 "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"  
    }  
  }  
]  

이 구성은 다음을 유발합니다:

  • 두 사이트 모두 /users/auth/saml/callback을 권한 부여 소비자 서비스(ACS) URL로 사용합니다.
  • 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 (OIDC) OmniAuth 공급자를 사용하는 경우, 대부분의 경우 문제 없이 작동해야 합니다:

  • 통합 URL로 OIDC: 주 사이트에서 OIDC를 올바르게 구성한 경우, 추가 구성 없이도 보조 사이트에서 작동해야 합니다.
  • 프록시가 비활성화된 별도의 URL로 OIDC: 주 사이트에서 OIDC를 올바르게 구성한 경우, 추가 구성 없이도 보조 사이트에서 작동해야 합니다.
  • 프록시가 활성화된 별도의 URL로 OIDC: 프록시가 활성화된 별도의 URL을 가진 Geo는 OpenID Connect를 지원하지 않습니다. 자세한 내용은 문제 396745를 참조하세요.

LDAP

주 사이트에서 LDAP를 사용하는 경우, 각 보조 사이트에서 보조 LDAP 서버를 설정해야 합니다. 그렇지 않으면 사용자는 HTTP 기본 인증을 사용하여 보조 사이트에서 HTTP(s)를 통한 Git 작업을 수행할 수 없습니다. 그러나 사용자는 여전히 SSH 및 개인 액세스 토큰을 사용하여 Git을 사용할 수 있습니다.

참고: 모든 보조 사이트가 LDAP 서버를 공유하는 것이 가능하지만, 추가 지연이 문제를 일으킬 수 있습니다. 또한, 보조 사이트가 사이트로 승격되는 경우 재해 복구 시 어떤 LDAP 서버를 사용할 수 있는지를 고려하세요.

LDAP 서비스에서 복제를 설정하는 방법에 대한 지침을 확인하세요. 프로세스는 사용되는 소프트웨어나 서비스에 따라 다릅니다. 예를 들어, OpenLDAP는 이 복제 문서를 제공합니다.