GitLab.com 그룹을 위한 SAML SSO

Tier: Premium, Ultimate Offering: GitLab.com

사용자는 SAML ID 공급자를 통해 GitLab에 로그인할 수 있습니다.

SCIM은 GitLab.com의 그룹과 사용자를 동기화합니다.

  • 사용자를 SCIM 앱에 추가하거나 제거할 때 SCIM은 사용자를 GitLab 그룹에서 추가하거나 제거합니다.
  • 사용자가 이미 그룹 멤버가 아닌 경우 사용자는 로그인 프로세스의 일부로 그룹에 추가됩니다.

SAML SSO를 최상위 그룹에만 구성할 수 있습니다.

ID 공급자 설정

SAML 표준을 사용하므로 GitLab과 다양한 ID 공급자를 사용할 수 있습니다. ID 공급자에는 관련 문서가 있을 수 있습니다. 이 문서는 지원되는 SAML 문서일 수도 있고 GitLab을 위해 특별히 대상으로 하는 경우도 있을 수 있습니다.

ID 공급자 설정 시에는 다음 공급자별 문서를 사용하여 일반적인 문제를 피하고 사용된 용어를 안내하는 데 도움을 받을 수 있습니다.

디렉터리에 없는 ID 공급자의 경우, 공급자가 요구하는 정보에 대한 추가 안내를 얻으려면 ID 공급자 구성을 위한 인스턴스 SAML 노트를 참조할 수 있습니다.

GitLab은 다음 안내를 제공합니다. SAML 앱을 구성하는 데 질문이 있으면 제공 업체의 지원팀에 문의하십시오.

ID 공급자 설정에 문제가 있는 경우 문제 해결 문서를 참조하십시오.

Azure

ID 공급자로서 Azure를 사용하여 SSO를 설정하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾으세요.
  2. 설정 > SAML SSO를 선택하세요.
  3. 이 페이지의 정보를 참고하세요.
  4. Azure로 이동하여 응용 프로그램에 대한 SSO 구성 지침을 따르십시오. 다음 GitLab 설정은 Azure 필드에 해당합니다.

    GitLab 설정 Azure 필드
    식별자(Identifier) 식별자 (Entity ID)
    Assertion 소비 서비스 URL 응답 URL (Assertion Consumer Service URL)
    GitLab 단일 서인-온 URL 로그인 URL
    ID 공급자 단일 서인-온 URL 로그인 URL
    인증서 지문 Thumbprint
  5. 다음 속성을 설정하십시오:
    • 고유 사용자 식별자(Name identifier)user.objectID로 설정합니다.
    • nameid-formatpersistent로 설정합니다. 자세한 내용은 사용자 SAML 식별자 관리를 참조하십시오.
    • 이메일user.mail 또는 유사한 값으로 설정합니다.
    • 추가 클레임지원되는 속성으로 설정하십시오.
  6. ID 공급자가 기존 GitLab 계정을 연결하기 위해 공급자에서 시작하는 호출이 설정되어 있는지 확인하십시오.

  7. 선택 사항입니다. 그룹 동기화를 사용하는 경우, 그룹 클레임의 이름을 요구 사항과 일치하도록 사용자 정의하십시오.

SCIM 프로비저닝에서 Azure를 사용하여 SSO 그룹 설정의 데모를 시청하세요. 이 비디오에서 objectID 매핑은 더 이상 사용되지 않습니다. 대신 SCIM 문서를 따르십시오.

추가 정보는 구성 예제 페이지를 참조하십시오.

Google Workspace

ID 공급자로서 Google Workspace를 설정하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾으세요.
  2. 설정 > SAML SSO를 선택하세요.
  3. 이 페이지의 정보를 참고하세요.
  4. ID 공급자로 Google과 SSO 설정에 대한 지침을 따르십시오. 다음 GitLab 설정은 Google Workspace 필드에 해당합니다.

    GitLab 설정 Google Workspace 필드
    식별자(Identifier) Entity ID
    Assertion 소비 서비스 URL ACS URL
    GitLab 단일 서인-온 URL 시작 URL
    ID 공급자 단일 서인-온 URL SSO URL
  5. Google Workspace에서 SHA256 지문이 표시됩니다. GitLab에서 SAML 구성에 필요한 SHA1 지문을 가져오려면:
    1. 인증서를 다운로드하십시오.
    2. 다음 명령을 실행하십시오:

      openssl x509 -noout -fingerprint -sha1 -inform pem -in "GoogleIDPCertificate-domain.com.pem"
      
  6. 다음 값을 설정하십시오:
    • 기본 이메일: email.
    • 이름: first_name.
    • : last_name.
    • 이름 식별자 형식: EMAIL.
    • NameID: 기본 정보 > 기본 이메일. 추가 정보는 지원되는 속성을 참조하십시오.
  7. ID 공급자가 기존 GitLab 계정을 연결하기 위해 공급자에서 시작하는 호출이 설정되어 있는지 확인하십시오.

GitLab SAML SSO 페이지에서 SAML 구성 확인을 선택할 때 NameID 형식을 persistent로 설정하는 것을 권장하는 경고를 무시하십시오.

추가 정보는 구성 예제 페이지를 참조하십시오.

Google Workspace와 SAML을 구성하고 그룹 동기화 설정의 데모를 확인하세요.

Okta

ID 공급자로서 Okta를 사용하여 SSO를 설정하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾으세요.
  2. 설정 > SAML SSO를 선택하세요.
  3. 이 페이지의 정보를 참고하세요.
  4. Okta에서 SAML 애플리케이션을 설정하는 지침을 따르십시오.

    다음 GitLab 설정은 Okta 필드에 해당합니다.

    GitLab 설정 Okta 필드
    식별자(Identifier) Audience URI
    Assertion 소비 서비스 URL 단일 로그인 URL
    GitLab 단일 서인-온 URL Login page URL (under Application Login Page settings)
    ID 공급자 단일 서인-온 URL Identity Provider Single Sign-On URL
  5. Okta의 단일 로그인 URL 필드에서 Use this for Recipient URL and Destination URL 확인란을 선택하세요.

  6. 다음 값을 설정하십시오:
    • 애플리케이션 사용자이름(NameID): Custom user.getInternalProperty("id").
    • Name ID 형식: Persistent. 자세한 내용은 사용자 SAML 식별자 관리를 참조하십시오.
    • 이메일: user.email 또는 유사한 값으로 설정하십시오.
    • 추가적인 속성 문장지원되는 속성을 참조하십시오.
  7. ID 공급자가 기존 GitLab 계정을 연결하기 위해 공급자에서 시작하는 호출이 설정되어 있는지 확인하십시오.

App Catalog에 있는 Okta GitLab 애플리케이션은 SCIM만 지원합니다. SAML 지원은 issue 216173에서 제안되었습니다.

Okta SAML 설정 및 SCIM을 포함한 데모를 보려면 데모: Okta 그룹 SAML 및 SCIM 설정을 확인하세요.

추가 정보는 구성 예제 페이지를 참조하십시오.

OneLogin

OneLogin은 자체 GitLab (SaaS) 애플리케이션을 지원합니다.

OneLogin을 식별 공급자로 설정하는 방법:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. Settings > SAML SSO를 선택합니다.
  3. 이 페이지의 정보를 확인합니다.
  4. 일반적인 SAML Test Connector (고급)를 사용하면 OneLogin SAML Test Connector를 사용해야 합니다. 다음 GitLab 설정이 OneLogin 필드에 해당합니다:

    GitLab 설정 OneLogin 필드
    Identifier Audience
    Assertion consumer service URL Recipient
    Assertion consumer service URL ACS (Consumer) URL
    Assertion consumer service URL(변환된 버전) ACS (Consumer) URL Validator
    GitLab single sign-on URL Login URL
    Identity provider single sign-on URL SAML 2.0 Endpoint
  5. NameID에는 OneLogin ID를 사용합니다. 자세한 정보는 사용자 SAML 식별 관리를 참조하세요.
  6. 필수 및 지원되는 속성을 구성합니다.
  7. 기존 GitLab 계정을 연결하기 위해 공급자에서 공급자 주도 호출(provider-initiated calls)이 설정되어 있는지 확인합니다.

단언(Assertion) 구성

note
속성은 대소문자를 구분합니다.

최소한 다음 단언을 구성해야 합니다:

  1. NameID.
  2. 이메일.

선택적으로, SAML 단언에 사용자 정보를 속성으로 GitLab에 전달할 수 있습니다.

  • 사용자의 이메일 주소는 이메일 또는 mail 속성일 수 있습니다.
  • 사용자 이름은 사용자 이름 또는 닉네임 속성일 수 있습니다. 이 중 하나만 지정해야 합니다.

더 많은 정보는 Self-Managed GitLab 인스턴스에 대한 사용 가능한 속성을 참조하세요.

메타데이터 사용

일부 식별 공급자를 구성하려면 GitLab 메타데이터 URL이 필요합니다. 이 URL을 찾으려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. Settings > SAML SSO를 선택합니다.
  3. 제공된 GitLab 메타데이터 URL을 복사합니다.
  4. 식별 공급자의 설명서를 확인하여 요청 시 메타데이터 URL을 붙여 넣습니다.

식별 공급자의 설명서를 확인하여 GitLab 메타데이터 URL을 지원하는지 확인하세요.

식별 공급자 관리

식별 공급자를 설정한 후에는 다음을 수행할 수 있습니다:

  • 식별 공급자 변경.
  • 이메일 도메인 변경.

식별 공급자 변경

다른 식별 공급자로 변경할 수 있습니다. 변경 프로세스 중에, 사용자는 SAML 그룹 중 어느 것에도 액세스할 수 없습니다. 이를 완화하려면 SSO 강제 적용(disable)할 수 있습니다.

식별 공급자를 변경하려면:

  1. 새 식별 공급자로 그룹을 구성합니다.
  2. 선택 사항. NameID가 동일하지 않은 경우 사용자의 NameID를 변경합니다.

이메일 도메인 변경

사용자에게 새 이메일로의 이전을 알리고 사용자는 다음을 수행할 수 있습니다:

  1. 새 이메일을 추가하여 이메일 주소를 계정의 기본 이메일로 설정하고 검증합니다.
  2. 선택 사항. 기존 이메일을 계정에서 제거합니다.

만약 NameID가 이메일 주소로 구성되어 있다면, 사용자의 NameID를 변경하세요.

GitLab 구성

  • 사용자 정의 역할을 기본 멤버십 역할로 설정할 수 있는 기능은 GitLab 16.7에서 도입되었습니다.

OneLogin과 GitLab을 연동한 후, 인증에 사용할 GitLab을 구성해야 합니다:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. Settings > SAML SSO를 선택합니다.
  3. 다음을 입력합니다:
    • Identity provider single sign-on URL 필드에 식별 공급자의 SSO URL을 입력합니다.
    • Certificate fingerprint 필드에 SAML 토큰 서명 인증서의 지문을 입력합니다.
  4. GitLab.com 그룹의 경우: Default membership role 필드에서 다음을 선택합니다:
    1. 새로운 사용자에게 할당할 역할.
    2. 그룹에 대한 매핑된 SAML 그룹의 구성이 설정되어 있지 않은 사용자에게 할당할 역할.
  5. Self-Managed 인스턴스의 그룹의 경우: Default membership role 필드에서 새로운 사용자에게 할당할 역할을 선택합니다. 기본 역할은 Guest입니다. 이 역할은 그룹에 추가된 모든 사용자의 시작 역할이 됩니다:
    • GitLab 16.7 이후, 그룹 소유자는 사용자 정의 역할을 설정할 수 있습니다.
    • GitLab 16.6 이전에는 그룹 소유자가 Guest 외의 역할을 기본 멤버십 역할로 설정할 수 있습니다.
  6. Enable SAML authentication for this group 확인란을 선택합니다.
  7. 선택 사항. 다음을 선택합니다:
    • 이 그룹에 대한 웹 활동에 대한 SSO 전용 인증 강제 적용.
    • 이 그룹에 대한 Git 활동에 대한 SSO 전용 인증 강제 적용. 자세한 정보는 SSO 강제 적용 문서를 참조하세요.
  8. Save changes를 선택합니다.
note
인증서 지문 알고리즘은 SHA1이어야 합니다. 식별 공급자(예: Google Workspace)를 구성할 때 안전한 서명 알고리즘을 사용하세요.

GitLab을 구성하는 데 문제가 있는 경우, 문제 해결 문서를 참조하세요.

사용자 액세스 및 관리

그룹 SSO가 구성되고 활성화된 후, 사용자는 식별 공급자 대시보드를 통해 GitLab.com 그룹에 액세스할 수 있습니다. SCIM이 구성된 경우, SCIM 페이지에서 사용자 액세스를 참조하세요.

사용자가 그룹 SSO로 로그인을 시도하면 GitLab은 다음을 기반으로 사용자를 찾거나 만듭니다:

  • 동일한 SAML 식별 정보를 가진 기존 사용자 찾기. 이는 사용자가 SCIM을 통해 계정이 생성되었거나 이전에 그룹의 SAML IdP를 통해 로그인한 경우입니다.
  • 동일한 이메일 주소를 가진 충돌하는 사용자가 없는 경우, 계정을 자동으로 만듭니다.
  • 동일한 이메일 주소를 가진 충돌하는 사용자가 있는 경우, 사용자를 다음 작업을 수행할 수 있도록 로그인 페이지로 리디렉션합니다:
    • 다른 이메일 주소로 새 계정을 만듭니다.
    • SAML 식별 정보를 연결하려면 기존 계정에 로그인합니다.

기존 GitLab.com 계정에 SAML 연결

  • Remember me 확인란은 GitLab 15.7부터 도입되었습니다.

기존 GitLab.com 계정에 SAML을 연결하려면 다음을 수행하세요:

  1. GitLab.com 계정에 로그인합니다. 필요한 경우 비밀번호를 재설정합니다.
  2. 가입하고 있는 그룹의 설정 > SAML SSO 페이지에서 GitLab 단일 로그인 URL을 찾아 방문합니다. 로그인 URL이 구성되어 있으면 사용자는 ID 공급자에서 GitLab 앱에 연결할 수 있습니다.
  3. 선택 사항. 2주 동안 GitLab에 로그인 유지하려면 Remember me 확인란을 선택합니다. SAML 공급자를 통해 자주 다시 인증을 받을 수 있습니다.
  4. 승인을 선택합니다.
  5. 프롬프트가 나오면 ID 공급자에서 자격 증명을 입력합니다.
  6. 그럼 GitLab.com으로 리디렉션되어 이제 해당 그룹에 액세스할 수 있어야 합니다. 앞으로는 SAML을 사용하여 GitLab.com에 로그인할 수 있습니다.

그룹의 구성원이 이미 해당 그룹의 구성원인 경우 SAML ID를 연결해도 역할이 변경되지 않습니다.

재방문 시 SAML을 사용하여 GitLab.com에 로그인하거나 직접 링크를 방문하여 로그인할 수 있어야 합니다. SSO 강제 실행 옵션이 활성화된 경우 ID 공급자를 통해 로그인하도록 리디렉션됩니다.

SAML을 사용하여 GitLab.com에 로그인

  1. ID 공급자에 로그인합니다.
  2. 앱 디렉터리에서 “GitLab.com”을 선택합니다. (이름은 ID 공급자의 관리자가 설정합니다.)
  3. 그럼 GitLab.com에 로그인되고 해당 그룹으로 리디렉션됩니다.

사용자 SAML ID 관리

  • SAML API를 사용한 SAML ID 업데이트는 GitLab 15.5에서 도입되었습니다.

GitLab.com은 사용자를 식별하기 위해 SAML NameID를 사용합니다. NameID는 다음과 같습니다:

  • SAML 응답에 필수 필드입니다.
  • 대소문자를 구분합니다.

NameID는 다음과 같아야 합니다:

  • 각 사용자마다 고유해야 합니다.
  • 결코 변경되지 않는 지속적인 값이어야 하며, 예를 들어 임의로 생성된 고유한 사용자 ID 등입니다.
  • 후속 로그인 시 정확히 일치해야 하므로 대문자와 소문자 사이에 변경될 수 있는 사용자 입력에 의존해서는 안 됩니다.

NameID는 이메일 주소나 사용자 이름이어서는 안 되는데, 그 이유는 다음과 같습니다:

  • 이메일 주소와 사용자 이름은 시간이 지남에 따라 변경될 수 있는 가능성이 높습니다. 예를 들어 사람의 이름이 변경될 때 등.
  • 이메일 주소는 대소문자를 구분하지 않으므로 사용자가 로그인할 수 없는 문제가 발생할 수 있습니다.

NameID 형식은 Persistent여야 하며, 필요에 따라 이메일과 같은 다른 형식을 사용할 수 있습니다. Transient를 제외한 어떤 형식이든 사용할 수 있습니다.

사용자 NameID 변경

그룹 소유자는 SAML API를 사용하여 그룹 구성원의 NameID를 변경하고 SAML ID를 업데이트할 수 있습니다.

SCIM이 구성되어 있는 경우 그룹 소유자는 SCIM API를 사용하여 SCIM ID를 업데이트할 수 있습니다.

또는 사용자에게 새로운 SAML 앱에 연결하도록 요청할 수 있습니다.

  1. 해당 사용자에게 그룹에서 계정 해제를 요청합니다.
  2. 해당 사용자에게 기존 SAML 앱에 계정 연결을 요청합니다.
caution
사용자가 SSO SAML을 사용하여 GitLab에 로그인한 후 NameID 값을 변경하면 구성이 손상되어 사용자가 GitLab 그룹에 로그인할 수 없을 수 있습니다.

특정 ID 공급자의 권장 값 및 형식에 대한 자세한 정보는 ID 공급자 설정를 참조하십시오.

SAML 응답에서 기업 사용자 설정 구성

  • GitLab 16.7에서 기존 사용자 설정만 구성하도록 변경되었습니다.

GitLab은 SAML 응답 값에 기초하여 특정 사용자 특성을 설정할 수 있습니다. 기업 사용자 인 경우 SAML 응답 값에서 기존 사용자의 특성이 업데이트됩니다.

지원되는 사용자 특성

  • can_create_group - 기업 사용자가 새로운 최상위 그룹을 만들 수 있는지를 나타내는 true 또는 false입니다. 기본값은 true입니다.
  • projects_limit - 기업 사용자가 생성할 수 있는 개인 프로젝트의 총 수입니다. 값이 0이면 사용자는 개인 네임스페이스에서 새 프로젝트를 만들 수 없습니다. 기본값은 100000입니다.

예제 SAML 응답

브라우저의 개발자 도구나 콘솔에서 base64로 인코딩된 형식으로 SAML 응답을 찾을 수 있습니다. 이 정보를 XML 형식으로 변환하려면 선택한 base64 디코딩 도구를 사용하십시오. 다음은 SAML 응답의 예제입니다.

   <saml2:AttributeStatement>
      <saml2:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
         <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">user.email</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="username" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">user.nickName</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="first_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
         <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">user.firstName</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="last_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
         <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">user.lastName</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="can_create_group" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
         <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">true</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="projects_limit" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
         <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">10</saml2:AttributeValue>
      </saml2:Attribute>
   </saml2:AttributeStatement>

확인된 도메인으로 사용자 이메일 확인 바이패스

기본적으로 SAML 또는 SCIM으로 프로비저닝된 사용자는 신원을 확인하기 위해 확인 이메일을 받습니다. 대신, 사용자 정의 도메인으로 GitLab을 구성하면 GitLab이 자동으로 사용자 계정을 확인합니다. 사용자는 여전히 enterprise 사용자 환영 이메일을 받습니다. 확인이 바이패스되는 경우:

  • 사용자가 SAML 또는 SCIM으로 프로비저닝됨.
  • 사용자의 이메일 주소가 확인된 도메인에 속함.

사용자 액세스 차단

SAML SSO만 구성된 경우 그룹에서 사용자의 액세스를 철회하려면 다음 중 하나를 수행하세요:

  • 사용자를 (순서대로) 다음에서 제거합니다.
    1. Identity 공급자의 사용자 데이터 리포지터리 또는 특정 앱의 사용자 디렉터리.
    2. GitLab.com 그룹.
  • 그룹 최상위 수준에서 그룹 동기화를 사용하여 기본 역할을 최소한의 액세스로 설정하면 그룹 내 모든 리소스의 액세스가 자동으로 차단됩니다.

SCIM을 사용하는 경우 사용자의 그룹 액세스를 철회하려면 액세스 제거를 참조하십시오.

계정 연결 해제

사용자는 프로필 페이지에서 그룹의 SAML을 연결해제할 수 있습니다. 이것은 다음과 같은 경우에 도움이 될 수 있습니다:

  • 특정 그룹이 GitLab.com에 로그인할 수 없도록 하고 싶을 때.
  • 사용자의 SAML NameID가 변경되어 GitLab에서 사용자를 더 이상 찾을 수 없을 때.
caution
계정 연결 해제는 해당 그룹에서 할당받은 모든 역할을 제거합니다. 사용자가 다시 계정을 연결하면 역할을 다시 할당해야 합니다.

그룹에는 적어도 하나의 소유자가 필요합니다. 계정이 그룹에서 유일한 소유자인 경우에는 계정을 연결 해제할 수 없습니다. 그 경우에 다른 사용자를 그룹 소유자로 설정한 다음 계정을 연결 해제할 수 있습니다.

예를 들어, MyOrg 계정을 연결 해제하려면:

  1. 왼쪽 사이드바에서 아바타를 선택합니다.
  2. 프로필 편집을 선택합니다.
  3. 왼쪽 사이드바에서 계정을 선택합니다.
  4. Service sign-in 섹션에서 연결된 계정 옆의 연결 해제를 선택합니다.

SSO 집행

  • GitLab 15.5에서 개선되었습니다.
  • SSO 집행이 활성화되지 않은 상태에서도 투명한 집행을 포함한 피처 플래그인 transparent_sso_enforcement개선되었습니다. GitLab.com에서 비활성화됨.
  • GitLab 15.8에서 개선되어 GitLab.com에서 기본적으로 투명한 SSO가 활성화됐습니다.
  • GitLab 15.10에서 일반적으로 이용 가능해졌습니다. 피처 플래그 transparent_sso_enforcement가 제거되었습니다.

GitLab.com에서 SSO는 다음과 같이 집행됩니다:

  • SAML SSO가 활성화된 경우.
  • 사용자의 GitLab.com 자격 증명을 사용하여 조직 그룹 계층 구조의 그룹 및 프로젝트에 액세스할 때 기존 SAML 신원을 가진 사용자를 위해. 사용자는 SAML SSO를 통해 로그인하지 않고도 조직 외부의 다른 그룹 및 프로젝트 및 사용자 설정을 볼 수 있습니다.

사용자는 다음 중 하나 이상의 항목이 사실인 경우에 SAML 신원을 가집니다:

  • GitLab 그룹의 단일 로그인 URL을 사용하여 GitLab에 로그인함.
  • SCIM을 통해 프로비저닝됨.

사용자는 매번 SSO를 통해 로그인하라는 메시지를 받지 않습니다. GitLab은 사용자가 SSO를 통해 인증했는지 확인합니다. 사용자가 마지막으로 24시간 이상 전에 로그인한 경우 GitLab은 사용자에게 다시 SSO를 통해 로그인하라는 메시지를 보냅니다.

SSO는 다음과 같이 집행됩니다:

프로젝트/그룹 가시성 SSO 집행 설정 신원이 있는 멤버 신원이 없는 멤버 비멤버 또는 로그인하지 않은 경우
비공개 꺼짐 집행됨 집행되지 않음 집행되지 않음
비공개 켜짐 집행됨 집행됨 집행되지 않음
공개 꺼짐 집행됨 집행되지 않음 집행되지 않음
공개 켜짐 집행됨 집행됨 집행되지 않음

유사한 SSO 요구를 API 활동에 추가하기 위한 이슈가 존재합니다.

웹 활동에 대한 SSO 전용 집행

이 그룹에 대해 웹 활동에 대한 SSO 전용 인증을 강제하기 옵션이 활성화된 경우:

  • 모든 멤버는 기존 SAML 신원 여부에 관계없이 그룹 리소스에 액세스하기 위해 사용자 그룹의 단일 로그인 URL을 사용해야 합니다.
  • 사용자는 조직 그룹 계층 구조의 그룹 및 프로젝트에 액세스할 때 SSO가 집행됩니다. 사용자는 SAML SSO를 통해 로그인하지 않고도 조직 외부의 다른 그룹 및 프로젝트를 볼 수 있습니다.
  • 사용자는 매뉴얼으로 새로운 멤버로 추가될 수 없습니다.
  • 소유자 역할을 가진 사용자는 최상위 그룹 설정을 변경하기 위해 표준 로그인 프로세스를 사용할 수 있습니다.
  • 비멤버 또는 로그인하지 않은 경우:
    • SSO는 공개 그룹 리소스에 액세스할 때 집행되지 않습니다.
    • SSO는 비공개 그룹 리소스에 액세스할 때 집행됩니다.
  • 조직 그룹 계층 구조의 항목에 대한 대시보드 가시성은 다음과 같습니다:
    • 할 일 디렉터리을 보는 경우 SSO가 집행됩니다. SSO 세션이 만료됐을 경우 할 일 항목이 숨겨지고 경고가 표시됩니다.
    • 할당된 이슈 디렉터리을 보는 경우 SSO가 집행됩니다. SSO 세션이 만료됐을 경우 이슈가 숨겨집니다. Issue 414475에서 이 동작을 변경하여 이슈를 표시하도록 제안했습니다.
    • Merge Request 디렉터리을 보는 경우 SSO가 집행되지 않습니다. SSO 세션이 만료됐을 경우에도 Merge Request을 볼 수 있습니다.

웹 활동에 대한 SSO 집행이 활성화된 경우 다음과 같은 효과가 있습니다:

  • 그룹 내에서 사용자는 프로젝트를 최상위 그룹 외부로 공유할 수 없습니다.
  • CI/CD 작업에서 발생한 Git 활동에는 SSO 확인이 집행되지 않습니다.
  • 일반 사용자에 연결되지 않은 자격증명(예: 프로젝트 및 그룹 액세스 토큰 및 배포 키)에는 SSO 확인이 집행되지 않습니다.
  • 사용자는 의존성 프록시를 사용하여 이미지를 검색하기 전에 SSO를 통해 로그인해야 합니다.
  • 이 그룹에 대해 Git 및 의존성 프록시 활동에 대한 SSO 전용 인증을 강제하기 옵션이 활성화된 경우, Git 활동을 포함하는 API 엔드포인트는 모두 SSO 집행이 됩니다. 예를 들어 브랜치, 커밋 또는 태그를 만들거나 삭제하는 경우입니다. Git 활동은 SSH 및 HTTPS를 통한 GitLab 리포지터리의 푸시 및 풀을 하기 전에 최소한 하나의 SSO로 활성 세션을 가져야 합니다. 활성 세션은 다른 장치에서 가능합니다.

웹 활동에 대한 SSO 집행이 활성화된 경우, SSO 그룹 멤버는 즉시 액세스 권한을 상실하지 않습니다. 사용자가:

  • 활성 세션이 있는 경우, 식별 공급자 세션이 만료될 때까지 최대 24시간 동안 그룹에 액세스할 수 있습니다.
  • 로그아웃되면 식별 공급자에서 제거된 후 그룹에 액세스할 수 없습니다.

관련 주제

문제 해결

GitLab와 ID 공급자 간의 다양한 SAML 용어를 일치시키는 데 어려움을 겪는 경우:

  1. ID 공급자의 문서를 확인하세요. 사용하는 용어에 대한 정보는 예제 SAML 구성을 살펴보세요.
  2. Self-Managed형 GitLab 인스턴스용 SAML SSO 문서를 확인하세요. Self-Managed형 GitLab 인스턴스의 SAML 구성 파일은 GitLab.com 파일보다 더 많은 옵션을 지원합니다. 다음에서 Self-Managed형 인스턴스 파일에 대한 정보를 찾을 수 있습니다:
  3. 제공자로부터의 XML 응답을 내부 테스트에 사용된 예제 XML과 비교하세요.

기타 문제 해결 정보는 SAML 문제 해결 가이드를 참조하세요.