Geo with Single Sign On (SSO)

Tier: 프리미엄, 얼티메이트 Offering: 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 이상에서는 기본적으로 프록시가 활성화됩니다.
프록시 사용이 불가능한 별도 URL입니다.

통합 URL로 SAML

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

프록시 사용이 가능한 별도 URL로 SAML

참고: 프록시를 사용할 때 SAML은 응용 프로그램이 여러 콜백 URL을 구성할 수 있는 경우에만 보조 사이트에서 로그인에 사용될 수 있습니다. 이 경우 확인하려면 SAML ID 제공자(IdP) 지원 팀에 문의하여 확인하십시오.

보조 사이트가 기본 사이트와 다른 external_url을 사용하는 경우 SAML ID 제공자(IdP)를 구성하여 보조 사이트의 SAML 콜백 URL을 허용해야 합니다. 예를 들어 Okta를 구성하는 경우:

Okta에 로그인.
Okta 관리 대시보드 > 응용 프로그램 > 응용 프로그램 이름 > 일반으로 이동합니다.
SAML 설정에서 편집을 선택합니다.
일반 설정에서 다음을 선택하여 SAML 설정으로 이동합니다.
SAML 설정 > 일반에서 단일 로그인 URL이 기본 사이트의 SAML 콜백 URL인지 확인합니다. 예를 들어 https://gitlab-primary.example.com/users/auth/saml/callback입니다. 그렇지 않은 경우 이 필드에 기본 사이트의 SAML 콜백 URL을 입력합니다.
고급 설정 표시를 선택합니다.
요청 가능한 다른 SSO URL에 보조 사이트의 SAML 콜백 URL을 입력합니다. 예를 들어 https://gitlab-secondary.example.com/users/auth/saml/callback입니다. 색인은 임의로 설정할 수 있습니다.
다음을 선택한 다음 완료를 선택합니다.

기본 사이트의 gitlab.rb에서 SAML 제공자 구성에서 assertion_consumer_service_url을 지정해서는 안됩니다. 예를 들어:

gitlab_rails['omniauth_providers'] = [
  {
    name: "saml",
    label: "Okta",
    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:EntityDescriptor>

gitlab-secondary.example.com을 가리키는 md:AssertionConsumerService 필드의 Location 속성을 확인할 수 있습니다.

SAML ID 제공자를 구성하여 보조 사이트의 SAML 콜백 URL을 허용한 후에는 기본 사이트 및 보조 사이트 모두 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 기본 인증을 사용하여 보조 사이트에서 Git 작업을 수행할 수 없습니다. 그러나 사용자는 여전히 SSH 및 개인 액세스 토큰을 사용하여 Git을 사용할 수 있습니다.

참고: 모든 보조 사이트가 LDAP 서버를 공유할 수 있지만 추가적인 지연 시간이 문제가 될 수 있습니다. 또한, 보조 사이트가 기본 사이트로 승격될 경우 재해 복구 시나리오에서 사용 가능한 LDAP 서버를 고려해야 합니다.

LDAP 서비스 설명서를 확인하여 사용 중인 소프트웨어나 서비스에 따라 복제 설정 방법에 대한 지침을 찾아보세요. 예를 들어, OpenLDAP은 이 복제 설명서를 제공합니다.

Geo with Single Sign On (SSO)

인스턴스 전체 SAML 구성

필수 조건

보조 사이트의 URL 유형 결정

통합 URL로 SAML

프록시 사용이 가능한 별도 URL로 SAML

별도 URL 및 프록시 비활성화 상태의 SAML

OpenID Connect

LDAP

도움말

기능 사용 가능성과 제품 평가판

도움받기