GitLab.com 그룹을 위한 SAML SSO

Tier: Premium, Ultimate Offering: GitLab.com

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

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

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

SAML SSO는 최상위 그룹에 대해서만 구성할 수 있습니다.

ID 공급업체 설정

SAML 표준을 사용하므로 GitLab에서 다양한 ID 공급업체를 사용할 수 있습니다. ID 공급업체에 관련된 문서가 있을 수 있습니다. 일반적인 SAML 문서거나 특정하게 GitLab을 위한 문서일 수 있습니다.

ID 공급업체를 설정할 때, 다음의 공급업체별 문서를 사용하여 일반적인 문제를 피하고 사용된 용어를 가이드로 사용하세요.

리스트되지 않은 ID 공급업체의 경우, 추가 가이던스를 위해 ID 공급업체 설정 문서를 참조할 수 있습니다.

GitLab은 다음 정보를 참고 용도로만 제공합니다. SAML 앱을 구성하는 데 문제가 있으면, 공급업체 지원팀에 문의하세요.

ID 공급업체 설정에 문제가 있다면 문제해결 문서를 참조하세요.

Azure

Azure를 ID 공급업체로 사용하여 SSO를 설정하기 위해:

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

Azure로 이동하여, 갤러리가 아닌 애플리케이션을 생성하고, 애플리케이션에 SSO 구성하세요. 다음의 GitLab 설정이 Azure 필드와 일치합니다.

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

다음과 같은 속성을 설정하세요:
- 고유 사용자 식별자 (이름 식별자)를 user.objectID로 설정하세요.
- nameid-format을 persistent로 설정하세요. 더 많은 정보는 사용자 SAML ID 관리를 참조하세요.
- 이메일을 user.mail 또는 유사한 값으로 설정하세요.
- 추가 클레임은 지원되는 속성으로 설정하세요.
기존 GitLab 계정을 연결하기 위해 공급업체가 제공된 전화(Call)을 사용하여야 합니다.
추가 사항. 그룹 동기화를 사용하는 경우, 필요한 속성과 일치하는 그룹 클레임의 이름을 사용자화하세요.

그룹용 SAML SSO를 위한 Azure에서 SCIM 프로비저닝을 참조하세요. 이 비디오에서 ‘objectID’ 매핑은 오래된 것입니다. 대신 SCIM 문서를 따르세요.

더 많은 정보는 예제 구성 페이지를 참조하세요.

Google Workspace

Google Workspace를 ID 공급업체로 설정하기 위해:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾으세요.
설정 > SAML SSO를 선택하세요.
이 페이지의 정보를 확인하세요.
Google을 ID 공급업체로 SSO를 설정하기 위한 지침을 따르세요. 다음의 GitLab 설정이 Google Workspace 필드와 일치합니다.

GitLab 설정 Google Workspace 필드

식별자 엔터티 ID
Assertion 컨슈머 서비스 URL ACS URL
GitLab 단일 로그인 URL 시작 URL
ID 공급자 단일 로그인 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을 설정하세요.
- 이름 ID 형식에는 EMAIL을 설정하세요.
- NameID에는 Basic Information > Primary email을 설정하세요. 더 많은 정보는 지원되는 속성을 참조하세요.
기존 GitLab 계정을 연결하기 위해 공급업체가 제공된 전화(Call)을 사용하여야 합니다.

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

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

더 많은 정보는 예제 구성 페이지를 참조하세요.

Google Workspaces와 그룹 동기화를 설정하는 방법 및 SAML 구성 보기.

Okta

OKta를 ID 공급업체로 사용하여 SSO를 설정하기 위해:

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

Okta에서 SAML 애플리케이션을 설정하기 위한 지침을 따르세요.

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

GitLab 설정	Okta 필드
식별자	수용 대상 URI
Assertion 컨슈머 서비스 URL	단일 로그인 URL
GitLab 단일 로그인 URL	로그인 페이지 URL (Application Login Page 설정 아래)
ID 공급자 단일 로그인 URL	ID 공급자 단일 로그인 URL

Okta 단일 로그인 URL 필드에서 수령자 URL 및 대상 URL에 사용 확인란을 선택하세요.
다음 값을 설정하세요:
- 애플리케이션 사용자명(이름 ID): 사용자.getInternalProperty(“id”) 방식으로 Custom 설정하세요.
- Name ID 형식: Persistent. 더 많은 정보는 사용자 SAML ID 관리를 참조하세요.
- 이메일: user.email 또는 유사한 값으로 설정하세요.
- 추가 속성 명세에 대한 정보는 지원되는 속성을 참조하세요.
기존 GitLab 계정을 연결하기 위해 공급업체가 제공된 전화(Call)을 사용하여야 합니다.

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

Okta SAML 설정 및 SCIM을 포함한 데모는 Demo: Okta Group SAML & SCIM 설정에서 확인할 수 있습니다.

더 많은 정보는 예제 구성 페이지를 참조하세요.

OneLogin

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

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

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

OneLogin 제네릭 SAML 테스트 커넥터 (고급)를 사용하는 경우 OneLogin SAML 테스트 커넥터를 사용해야 합니다. 다음과 같은 GitLab 설정이 OneLogin 필드에 해당합니다.

GitLab 설정	OneLogin 필드
식별자	수강자
주장 컨슈머 서비스 URL	수령인
주장 컨슈머 서비스 URL	ACS(소비자) URL
주장 컨슈머 서비스 URL (이스케이프 된 버전)	ACS(소비자) URL 유효성 검사기
GitLab 단일 로그인 URL	로그인 URL
식별 공급자 단일 로그인 URL	SAML 2.0 엔드포인트

NameID로 OneLogin ID를 사용합니다. 자세한 내용은 사용자 SAML ID 관리를 참조하세요.
필수 및 지원되는 속성을 구성합니다.
기존 GitLab 계정을 연결하도록 식별 공급자를 설정했는지 확인합니다.

주장 구성

참고: 이 속성은 대소문자를 구분하지 않습니다.

최소한 다음 주장을 구성해야 합니다.

NameID.
이메일.

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

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

더 많은 정보는 자체 관리형 GitLab 인스턴스에 대한 사용 가능한 속성을 참조하세요.

메타데이터 사용

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

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

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

식별 공급자 관리

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

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

식별 공급자 변경

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

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

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

이메일 도메인 변경

사용자를 새 이메일 도메인으로 마이그레이션하려면 사용자에게 다음을 알리세요:

최신 이메일을 계정의 기본 이메일로 추가하고 확인하세요.
선택사항. 이전 이메일을 계정에서 제거하세요.

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

GitLab 구성

GitLab 16.7에서 소개된 사용자 정의 역할을 기본 멤버십 역할로 설정할 수 있는 기능.

GitLab에서 식별 공급자를 구성하려면 다음을 수행해야 합니다:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
설정 > SAML SSO를 선택합니다.
다음을 입력합니다:
- 식별 공급자 단일 로그인 URL 필드에 식별 공급자의 SSO URL을 입력합니다.
- 인증서 지문 필드에 SAML 토큰 서명 인증서의 지문을 입력합니다.
GitLab.com의 그룹의 경우: 기본 멤버십 역할 필드에서 다음을 선택합니다:
1. 새 사용자에게 할당할 역할.
2. 그룹에 매핑된 SAML 그룹 없는 사용자에 할당할 역할.
자체 관리형 인스턴스의 그룹의 경우: 기본 멤버십 역할 필드에서 새 사용자에게 할당할 역할을 선택합니다. 기본 역할은 게스트입니다. 이 역할은 그룹에 추가된 모든 사용자의 시작 역할이 됩니다:
- GitLab 16.7 이후, 그룹 소유자는 사용자 정의 역할을 설정할 수 있습니다.
- GitLab 16.6 이전, 그룹 소유자는 게스트 이외의 기본 멤버십 역할을 설정할 수 있습니다.
이 그룹에 대한 SAML 인증 사용 확인란을 선택합니다.
선택 사항. 다음을 선택하세요:
- GitLab 17.4 이후, 기업 사용자의 비밀번호 인증 비활성화. 자세한 내용은 기업 사용자의 비밀번호 인증 비활성화 문서를 참조하세요.
- 웹 활동의 SSO 전용 인증 강제 실행.
- 이 그룹의 Git 및 의존성 프록시 활동의 SSO 전용 인증 강제 실행. 자세한 내용은 SSO 강제 실행 문서를 참조하세요.
변경 사항 저장을 선택합니다.

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

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

사용자 접근 및 관리

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

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

동일한 SAML 신원 정보를 가진 기존 사용자 찾기. 이는 사용자가 SCIM을 통해 계정이 생성되었거나 그룹의 SAML IdP로 이전에 로그인한 경우입니다.
동일한 이메일 주소를 가진 충돌하는 사용자가 없는 경우, 새 계정을 자동으로 생성합니다.
동일한 이메일 주소를 가진 충돌하는 사용자가 있는 경우, 사용자를 다음과 같이 로그인 페이지로 리디렉션하여:
- 다른 이메일 주소로 새 계정을 생성합니다.
- SAML 신원을 연결하는 기존 계정으로 로그인합니다.

기존 GitLab.com 계정에 SAML 연결

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

참고: 만약 사용자가 해당 그룹의 기업 사용자인 경우, 아래 단계는 적용되지 않습니다. 그 대신, 기업 사용자는 기존 계정과 동일한 이메일을 가진 SAML 계정으로 로그인해야 합니다. 이를 통해 GitLab은 SAML 계정을 기존 계정에 연결할 수 있습니다.

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

GitLab.com 계정에 로그인합니다. 필요한 경우 비밀번호를 재설정하세요.
로그인하려는 그룹의 GitLab 단일 로그인 URL을 찾아 방문합니다. 그룹 소유자는 이 URL을 해당 그룹의 설정 > SAML SSO 페이지에서 찾을 수 있습니다. 로그인 URL이 구성된 경우, 사용자는 신원 공급자에서 GitLab 앱에 연결할 수 있습니다.
선택 사항입니다. Remember me 확인란을 선택하여 2주 동안 GitLab에 로그인 상태를 유지합니다. 여전히 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 16.7에서 기존의 특정 사용자 설정만 구성하도록 변경되었습니다.

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

지원되는 사용자 속성

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

SAML 응닑 예제

웹 브라우저의 개발자 도구 또는 콘솔에서 base64로 인코딩된 형식으로 SAML 응닑을 찾을 수 있습니다. 원하는 base64 디코딩 도구를 사용하여 정보를 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으로 제공된 사용자는 ID를 확인하기 위해 확인 이메일을 받습니다. 대신 사용자 지정 도메인으로 GitLab을 구성하면 GitLab이 자동으로 사용자 계정을 확인합니다. 사용자는 여전히 기업 사용자 환영 이메일을 받습니다. 다음이 모두 참이면 확인이 우회됩니다:

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

기업 사용자를 위한 패스워드 인증 비활성화

입힌된 날짜 : GitLab 17.4.

전제 조건:

기업 사용자가 속한 그룹의 소유자 역할이 있어야 합니다.
그룹 SSO가 활성화되어 있어야 합니다.

그룹의 기업 사용자에 대한 패스워드 인증을 비활성화할 수 있습니다. 이렇게 하면 기업 사용자는 사용자 이름과 암호를 사용하여 인증할 수 없습니다. 대신 이러한 사용자는 다음 중 하나를 할 수 있습니다:

그룹의 SAML IdP를 사용하여 GitLab 웹 UI에서 인증합니다.
개인 액세스 토큰을 사용하여 GitLab API 및 Git에 HTTP 기본 인증을 사용하여 인증합니다. 개인 액세스 토큰 사용이 비활성화되지 않은 경우에만 해당됩니다.

이는 기업 사용자가 그룹의 관리자인 경우에도 적용됩니다.

기업 사용자를 위한 패스워드 인증을 비활성화하려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
설정 > SAML SSO를 선택합니다.
구성 아래에서 기업 사용자를 위한 패스워드 인증 비활성화를 선택합니다.
변경 사항 저장을 선택합니다.

기존 사용자 (자동 ID 다시 연결)

기업 사용자가 그룹에서 제거되었다가 돌아오면 기업 SSO 계정으로 로그인할 수 있습니다. 식별 공급자의 사용자 이메일 주소가 기존 GitLab 계정의 이메일 주소와 같은 경우 SSO ID가 자동으로 계정에 연결되며 사용자는 문제없이 로그인할 수 있습니다.

사용자 액세스 차단

SAML SSO만 구성된 상황에서 사용자의 그룹 액세스를 철회하려면 다음 중 하나를 수행하십시오:

사용자를 :
1. 식별 공급자의 사용자 데이터 저장소 또는 해당 응용 프로그램의 사용자 목록에서 제거합니다.
2. GitLab.com 그룹에서 제거합니다.
그룹 동기화를 사용하여 그룹의 모든 리소스의 액세스를 자동으로 차단하는 기본 역할을 최소 액세스로 설정합니다.

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

계정 연결 해제

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

더 이상 그룹이 GitLab.com에 대한 로그인을 수행하지 못하도록 하려고 합니다.
SAML NameID가 변경되어 GitLab이 사용자를 더 이상 찾을 수 없습니다.

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

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

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

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

SSO 강제 실행

GitLab 15.5에서 개선됨 플래그 transparent_sso_enforcement 추가하여 SSO 강제 실행이 활성화되지 않은 상태에서도 투명한 강제 실행이 포함되도록 함. GitLab.com에서 사용 중지됨.
GitLab 15.8에서 개선됨 - GitLab.com에서 기본적으로 투명 SSO 활성화됨.
GitLab 15.10에서 일반 사용 가능. 기능 플래그 transparent_sso_enforcement 제거됨.

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

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

사용자가 SAML 식별 정보를 가지고 있는 경우 다음 중 하나 이상이나 모두 참인 경우입니다:

그들이 자신의 GitLab 그룹의 단일 로그인 URL을 사용하여 GitLab에 로그인했을 때
그들이 SCIM에 의해 공급되었을 때

사용자들은 매 방문마다 SSO를 통해 로그인하도록 요청받지 않습니다. GitLab은 사용자가 SSO를 통해 인증했는지를 확인합니다. 사용자의 마지막 로그인이 24시간 이상 전이라면, GitLab은 사용자에게 다시 SSO를 통해 로그인하도록 요청합니다.

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

프로젝트/그룹 가시성	SSO 강제 실행 설정	식별 정보가 있는 멤버	식별 정보가 없는 멤버	비 멤버 또는 로그인하지 않은 사용자
비공개	끔	강제 실행됨	강제 실행되지 않음	강제 실행되지 않음
비공개	켬	강제 실행됨	강제 실행됨	강제 실행됨
공개	끔	강제 실행됨	강제 실행되지 않음	강제 실행되지 않음
공개	켬	강제 실행됨	강제 실행됨	강제 실행되지 않음

유사한 SSO 필요에 대한 이슈가 존재합니다. 이 요구 사항이 추가되기 전까지, API를 활용하는 기능을 SSO 세션이 활성화되어 있지 않은 상태에서도 사용할 수 있습니다.

웹 활동에 대한 SSO 전용 강제 실행

이 그룹의 웹 활동에 대한 SSO 전용 인증 강제 실행 옵션이 활성화된 경우:

모든 멤버는 기존 SAML 식별 정보의 여부에 관계없이 그룹 자원에 접근하기 위해 자신의 GitLab 그룹의 단일 로그인 URL을 사용해야 합니다.
조직의 그룹 계층 구조에서 그룹 및 프로젝트에 접근할 때 SSO가 강제로 실행됩니다.
사용자는 SAML SSO를 통해 로그인하지 않고도 조직 외부의 다른 그룹 및 프로젝트를 볼 수 있습니다.
사용자들은 수동으로 새로운 멤버로 추가할 수 없습니다.
소유자 역할을 갖는 사용자는 핵심 그룹 설정을 변경하기 위해 표준 로그인 프로세스를 사용할 수 있습니다.
비 멤버 또는 로그인하지 않은 사용자에 대해:
- SSO가 공개 그룹 자원에 접근할 때 강제되지 않음.
- SSO가 비공개 그룹 자원에 접근할 때 강제 실행됨.
조직의 그룹 계층 구조에 대한 대시보드 가시성은 다음과 같습니다:
- 할 일 목록 보기시 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시간동안 그룹에 액세스할 수 있습니다.
로그아웃 되면, 제공자에서 제거된 후에 그룹에 액세스할 수 없습니다.

새로운 제공자로 마이그레이션

새로운 제공자로 마이그레이션하려면, SAML API를 사용하여 그룹 멤버들의 식별 정보를 업데이트하세요.

예를 들면:

사용자가 그 시간에 활성 상태가 아닌지 확인하기 위해 유지 관리 창을 설정하십시오.
각 사용자의 식별 정보를 업데이트하기 위해 SAML API를 사용하세요. (../../../api/saml.md#update-extern_uid-field-for-a-saml-identity).
새로운 제공자를 구성하세요.
로그인이 작동하는지 테스트하세요.

문제 해결

만약 GitLab와 아이덴티티 제공자 사이의 다른 SAML 용어를 맞추는 데 어려움을 겪는다면:

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

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

GitLab.com 그룹을 위한 SAML SSO

ID 공급업체 설정

Azure

Google Workspace

Okta

OneLogin

주장 구성

메타데이터 사용

식별 공급자 관리

식별 공급자 변경

이메일 도메인 변경

GitLab 구성

사용자 접근 및 관리

기존 GitLab.com 계정에 SAML 연결

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

사용자 SAML 신원 관리

사용자 NameID 변경

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

지원되는 사용자 속성

SAML 응닑 예제

검증된 도메인을 사용하여 사용자 이메일 확인 우회

기업 사용자를 위한 패스워드 인증 비활성화

기존 사용자 (자동 ID 다시 연결)

사용자 액세스 차단

계정 연결 해제

SSO 강제 실행

웹 활동에 대한 SSO 전용 강제 실행

새로운 제공자로 마이그레이션

관련 주제

문제 해결

도움말

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

도움받기