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을 위해 특별히 대상화된 문서일 수 있습니다.

신원 공급자 설정 시, 일반적인 문제를 피하고 사용된 용어에 대한 안내를 위해 다음 공급자별 문서를 참조하세요.

리스트되지 않은 식별 공급자는 식별 공급자 설정 페이지를 참조하여 공급자가 요구할 수 있는 정보에 대한 추가 지침을 얻을 수 있습니다.

GitLab은 다음 안내 정보만 제공합니다. SAML 앱 설정에 대한 질문이 있으면 공급자 지원팀에 문의하십시오.

식별 공급자 설정에 문제가 있는 경우 문제 해결 문서를 참조하세요.

Azure

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

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

Azure로 이동하여 애플리케이션에 대한 SSO 구성 지침을 따릅니다. 다음 GitLab 설정은 Azure 필드와 일치합니다.

GitLab 설정	Azure 필드
식별자(Identifier)	식별자(엔터티 ID)
단언 컨슈머 서비스 URL	응답 URL(단언 컨슈머 서비스 URL)
GitLab 단일 로그인 URL	로그인 URL
IdP(SSO) 단일 로그인 URL	로그인 URL
인증서 지문	지문(Thumbprint)

다음과 같이 다음 속성을 설정해야 합니다:
- 고유 사용자 식별자(이름 식별자)를 user.objectID로 설정합니다.
- nameid-format을 persistent로 설정합니다. 자세한 정보는 사용자 SAML 식별 관리 참조.
- 이메일을 user.mail 또는 유사한 값으로 설정합니다.
- 추가되는 클레임에 대한 지원되는 속성을 확인합니다.
기존 GitLab 계정을 연결하기 위해 신원 공급자가 제공자 주도 호출을 수행하도록 설정해야 합니다.
선택 사항. 그룹 동기화를 사용하는 경우, 그룹 클레임의 이름을 요구되는 속성과 일치하도록 사용자화하세요.

그룹용 SCIM 프로비저닝을 사용하여 Azure에서 SAML SSO 설정을(를) 시청하세요. 이 비디오에서는 이제는 사용되지 않는 objectID 매핑을 따르지 마십시오. 대신 SCIM 문서를 참조하세요.

추가 정보는 예제 구성 페이지를 참조하세요.

Google Workspace

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

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

GitLab 설정 Google Workspace 필드

식별자(Identifier) 엔터티 ID
단언 컨슈머 서비스 URL ACS URL
GitLab 단일 로그인 URL 시작 URL
IdP(SSO) 단일 로그인 URL SSO URL
Google Workspace는 SHA256 지문을 표시합니다. GitLab에서 필요로 하는 SHA1 지문을 검색하려면 다음 단계를 따르세요:
1. 인증서를 다운로드합니다.
2. 다음 명령을 실행합니다:
```
openssl x509 -noout -fingerprint -sha1 -inform pem -in "GoogleIDPCertificate-domain.com.pem"
```
다음 값을 설정합니다:
- 기본 이메일에 email을 설정합니다.
- 이름에 first_name을 설정합니다.
- 성에 last_name을 설정합니다.
- 이름 ID 형식에 EMAIL을 설정합니다.
- NameID에 기본 정보 > 기본 이메일을 설정합니다. 자세한 정보는 지원되는 속성을 참조하세요.
기존 GitLab 계정을 연결하기 위해 신원 공급자가 제공자 주도 호출을 수행하도록 설정해야 합니다.

GitLab 설정	Google Workspace 필드
식별자(Identifier)	엔터티 ID
단언 컨슈머 서비스 URL	ACS URL
GitLab 단일 로그인 URL	시작 URL
IdP(SSO) 단일 로그인 URL	SSO URL

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

추가 정보는 예제 구성 페이지를 참조하세요.

Google Workspaces에서 SAML을 구성하고 그룹 동기화 설정을(를) 시청하세요.

Okta

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

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

Okta에서 SAML 앱 설정 지침을 따릅니다.

다음 GitLab 설정은 Okta 필드와 일치합니다.

GitLab 설정	Okta 필드
식별자(Identifier)	Audience URI
단언 컨슈머 서비스 URL	단일 로그인 URL
GitLab 단일 로그인 URL	로그인 페이지 URL(애플리케이션 로그인 페이지 설정 아래)
IdP(SSO) 단일 로그인 URL	IdP(SSO) 단일 로그인 URL

Okta 단일 로그인 URL 필드 아래에서 받는 사람 URL 및 대상 URL에 사용 확인란을 선택합니다.
다음 값을 설정합니다:
- 애플리케이션 사용자 이름(이름 ID): Custom user.getInternalProperty("id").
- Name ID Format: Persistent. 자세한 정보는 사용자 SAML 식별 관리를 참조하세요.
- email: user.email 또는 유사한 값으로 설정합니다.
- 추가되는 클레임에 대한 지원되는 속성을 확인합니다.
기존 GitLab 계정을 연결하기 위해 신원 공급자가 제공자 주도 호출을 수행하도록 설정해야 합니다.

앱 카탈로그에서 제공하는 Okta GitLab 앱은 SCIM만 지원합니다. SAML 지원은 이슈 216173에서 제안되었습니다.

Okta SAML 설정 및 SCIM을 포함한 데모: Okta 그룹 SAML 및 SCIM 설정을(를) 시청하세요.

추가 정보는 예제 구성 페이지를 참조하세요.

OneLogin

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

OneLogin을 ID 공급자로 설정하려면:

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

OneLogin 제네릭 SAML 테스트 커넥터(고급)를 사용한다면 OneLogin SAML 테스트 커넥터를 사용해야 합니다. 다음 GitLab 설정이 OneLogin 필드에 해당합니다:

| GitLab 설정                                       | OneLogin 필드               |
| ------------------------------------------------- | ---------------------------- |
| **식별자**                                         | **수용자**                    |
| **주장 소비자 서비스 URL**                          | **수취인**                    |
| **주장 소비자 서비스 URL**                          | **ACS(Consumer) URL**         |
| **주장 소비자 서비스 URL(이스케이프된 버전)**       | **ACS(Consumer) URL Validator** |
| **GitLab 단일 로그인 URL**                        | **로그인 URL**               |
| **ID 공급자 단일 로그인 URL**                      | **SAML 2.0 엔드포인트**       |

NameID에 OneLogin ID를 사용합니다. 자세한 내용은 사용자 SAML 식별 관리를 참조하세요.
필수 및 지원 속성을 구성합니다.
기존 GitLab 계정을 링크하기 위해 ID 공급자가 공급자 주도 호출이 설정되어 있는지 확인합니다.

주장 구성

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

최소한 다음과 같은 주장을 구성해야 합니다:

NameID.
이메일.

원하는 경우 SAML 주장의 사용자 정보를 GitLab에 속성으로 전달할 수 있습니다.

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

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

메타데이터 사용

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

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

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

ID 공급자 관리

ID 공급자를 설정한 후 다음을 수행할 수 있습니다:

ID 공급자 변경.
이메일 도메인 변경.

ID 공급자 변경

다른 ID 공급자로 변경할 수 있습니다. 변경 프로세스 동안 사용자는 SAML 그룹에 액세스할 수 없습니다. 이를 완화하기 위해 SSO 강제 적용을 비활성화할 수 있습니다.

ID 공급자를 변경하려면:

새 ID 공급자로 그룹을 구성합니다.
선택 사항. NameID가 동일하지 않은 경우 사용자의 NameID 변경을 수행하세요.

이메일 도메인 변경

사용자를 새로운 이메일 도메인으로 이전하려면 사용자에게 다음을 알려야 합니다:

새 이메일을 추가하여 계정의 기본 이메일로 만들고 확인합니다.
선택 사항. 이전 이메일을 계정에서 제거합니다.

NameID가 이메일 주소로 구성된 경우 사용자의 NameID 변경을 수행하세요.

GitLab 구성

사용자 지정 역할을 기본 멤버십 역할로 설정하는 기능은 GitLab 16.7에서 소개되었습니다.

OneLogin을 GitLab과 사용하도록 구성한 후 GitLab을 인증에 사용하도록 설정해야 합니다:

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

인증서의 지문 알고리즘은 SHA1이어야 합니다. (예: Google Workspace) ID 공급자를 구성할 때 안전한 서명 알고리즘을 사용하세요.

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

사용자 액세스 및 관리

SAML 사용자 프로비저닝은 GitLab 13.7에서 소개되었습니다.

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

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

일치하는 SAML 신원을 가진 기존 사용자 찾기. 이는 사용자가 이전에 SCIM을 통해 계정을 만들었거나 그룹의 SAML IdP로 로그인 한 적이 있는 경우입니다.
동일한 이메일 주소를 가진 충돌하는 사용자가 없으면 자동으로 새 계정을 만듭니다.
동일한 이메일 주소를 가진 충돌하는 사용자가 있는 경우 사용자를 다음 중 하나로 리디렉션하여 로그인 페이지에서 다음을 수행합니다:
- 다른 이메일 주소로 새 계정 만들기.
- SAML 신원을 연결하기 위해 기존 계정으로 로그인하기.

기존 GitLab.com 계정에 SAML 연결하기

Remember me 체크 상자는 GitLab 15.7에서 소개되었습니다.

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

GitLab.com 계정에 로그인합니다. 필요한 경우 암호를 재설정하세요.
서명하기 위해 사용되는 그룹의 GitLab 단일 로그인 URL을 찾아 방문합니다. 그룹 소유자는 이것을 그룹의 설정 > SAML SSO 페이지에서 찾을 수 있습니다. 로그인 URL이 구성된 경우 사용자는 신원 공급자에서 GitLab 앱에 연결할 수 있습니다.
선택 사항. 2 주 동안 GitLab에 로그인 유지하려면 Remember me 확인란을 선택하세요. 여전히 SAML 제공자로부터 더 자주 재인증을 요청 받을 수 있습니다.
승인을 선택합니다.
프롬프트가 표시되면 신원 제공자에 자격 증명을 입력합니다.
그런 다음 GitLab.com으로 리디렉션되어 그룹에 액세스할 수 있어야 합니다. 나중에 SAML을 사용하여 GitLab.com에 로그인할 수 있습니다.

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

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

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

신원 공급자에 로그인합니다.
앱 디렉터리에서 “GitLab.com”을 선택합니다(이름은 신원 공급자의 관리자가 설정합니다).
그런 다음 GitLab.com으로 로그인되어 그룹으로 리디렉션됩니다.

사용자 SAML 신원 관리

SAML API를 사용하여 SAML 신원을 업데이트하는 기능이 GitLab 15.5에 도입되었습니다.

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

SAML 응답의 필수 필드.
대소문자를 구분하는 필드입니다.

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

각 사용자마다 고유해야 합니다.
사용자 ID와 같이 변경되지 않는 영구 값이어야 합니다.
이후 로그인 시 정확히 일치해야 하므로 사용자 입력에 의존하지 않아야 합니다. 대/소문자가 변경될 수 있는 사용자 입력에 의존해서는 안 됩니다.

NameID는 이메일 주소나 사용자 이름이 아니어야 합니다. 왜냐하면 다음과 같은 이유 때문입니다:

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

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

사용자 NameID 변경

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

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

대체로 사용자에게 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 응답 예시

SAML 응답은 브라우저의 개발자 도구나 콘솔에서 base64로 인코딩된 형식으로 찾을 수 있습니다. 정보를 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>

확인된 도메인을 사용하여 사용자 이메일 확인 생략

GitLab 15.4에서 소개됨.

기본적으로 SAML이나 SCIM으로 제공된 사용자는 신원을 확인하기 위해 확인 이메일을 받습니다. 대신 사용자 지정 도메인으로 GitLab을 구성하면 GitLab이 사용자 계정을 자동으로 확인합니다. 사용자는 여전히 기업 사용자 환영 이메일을 받습니다. 다음 조건을 모두 충족하면 확인이 생략됩니다:

사용자가 SAML이나 SCIM으로 제공됨.
사용자의 이메일 주소가 확인된 도메인에 속함.

사용자 액세스 차단

SAML SSO만 구성된 경우 그룹에서 사용자 액세스를 취소하려면 다음 중 하나를 수행합니다:

사용자 데이터 리포지터리에서 사용자를 (순서대로) 삭제하거나 특정 앱의 사용자 디렉터리에서 제거합니다.
기본 역할이 최소한의 액세스 권한을 갖는 사용자로 설정된 상태에서 그룹 상위 수준에 있는 그룹 동기화를 사용하여 그룹의 모든 리소스에 대한 액세스 차단을 자동으로 수행합니다.

SCIM을 사용하는 경우 사용자의 그룹 액세스를 취소하려면 액세스 제거를 참조하세요.

계정 연결 해제

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

특정 그룹이 GitLab.com에 로그인할 수 있는 권한을 더 이상 주고 싶지 않을 때.
사용자의 SAML NameID가 변경되어 GitLab이 사용자를 더 이상 찾을 수 없을 때.

계정 연결 해제 시 그 사용자에게 지정된 모든 역할이 제거됩니다. 사용자가 다시 계정을 연결하면 역할을 다시 할당해야 합니다.

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

예를 들어, MyOrg 계정을 연결 해제하려면 다음을 수행합니다:

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

SSO 강제 실행

GitLab 11.8에서 소개됨.
계속된 강제 실행을 위해 GitLab UI에서 개선됨 - GitLab 11.11.
업데이트된 타임아웃 경험을 포함하여 개선됨 - GitLab 13.8.
그룹 소유자가 SSO를 거치지 않도록 허용하는 기능을 포함하여 개선됨 - GitLab 13.8.
이 설정이 켜져 있는 경우, 열린 SSO 세션을 사용하여 Git에 대한 Git 활동에 SSO를 강제 실행하는 개선 - GitLab 13.11.
GitLab 14.7에서 CI/CD 작업에서 시작된 Git 활동에 대한 SSO 확인을 강제 실행하지 않도록하여 개선됨.
SSO 강제 실행이 사용되지 않을 때라도 투명한 강제 실행을 포함하기 위해 플래그인 transparent_sso_enforcement를 사용하는 GitLab 15.5에서 개선됨. 이 기능은 GitLab.com에서 비활성화됨.
GitLab.com에서 기본적으로 투명한 SSO를 사용하도록 설정함으로써 GitLab 15.8로 개선됨.
GitLab 15.10에서 플래그 transparent_sso_enforcement가 제거되며 기능이 일반적으로 사용 가능해짐.

GitLab.com에서는 다음과 같은 경우 SSO가 강제됩니다:

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

사용자는 매 방문마다 SSO를 통해 로그인하라는 메시지를 받지 않습니다. GitLab은 사용자가 SSO를 통해 인증되었는지 확인합니다. 사용자의 마지막 로그인 후 24시간이 지났을 경우 GitLab은 사용자에게 다시 SSO를 통해 로그인하라는 메시지를 보냅니다.

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

프로젝트/그룹 가시성	SSO 설정 강제화	신원이 있는 회원	신원이 없는 회원	비회원 또는 로그인하지 않은 경우
비공개	끔	강제화	강제화	강제화
비공개	켬	강제화	강제화	강제화
공개	끔	강제화	강제화	강제화
공개	켬	강제화	강제화	강제화

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

웹 활동 강제용 SSO 만

이 그룹의 웹 활동에 대해 SSO만 인증을 강제 사용 옵션이 활성화될 때:

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

웹 활동을 위한 SSO 강제 적용 시 다음과 같은 효과가 있습니다:

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

웹 활동을 위한 SSO가 강제될 때, 비-SSO 그룹 구성원은 즉시 액세스 권한이 없어지는 것은 아닙니다. 사용자가:

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

문제 해결

GitLab과 신원 제공자 간에 다른 SAML 용어가 일치하는 것이 어렵다면:

신원 제공자의 문서를 확인하세요. 사용하는 용어에 대한 정보를 위해 그들의 예제 SAML 구성을 살펴보세요.
Self-managed GitLab 인스턴스용 SAML SSO 문서를 확인하세요. Self-managed GitLab 인스턴스 SAML 구성 파일은 GitLab.com 파일보다 더 많은 옵션을 지원합니다. Self-managed 인스턴스 파일에 대한 정보는 다음에서 찾을 수 있습니다:
- 외부 OmniAuth SAML 문서
- ruby-saml 라이브러리
제공자로부터의 XML 응답을 우리의 내부 테스트에 사용된 XML 예제와 비교하세요.

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

GitLab.com 그룹을 위한 SAML SSO

식별 공급자 설정

Azure

Google Workspace

Okta

OneLogin

주장 구성

메타데이터 사용

ID 공급자 관리

ID 공급자 변경

이메일 도메인 변경

GitLab 구성

사용자 액세스 및 관리

기존 GitLab.com 계정에 SAML 연결하기

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

사용자 SAML 신원 관리

사용자 NameID 변경

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

지원되는 사용자 속성

SAML 응답 예시

확인된 도메인을 사용하여 사용자 이메일 확인 생략

사용자 액세스 차단

계정 연결 해제

SSO 강제 실행

웹 활동 강제용 SSO 만

관련 주제

문제 해결

도움말

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

도움받기