GitLab.com 그룹을 위한 SAML SSO

Tier: Premium, Ultimate Offering: GitLab.com

- GitLab 11.0에서 처음 소개되었습니다.

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

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

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

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

식별 공급자 설정하기

SAML 표준을 사용하므로 GitLab에서 다양한 식별 공급업체를 사용할 수 있습니다. 귀하의 식별 공급자에는 관련 문서가 있을 수 있습니다. 이 문서는 일반 SAML 문서일 수도 있고 GitLab을 대상으로 특별히 지정된 문서일 수도 있습니다.

귀하의 식별 공급자를 설정할 때, 공급자별 문서를 사용하여 일반적인 문제를 피하고 사용된 용어를 안내 받을 수 있습니다.

목록에 없는 식별 공급자의 경우, 귀하의 공급자가 요구하는 정보에 대한 추가 안내를 위해 아이디어 SAML 설정을 구성하는 인스턴스 SAML 노트를 참고할 수 있습니다.

GitLab은 단순 안내를 제공합니다.
SAML 앱의 구성에 관한 질문이 있으면 귀하의 식별 공급자 지원팀에 문의하십시오.

귀하의 식별 공급자 설정에 문제가 있으면 문제 해결 문서를 참조하십시오.

Azure

귀하의 식별 공급자로서 Azure를 사용하여 SSO를 설정하려면:

왼쪽 사이드바에서 검색 또는 이동하여 그룹을 찾습니다.
설정 > SAML SSO를 선택합니다.
이 페이지의 정보를 확인합니다.

Azure로 이동하여 응용 프로그램에 대한 SSO 구성 지침을 따릅니다. 다음은 GitLab 설정과 Azure 필드에 해당합니다.

GitLab 설정	Azure 필드
식별자	식별자 (엔터티 ID)
Assertion 소비자 서비스 URL	응답 URL (Assertion Consumer Service URL)
GitLab 단일 로그인 URL	로그인 URL
식별 공급자 단일 로그인 URL	로그인 URL
인증서 지문	Thumbprint

아래의 값을 설정해야 합니다.
- 고유 사용자 식별자 (이름 식별자)는 user.objectID여야 합니다.
- nameid-format은 persistent여야 합니다. 자세한 내용은 사용자 SAML 식별 관리를 참조하십시오.
- 이메일은 user.mail 또는 유사한 값이어야 합니다.
- 추가 클레임은 지원되는 속성을 참조하십시오.
고유한 GitLab 계정을 링크하려면 식별 공급자가 공급자 주도 호출이 설정되어 있는지 확인하십시오.
선택 사항. 그룹 동기화를 사용하는 경우, 필요한 속성과 일치하도록 그룹 클레임의 이름을 사용자화하십시오.

그룹을 위한 SAML SSO에서 Azure를 사용한 SCIM 프로비저닝 영상을 확인하십시오. 이 비디오에는 objectID 매핑이 오래되었습니다. 대신 SCIM 문서를 따르십시오.

자세한 내용은 구성 페이지 예시를 참조하십시오.

Google Workspace

귀하의 식별 공급자로서 Google Workspace를 사용하여 SSO를 설정하려면:

왼쪽 사이드바에서 검색 또는 이동하여 그룹을 찾습니다.
설정 > SAML SSO를 선택합니다.
이 페이지의 정보를 확인합니다.
Google이 식별 공급자로 SSO 설정하는 방법에 대한 지침을 따릅니다. 다음은 GitLab 설정과 Google Workspace 필드에 해당합니다.

GitLab 설정 Google Workspace 필드

식별자 엔터티 ID
Assertion 소비자 서비스 URL ACS URL
GitLab 단일 로그인 URL 시작 URL
식별 공급자 단일 로그인 URL SSO URL
Google Workspace은 SHA256 지문을 표시합니다. GitLab에서 SAML을 구성하기 위해 필요한 SHA1 지문을 가져오려면:
1. 인증서를 다운로드합니다.
2. 다음 명령을 실행합니다:
```
openssl x509 -noout -fingerprint -sha1 -inform pem -in "GoogleIDPCertificate-domain.com.pem"
```
다음 값을 설정해야 합니다.
- 기본 이메일에는 email을 입력해야 합니다.
- 이름에는 first_name을 입력해야 합니다.
- 성에는 last_name을 입력해야 합니다.
- Name ID format에는 EMAIL을 입력해야 합니다.
- NameID에는 기본 정보 > 기본 이메일을 입력해야 합니다.
  자세한 내용은 지원되는 속성을 참조하십시오.
고유한 GitLab 계정을 링크하려면 식별 공급자가 공급자 주도 호출이 설정되어 있는지 확인하십시오.

GitLab 설정	Google Workspace 필드
식별자	엔터티 ID
Assertion 소비자 서비스 URL	ACS URL
GitLab 단일 로그인 URL	시작 URL
식별 공급자 단일 로그인 URL	SSO URL

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

자세한 내용은 구성 페이지 예시를 참조하십시오.

Google Workspace 및 그룹 동기화 설정과 함께 SAML 구성 방법 영상을 확인하십시오.

Okta

왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
설정 > SAML SSO를 선택합니다.
이 페이지의 정보를 메모합니다.

Okta에서 SAML 애플리케이션 설정 지침을 따릅니다.

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

GitLab 설정	Okta 필드
식별자	Audience URI
Assertion 소비자 서비스 URL	Single sign-on URL
GitLab 단일 로그인 URL	Login page URL (Application Login Page 설정 하위)
Identity 공급자 단일 로그인 URL	Identity Provider Single Sign-On URL

Okta Single sign-on URL 필드 아래에서 Recipient URL 및 Destination URL로 사용 확인란을 선택합니다.
이러한 값을 설정합니다:
- 애플리케이션 사용자명(NameID): 사용자.getInternalProperty(“id”).
- Name ID 형식: Persistent. 자세한 정보는 사용자 SAML 신원 관리를 참조하십시오.
- 이메일: user.email 또는 유사한 값.
- 추가 Attribute Statements은 지원되는 속성을 참조하십시오.
기존 GitLab 계정을 링크하려면 공급자주도 호출(provider-initiated calls)로 설정되었는지 확인합니다.

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

Okta SAML 설정 및 SCIM 데모는 데모: Okta 그룹 SAML 및 SCIM 설정에서 확인할 수 있습니다.

더 많은 정보는 구성 예제 페이지를 참조하십시오.

OneLogin

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

왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
설정 > SAML SSO를 선택합니다.
이 페이지의 정보를 메모합니다.

OneLogin이 제공하는 일반 SAML 테스트 커넥터(고급)를 사용한다면, OneLogin SAML 테스트 커넥터를 사용해야 합니다. 다음 GitLab 설정이 OneLogin 필드에 해당합니다.

GitLab 설정	OneLogin 필드
식별자	Audiance
Assertion 소비자 서비스 URL	Recipient
Assertion 소비자 서비스 URL	ACS (Consumer) URL
Assertion 소비자 서비스 URL (이스케이프된 버전)	ACS (Consumer) URL Validator
GitLab 단일 로그인 URL	Login URL
Identity 공급자 단일 로그인 URL	SAML 2.0 Endpoint

NameID로 OneLogin ID를 사용합니다. 자세한 정보는 사용자 SAML 신원 관리를 참조하십시오.
필수 및 지원되는 속성을 구성합니다.
기존 GitLab 계정을 링크하려면 공급자주도 호출(provider-initiated calls)로 설정되었는지 확인합니다.

단언(Assertions) 구성

참고: 속성은 대소문자를 구분합니다. 최소한 다음 단언을 구성해야 합니다:

NameID.
이메일.

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

사용자의 이메일 주소는 이메일 또는 mail 속성이 될 수 있습니다.
사용자명은 사용자명 또는 별명 속성이 될 수 있습니다. 이 중 하나만 지정해야 합니다.

더 많은 정보는 올바르게 구성된 속성을 참조하십시오.

메타데이터 사용

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

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

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

식별 공급자 관리

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

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

식별 공급자 변경

다른 식별 공급자로 변경할 수 있습니다. 변경 프로세스 중에는 사용자가 SAML 그룹에 액세스할 수 없습니다. 이를 줄이기 위해 SSO 강제 적용을 사용할 수 있습니다.

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

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

이메일 도메인 변경

사용자를 새로운 이메일 도메인으로 마이그레이션하려면 사용자에게 다음을 알려야 합니다.

새 이메일을 사용자 계정의 주 이메일로 추가하고 확인합니다.
선택 사항. 계정에서 이전 이메일을 제거합니다.

NameID가 이메일 주소로 구성된 경우 사용자의 NameID를 변경합니다.

GitLab 구성

사용자 역할을 기본 멤버십 역할로 설정하는 능력은 GitLab 16.7에서 소개됨.

GitLab을 사용하여 식별 공급자를 구성하려면 인증에 사용할 GitLab을 구성해야 합니다.

왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
설정 > SAML SSO를 선택합니다.
다음을 완료합니다:
- 식별 공급자 단일 로그온 URL 필드에 식별 공급자의 SSO URL을 입력합니다.
- 인증서 지문 필드에 SAML 토큰 서명 인증서의 지문을 입력합니다.
기본 멤버십 역할 필드에서 새로운 사용자에 할당할 역할을 선택합니다. 기본 역할은 게스트입니다. 해당 역할은 그룹에 추가된 모든 사용자의 시작 역할이 됩니다.
- GitLab 13.3부터 그룹 소유자는 게스트 이외의 기본 멤버십 역할을 설정할 수 있습니다.
- GitLab 16.7부터 그룹 소유자는 사용자 지정 역할을 기본 멤버십 역할로 설정할 수 있습니다.
이 그룹에 대한 SAML 인증 활성화 확인란을 선택합니다.
선택 사항. 다음을 선택합니다:
- 이 그룹에 대한 웹 활동의 SSO 전용 인증 강제 적용.
- 이 그룹에 대한 Git 활동의 SSO 전용 인증 강제 적용. 자세한 내용은 SSO 강제 적용 문서를 참조하세요.
변경 사항 저장을 선택합니다.

참고: 인증서 지문 알고리즘은 SHA1이어야 합니다. (예: Google Workspace와 같은) 식별 공급자 구성 시 안전한 서명 알고리즘을 사용합니다.

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

사용자 액세스 및 관리

SAML 사용자 프로비저닝은 GitLab 13.7에서 소개됨.

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

사용자가 그룹 SSO로 로그인을 시도하면 GitLab은 다음을 기반으로 사용자를 찾거나 생성하려고 합니다.

일치하는 SAML 식별 정보를 가진 기존 사용자를 찾습니다. 사용자는 SCIM에 의해 계정이 생성되었거나 그룹의 SAML IdP로 이전에 로그인한 경우입니다.
동일한 이메일 주소를 가진 충돌하는 사용자가 없는 경우, 새로운 계정을 자동으로 만듭니다.
동일한 이메일 주소를 가진 충돌하는 사용자가 있는 경우, 사용자를 다음 작업이 가능하도록 다음과 같이
- 다른 이메일 주소로 새 계정을 만듭니다.
- SAML 식별 정보를 연결하려면 기존 계정으로 로그인합니다.

기존 GitLab.com 계정에 SAML 연결

기억하기 확인란은 GitLab 15.7에서 소개됨.

기존 GitLab.com 계정에 SAML을 연결하려면:

GitLab.com 계정에 로그인합니다. 비밀번호를 재설정 이 필요하면 수행합니다.
가입하려는 그룹의 GitLab 단일 로그온 URL을 찾아 방문합니다. 그룹 소유자는 그룹의 설정 > SAML SSO 페이지에서 이 URL을 찾을 수 있습니다. 사용자가 구성된 경우, 사용자는 식별 공급자에서 GitLab 앱에 연결할 수 있습니다.
선택 사항. 2주 동안 GitLab에 로그인 유지하려면 기억하기 확인란을 선택합니다. 더 자주 SAML 제공자로 다시 인증을 받을 수 있습니다.
승인을 선택합니다.
프롬프트가 표시되면 식별 공급자에서 자격 증명을 입력합니다.
그런 다음 GitLab.com으로 리디렉션되어 그룹에 액세스할 수 있어야 합니다. 앞으로 SAML을 사용하여 GitLab.com에 로그인할 수 있습니다.

사용자가 이미 그룹의 구성원인 경우, SAML 식별을 연결해도 사용자의 역할이 변경되지 않습니다.

차후 방문 시 SAML을 사용하여 GitLab.com에 로그인할 수 있어야하거나 직접 링크를 방문하여 로그인할 수 있어야 합니다. SSO 강제 적용 옵션이 켜져 있는 경우 식별 공급자를 통해 로그인하도록 리디렉션됩니다.

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

식별 공급자(Identity Provider)에 로그인합니다.
앱 목록에서 “GitLab.com” 앱을 선택하세요. (앱 이름은 식별 공급자의 관리자에 의해 설정됩니다.)
그러면 GitLab.com에 로그인되고 해당 그룹으로 리디렉션됩니다.

사용자 SAML ID 관리

GitLab 15.5에서 도입된 SAML API를 사용하여 SAML ID를 업데이트합니다.

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

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

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

각 사용자마다 고유해야 합니다.
절대 변경되지 않는 영구 값이어야 하며, 무작위로 생성된 고유한 사용자 ID 등이 될 수 있습니다.
후속 로그인 시 정확히 일치해야 하므로 대소문자가 바뀔 수 있는 사용자 입력에 의존하면 안 됩니다.

NameID는 이메일 주소나 사용자 이름이 아니어야 합니다. 왜냐하면:

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

NameID의 형식은 Persistent 여야 하지만, 이메일과 같은 필드를 사용하는 경우와 같이 다른 형식이 필요한 경우도 있습니다. Transient를 제외한 모든 형식을 사용할 수 있습니다.

사용자 NameID 변경

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

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

또는 사용자에게 SAML 계정을 다시 연결할 것을 요청할 수 있습니다.

관련 사용자에게 그들의 계정을 그룹에서 연결 해제할 것을 요청하세요.
관련 사용자에게 그들의 계정을 새 SAML 앱에 연결할 것을 요청하세요.

경고: 사용자가 SSO SAML을 사용하여 GitLab에 로그인한 후 NameID 값을 변경하면 구성이 손상되어 사용자가 GitLab 그룹에 로크될 수 있습니다.

특정 식별 공급자에 대한 권장 값 및 형식에 대한 자세한 정보는 식별 공급자 설정을 참조하세요.

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

GitLab 13.7에서 도입된 기능.
GitLab 16.7에서는 기업 사용자 설정만 구성하도록 변경되었습니다.

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

지원되는 사용자 속성

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

예시 SAML 응답

브라우저의 개발자 도구나 콘솔에서 base64로 인코딩된 형식으로 SAML 응답을 찾을 수 있습니다. 선택한 도구를 사용하여 정보를 XML로 변환하세요. 다음은 예시 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>

검증된 도메인으로 사용자 이메일 확인 우회

GitLab 15.4에 도입됨.

기본적으로 SAML 또는 SCIM으로 증설된 사용자는 신원을 확인하기 위해 확인 이메일을 받습니다. 대신, 사용자가 기업용 도메인 설정과 GitLab이 사용자 계정을 자동으로 확인하도록 설정할 수 있습니다. 사용자는 여전히 기업 사용자 환영 이메일을 받습니다. 확인은 다음 두 가지 모두 참인 경우 우회됩니다.

사용자가 SAML 또는 SCIM으로 증설됩니다.
사용자의 이메일 주소가 검증된 도메인에 속합니다.

사용자 액세스 차단

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

사용자를 다음에서 (순서대로) 제거합니다:
1. Identity 공급자의 사용자 데이터 저장소 또는 특정 앱의 사용자 목록.
2. GitLab.com 그룹.
기본 역할을 가진 그룹 동기화를 사용하여 그룹의 모든 리소스 액세스를 자동으로 차단하세요.

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

계정 연결 해제

사용자는 프로필 페이지에서 그룹에 대한 SAML 연결을 해제할 수 있습니다. 이 기능은 다음과 같은 경우에 유용합니다.

GitLab.com에 로그인할 수 없는 그룹을 더 이상 원하지 않을 때.
사용자의 SAML NameID가 변경되어 GitLab이 사용자를 더 이상 찾지 못할 때.

경고: 계정 연결 해제는 해당 사용자에게 할당된 모든 역할을 제거합니다. 사용자가 다시 계정을 연결하면 역할을 다시 할당해야 합니다.

그룹에는 최소한 하나의 소유자가 필요합니다. 사용하는 계정이 그룹의 유일한 소유자인 경우 계정을 연결 해제할 수 없습니다. 이 경우 다른 사용자를 그룹 소유자로 설정한 후 계정을 연결 해제할 수 있습니다. 예를 들어, MyOrg 계정을 연결 해제하려면:

왼쪽 사이드바에서 아바타를 선택합니다.
프로필 편집을 선택합니다.
왼쪽 사이드바에서 계정을 선택합니다.
서비스 로그인 섹션에서 연결된 계정 옆의 연결 해제를 선택합니다.

SSO 강제 실행

GitLab 11.8에 도입됨.
GitLab 11.11에서 개선됨으로 GitLab UI에서 지속적으로 강제 실행됨.
GitLab 13.8에서 개선됨으로 업데이트된 시간 초과 경험 제공.
GitLab 13.8에서 개선됨으로 그룹 소유자가 SSO를 거치지 않도록 허용.
GitLab 13.11에서 개선됨으로 이 설정이 활성화되어 있으면 Git에서 SSO 세션을 강제 사용.
GitLab 14.7에서 개선됨으로 GitLab.com의 CI/CD 작업에서의 Git 활동에 대한 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가 활성화된 경우.
사용자가 조직의 그룹 계층구조의 그룹 및 프로젝트에 액세스할 때 기존 SAML 신원이 있는 사용자. 사용자는 GitLab.com 자격 증명을 사용하여 SSO 로그인 없이 기타 그룹 및 프로젝트, 사용자 설정을 볼 수 있습니다.

사용자의 SAML 신원이 있는 경우 다음 중 하나 또는 둘 다 해당됩니다:

GitLab 그룹의 단일 로그인 URL을 사용하여 GitLab에 로그인한 경우.
SCIM을 통해 증설된 경우.

사용자가 매번 SSO를 통해 로그인하도록 요청받지 않습니다. GitLab은 사용자가 SSO를 통해 인증했는지를 확인합니다. 사용자가 마지막으로 지난 24시간 전에 로그인한 경우, GitLab은 사용자에게 다시 SSO를 통해 로그인하라는 요청을 표시합니다.

SSO가 다음과 같이 강제로 실행됩니다:

프로젝트/그룹 가시성	SSO 강제 실행 설정	신원이 있는 멤버	신원이 없는 멤버	비멤버 또는 로그인되지 않음
비공개	비활성화	강제 실행	강제 실행	강제 실행
비공개	활성화	강제 실행	강제 실행	강제 실행
공개	비활성화	강제 실행	강제 실행	강제 실행
공개	활성화	강제 실행	강제 실행	강제 실행

API 활동에 대한 유사한 SSO 요구 사항을 추가하는 데 관한 이슈가 있습니다.

웹 활동 강제용 SSO-ONLY

이 그룹의 웹 활동에 대해 SSO-전용 인증을 강제로 설정 옵션이 활성화되면:

모든 구성원은 기존 SAML 식별정보가 있는지 여부에 관계없이 GitLab 그룹의 단일 로그인 URL을 사용하여 그룹 리소스에 액세스해야 합니다.
사용자가 조직의 그룹 계층 구조에서 그룹 및 프로젝트에 액세스할 때 SSO가 강제됩니다. 사용자는 SSO 로그인 없이 다른 그룹 및 프로젝트를 볼 수 있습니다.
사용자는 수동으로 새 구성원으로 추가될 수 없습니다.
소유자 역할을 가진 사용자는 상위 그룹 설정을 변경하기 위해 표준 로그인 프로세스를 사용할 수 있습니다.
비구성원 또는 로그인하지 않은 사용자의 경우:
- 공개 그룹 리소스에 액세스할 때 SSO가 강제되지 않습니다.
- 비공개 그룹 리소스에 액세스할 때 SSO가 강제됩니다.
조직의 그룹 계층 구조 항목의 경우, 대시보드 가시성은 다음과 같습니다:
- To-Do List를 보는 경우 SSO가 강제됩니다. SSO 세션이 만료된 경우 할 일 항목이 숨겨지고 경고가 표시됩니다.
- 할당된 이슈 목록을 보는 경우 SSO가 강제됩니다. SSO 세션이 만료된 경우 이슈가 숨겨집니다. 이슈 414475는 이 동작을 변경하여 이슈를 표시하도록 제안합니다.
- 당신이 담당자이거나 검토가 요청된 병합 요청 목록을 보는 경우 SSO가 강제되지 않습니다. SSO 세션이 만료되었더라도 병합 요청을 볼 수 있습니다.

웹 활동을 위한 SSO 강제 실행이 활성화되면 다음과 같은 영향이 있습니다:

그룹에서 사용자는 프로젝트를 최상위 그룹 외부에서 공유할 수 없습니다. 프로젝트가 포크되더라도 마찬가지입니다.
CI/CD 작업에서 발생한 Git 활동은 SSO 확인이 강제되지 않습니다.
일반 사용자에게 매핑되지 않은 자격 증명(예: 프로젝트 및 그룹 액세스 토큰 및 배포 키)에 대해서도 SSO 확인이 강제되지 않습니다.
사용자는 의존성 프록시를 사용하여 이미지를 가져오기 전에 SSO로 로그인해야 합니다.
이 그룹의 Git 및 의존성 프록시 활동에 대해 SSO-전용 인증을 강제로 설정 옵션이 활성화되면 Git 활동과 관련된 API 엔드포인트에 SSO 강제가 적용됩니다. 예를 들어 브랜치, 커밋 또는 태그를 생성하거나 삭제하는 경우입니다. Git 활동이 SSH 및 HTTPS를 통해 이루어지는 경우, 사용자는 GitLab 리포지토리에 푸시 또는 풀하기 전에 적어도 하나의 SSO로 로그인된 활성 세션이 있어야 합니다.

웹 활동을 위한 SSO가 강제 실행될 때, 비-SSO 그룹 구성원은 즉시 액세스 권한을 상실하지 않습니다. 사용자가 다음과 같을 경우:

활성 세션이 있는 경우 신원 공급자 세션이 만료될 때까지 최대 24시간 동안 그룹에 계속 액세스할 수 있습니다.
로그아웃되었을 경우, 신원 공급자에서 제거된 후에는 그룹에 더 이상 액세스할 수 없습니다.

문제 해결

GitLab 및 신원 공급자 간의 다양한 SAML 용어를 일치시키기 어려운 경우:

신원 공급자의 문서를 확인하십시오. 그들이 사용하는 용어에 대한 정보를 얻으려면 그들의 예제 SAML 구성을 살펴보십시오.
자체 관리형 GitLab 인스턴스용 SAML SSO 문서를 확인하십시오. 자체 관리형 GitLab 인스턴스 SAML 구성 파일은 GitLab.com 파일보다 더 많은 옵션을 지원합니다. 자체 관리형 인스턴스 파일에 대한 정보는 다음에서 찾을 수 있습니다:
- 외부 OmniAuth SAML 문서
- ruby-saml 라이브러리.
제공업체의 XML 응답을 내부 테스트에 사용된 예제 XML과 비교하십시오.

기타 문제 해결 정보는 SAML 해결 방법 안내서를 참조하십시오.

GitLab.com 그룹을 위한 SAML SSO

식별 공급자 설정하기

Azure

Google Workspace

Okta

OneLogin

단언(Assertions) 구성

메타데이터 사용

식별 공급자 관리

식별 공급자 변경

이메일 도메인 변경

GitLab 구성

사용자 액세스 및 관리

기존 GitLab.com 계정에 SAML 연결

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

사용자 SAML ID 관리

사용자 NameID 변경

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

지원되는 사용자 속성

예시 SAML 응답

검증된 도메인으로 사용자 이메일 확인 우회

사용자 액세스 차단

계정 연결 해제

SSO 강제 실행

웹 활동 강제용 SSO-ONLY

관련 주제

문제 해결

도움말

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

도움받기