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

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

왼쪽 사이드바에서 검색하거나 이동을 선택하고 귀하의 그룹을 찾습니다.
설정 > SAML SSO를 선택합니다.
이 페이지의 정보를 기록해 두세요.

Azure로 이동하여 비갤러리 애플리케이션 생성하고 애플리케이션에 대한 SSO 구성을 진행합니다. 다음 GitLab 설정은 Azure 필드에 대응합니다.

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

다음 속성을 설정해야 합니다:
- 고유 사용자 식별자 (이름 식별자)를 user.objectID로 설정합니다.
- nameid-format을 persistent로 설정합니다. 자세한 내용은 사용자 SAML ID 관리를 참조하세요.
- 이메일을 user.mail 또는 유사한 값으로 설정합니다.
- 추가 주장을 지원되는 속성으로 설정합니다.
ID 제공자가 기존 GitLab 계정에 대한 제공자 주도 호출을 할 수 있도록 설정되어 있는지 확인하세요.
선택 사항. 그룹 동기화를 사용하는 경우, 필요한 속성에 맞게 그룹 청구서의 이름을 사용자 정의하세요.

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

자세한 내용은 예제 구성 페이지를 참조하세요.

Google Workspace

Google Workspace를 아이덴티티 공급자로 설정하려면:

왼쪽 사이드바에서 Search or go to를 선택하고 그룹을 찾습니다.
Settings > SAML SSO를 선택합니다.
이 페이지의 정보를 기록해 둡니다.

Google을 아이덴티티 공급자로 사용하여 SSO 설정하기 안내를 따릅니다. 다음 GitLab 설정은 Google Workspace 필드에 해당합니다.

GitLab setting	Google Workspace field
Identifier	Entity ID
Assertion consumer service URL	ACS URL
GitLab single sign-on URL	Start URL
Identity provider single sign-on URL	SSO URL

Google Workspace는 SHA256 지문을 표시합니다. GitLab에서 SAML을 구성하는 데 필요한 SHA1 지문을 가져오려면:
1. 인증서를 다운로드합니다.
2. 다음 명령어를 실행합니다:
```
openssl x509 -noout -fingerprint -sha1 -inform pem -in "GoogleIDPCertificate-domain.com.pem"
```
다음 값을 설정합니다:
- Primary email: email.
- First name: first_name.
- Last name: last_name.
- Name ID format: EMAIL.
- NameID: Basic Information > Primary email. 더 많은 정보는 지원되는 속성을 참조하세요.
아이덴티티 공급자가 기존 GitLab 계정을 연결하기 위해 공급자 주도 호출을 설정하도록 확인합니다.

GitLab SAML SSO 페이지에서 Verify SAML Configuration를 선택할 때, NameID 형식을 persistent로 설정하라는 경고를 무시합니다.

자세한 내용은 예제 구성 페이지를 참조하세요.

Google Workspaces와 SAML을 구성하는 방법 및 그룹 동기화 설정에 대한 데모를 확인하세요.

Okta

Okta를 아이덴티티 공급자로 사용하여 SSO를 설정하려면:

왼쪽 사이드바에서 Search or go to를 선택하고 그룹을 찾습니다.
Settings > SAML SSO를 선택합니다.
이 페이지의 정보를 기록해 둡니다.

Okta에서 SAML 애플리케이션 설정하기 안내를 따릅니다.

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

GitLab setting	Okta field
Identifier	Audience URI
Assertion consumer service URL	Single sign-on URL
GitLab single sign-on URL	Login page URL (under Application Login Page settings)
Identity provider single sign-on URL	Identity Provider Single Sign-On URL

Okta의 Single sign-on URL 필드에서 Use this for Recipient URL and Destination URL 체크박스를 선택합니다.
다음 값을 설정합니다:
- Application username (NameID): Custom user.getInternalProperty("id").
- Name ID Format: Persistent. 더 많은 정보는 사용자 SAML 아이덴티티 관리를 참조하세요.
- email: user.email 또는 유사한 값.
- 추가 Attribute Statements에 대한 내용은 지원되는 속성을 참조하세요.
아이덴티티 공급자가 기존 GitLab 계정을 연결하기 위해 공급자 주도 호출을 설정하도록 확인합니다.

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

SCIM을 포함한 Okta SAML 설정 데모는 Demo: Okta Group SAML & SCIM setup에서 확인하세요.

자세한 내용은 예제 구성 페이지를 참조하세요.

OneLogin

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

OneLogin을 신원 프로바이더로 설정하려면:

왼쪽 사이드바에서 Search or go to를 선택하고 그룹을 찾습니다.
Settings > SAML SSO를 선택합니다.
이 페이지의 정보를 기록해 둡니다.

OneLogin 일반 SAML Test Connector (Advanced)을 사용하는 경우, 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 (escaped version)	ACS (Consumer) URL Validator
GitLab single sign-on URL	Login URL
Identity provider single sign-on URL	SAML 2.0 Endpoint

NameID에는 OneLogin ID를 사용합니다. 자세한 내용은 사용자 SAML 신원 관리를 참조하세요.
필수 및 지원 속성 구성을 설정합니다.
신원 프로바이더가 기존 GitLab 계정과 연결하기 위해 프로바이더 시작 호출이 설정되었는지 확인합니다.

Assertions 구성

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

최소한, 다음 assertions을 구성해야 합니다:

NameID.
이메일.

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

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

자세한 내용은 자체 관리 GitLab 인스턴스에서 사용 가능한 속성을 참조하세요.

메타데이터 사용

일부 신원 프로바이더를 구성하려면 GitLab 메타데이터 URL이 필요합니다.

이 URL을 찾으려면:

왼쪽 사이드바에서 Search or go to를 선택하고 그룹을 찾습니다.
Settings > SAML SSO를 선택합니다.
제공된 GitLab metadata URL을 복사합니다.
신원 프로바이더의 문서를 따라 메타데이터 URL을 요청할 때 붙여넣습니다.

신원 프로바이더의 문서를 확인하여 GitLab 메타데이터 URL을 지원하는지 확인하세요.

신원 프로바이더 관리

신원 프로바이더를 설정한 후, 다음을 수행할 수 있습니다:

신원 프로바이더 변경.
이메일 도메인 변경.

신원 공급자 변경

다른 신원 공급자로 변경할 수 있습니다. 변경 과정 중에는 사용자가 SAML 그룹에 액세스할 수 없습니다. 이를 완화하기 위해 SSO enforcement를 비활성화할 수 있습니다.

신원 공급자를 변경하는 방법:

새 신원 공급자로 그룹 구성하기.
선택 사항. NameID가 동일하지 않다면, 사용자의 NameID 변경하기.

이메일 도메인 변경

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

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

NameID가 이메일 주소로 구성된 경우, 사용자의 NameID 변경하기.

GitLab 구성

GitLab 16.7에서 도입된 기본 구성원 역할로 사용자 정의 역할 설정 기능.

신원 공급자가 GitLab과 작동하도록 설정한 후, GitLab을 인증용으로 사용할 수 있도록 구성해야 합니다:

왼쪽 사이드바에서 Search or go to를 선택하고 그룹을 찾습니다.
Settings > SAML SSO를 선택합니다.
필드를 작성합니다:
- Identity provider single sign-on URL 필드에 신원 공급자에서 가져온 SSO URL을 입력합니다.
- Certificate fingerprint 필드에 SAML 토큰 서명 인증서의 지문을 입력합니다.
GitLab.com의 그룹의 경우: Default membership role 필드에서 다음을 선택합니다:
1. 새 사용자에게 할당할 역할.
2. 매핑된 SAML 그룹의 구성원이 아닌 사용자에게 할당할 역할 SAML 그룹 링크가 그룹에 대해 구성된 경우.
자체 관리 인스턴스의 그룹의 경우: Default membership role 필드에서 새 사용자에게 할당할 역할을 선택합니다. 기본 역할은 Guest입니다. 해당 역할은 그룹에 추가된 모든 사용자에게 시작 역할이 됩니다:
- GitLab 16.7 이상에서 그룹 소유자는 사용자 정의 역할을 설정할 수 있습니다.
- GitLab 16.6 이하에서 그룹 소유자는 기본 구성원 역할로 Guest 이외의 역할을 설정할 수 있습니다.
Enable SAML authentication for this group 체크박스를 선택합니다.
선택 사항. 선택합니다:
- GitLab 17.4 이상에서 Disable password authentication for enterprise users. 자세한 내용은 기업 사용자를 위한 비밀번호 인증 비활성화 문서를 참조하세요.
- 이 그룹에 대해 웹 활동에 대한 SSO 전용 인증 강제 적용.
- 이 그룹에 대해 Git 및 종속성 프록시 활동에 대한 SSO 전용 인증 강제 적용. 자세한 내용은 SSO enforcement 문서를 참조하세요.
Save changes를 선택합니다.

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

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

사용자 접근 및 관리

그룹 SSO가 구성되고 활성화되면 사용자는 신원 공급자의 대시보드를 통해 GitLab.com 그룹에 접근할 수 있습니다.

SCIM이 구성된 경우, SCIM 페이지에서 사용자 접근을 참조하세요.

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

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

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

기억하기 체크박스는 GitLab 15.7에 도입되었습니다.

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

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

GitLab.com 계정으로 로그인합니다. 필요 시 비밀번호를 재설정합니다.
로그인하는 그룹의 GitLab 단일 로그인 URL을 찾고 방문합니다. 그룹 소유자는 그룹의 설정 > SAML SSO 페이지에서 이를 찾을 수 있습니다. 로그인 URL이 구성된 경우, 사용자는 신원 공급자에서 GitLab 앱에 연결할 수 있습니다.
선택 사항. 기억하기 체크박스를 선택하여 GitLab에 2주간 로그인 상태를 유지합니다. 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 응답

브라우저의 개발자 도구 또는 콘솔에서 SAML 응답을 찾을 수 있으며, base64 인코딩된 형식입니다. 선택한 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으로 프로비저닝된 사용자는 자신의 신원을 확인하기 위해 확인 이메일을 받습니다. 대신, 사용자 지정 도메인으로 GitLab을 구성할 수 있습니다 그리고 GitLab은 사용자 계정을 자동으로 확인합니다. 사용자는 여전히 엔터프라이즈 사용자 환영 이메일을 받습니다. 다음 두 조건이 모두 충족되면 확인이 우회됩니다:

사용자가 SAML 또는 SCIM으로 프로비저닝되었습니다.
사용자가 확인된 도메인에 속하는 이메일 주소를 가지고 있습니다.

엔터프라이즈 사용자를 위한 비밀번호 인증 비활성화

도입됨 GitLab 17.4에서.

필수 조건:

엔터프라이즈 사용자가 속한 그룹에 대한 소유자 역할이 있어야 합니다.
그룹 SSO가 활성화되어 있어야 합니다.

그룹의 엔터프라이즈 사용자에 대해 비밀번호 인증을 비활성화할 수 있습니다. 이렇게 하면 엔터프라이즈 사용자가 사용자 이름과 비밀번호를 사용하여 인증할 수 없습니다. 대신, 이러한 사용자는 다음 중 하나를 수행할 수 있습니다:

그룹의 SAML IdP를 사용하여 GitLab 웹 UI에 인증합니다.
개인 액세스 토큰을 사용하여 GitLab API와 Git에 HTTP 기본 인증으로 인증합니다, 단, 개인 액세스 토큰 사용이 비활성화되지 않은 경우에 한합니다.

이것은 엔터프라이즈 사용자가 그룹의 관리자일 경우에도 적용됩니다.

엔터프라이즈 사용자에 대한 비밀번호 인증을 비활성화하려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
설정 > SAML SSO를 선택합니다.
구성에서 엔터프라이즈 사용자를 위한 비밀번호 인증 비활성화를 선택합니다.
변경 사항 저장을 선택합니다.

복귀하는 사용자 (자동 신원 재연결)

엔터프라이즈 사용자가 그룹에서 제거된 후 다시 돌아오면, 그들은 자신의 엔터프라이즈 SSO 계정으로 로그인할 수 있습니다. 사용자의 이메일 주소가 ID 공급자에 있는 것과 기존 GitLab 계정의 이메일 주소가 동일한 한, SSO 신원이 계정에 자동으로 연결되어 사용자는 문제없이 로그인할 수 있습니다.

사용자 접근 차단

사용자의 접근을 그룹에서 철회하려면 SAML SSO만 구성된 경우 다음 방법 중 하나를 사용하십시오:

사용자를 다음 순서로 제거합니다:
1. ID 공급자의 사용자 데이터 저장소 또는 특정 앱의 사용자 목록에서 제거합니다.
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 ID를 가진 사용자에 대해. 사용자는 GitLab.com 자격 증명을 사용하여 조직 외부의 다른 그룹 및 프로젝트뿐만 아니라 사용자 설정을 SAML SSO를 통해 로그인하지 않고도 볼 수 있습니다.

사용자는 다음 중 하나 이상이 참이면 SAML ID를 갖습니다:

그들은 GitLab 그룹의 싱글 사인온(URL)을 사용하여 GitLab에 로그인했습니다.
SCIM에 의해 프로비저닝되었습니다.

사용자는 매 방문 시 SSO를 통해 로그인하라는 메시지를 받지 않습니다. GitLab은 사용자가 SSO를 통해 인증되었는지 확인합니다. 사용자가 마지막으로 24시간 이상 로그인하지 않았다면, GitLab은 사용자에게 SSO를 통해 다시 로그인하라는 메시지를 표시합니다.

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

프로젝트/그룹 가시성	SSO 설정	ID가 있는 멤버	ID가 없는 멤버	비회원 또는 로그인하지 않음
비공개	끔	시행됨	시행되지 않음	시행되지 않음
비공개	켬	시행됨	시행됨	시행됨
공개	끔	시행됨	시행되지 않음	시행되지 않음
공개	켬	시행됨	시행됨	시행되지 않음

유사한 SSO 요구사항을 API 활동에 추가하자는 문제가 존재합니다. 이 요구사항이 추가될 때까지 활성 SSO 세션 없이 API에 의존하는 기능을 사용할 수 있습니다.

웹 활동에 대한 SSO 전용 시행

이 그룹에 대한 웹 활동에 대해 SSO 전용 인증 시행 옵션이 활성화되면:

모든 멤버는 기존 SAML ID가 있는지와 관계없이 그룹 리소스에 접근하기 위해 GitLab 그룹의 싱글 사인온(URL)을 사용해야 합니다.
사용자가 조직의 그룹 계층에서 그룹 및 프로젝트에 접근할 때 SSO가 시행됩니다. 사용자는 SAML SSO를 통해 로그인하지 않고도 조직 외부의 다른 그룹 및 프로젝트를 볼 수 있습니다.
사용자는 수동으로 새로운 멤버로 추가될 수 없습니다.
소유자 역할을 가진 사용자는 최상위 그룹 설정에 필요한 변경을 하기 위해 표준 로그인 프로세스를 사용할 수 있습니다.
비회원 또는 로그인하지 않은 사용자에 대한:
- 공개 그룹 리소스에 접근할 때 SSO는 시행되지 않습니다.
- 비공개 그룹 리소스에 접근할 때 SSO가 시행됩니다.
조직의 그룹 계층에 대한 항목은 대시보드 가시성이 다음과 같습니다:
- 할 일 목록을 볼 때 SSO가 시행됩니다. SSO 세션이 만료되면 할 일 항목이 숨겨지며, 알림이 표시됩니다.
- 할당된 문제 목록을 볼 때 SSO가 시행됩니다. SSO 세션이 만료되면 문제는 숨겨집니다. 문제 414475는 이러한 동작을 변경하여 문제가 보이도록 제안합니다.
- 할당자거나 리뷰가 요청된 경우 병합 요청 목록을 볼 때 SSO가 시행되지 않습니다. SSO 세션이 만료되어도 병합 요청을 볼 수 있습니다.

웹 활동에 대한 SSO 시행이 활성화되면 다음과 같은 효과가 있습니다:

그룹의 경우 사용자는 프로젝트가 포크되더라도 최상위 그룹 외부에서 프로젝트를 공유할 수 없습니다.
CI/CD 작업에서 발생하는 Git 활동은 SSO 체크가 시행되지 않습니다.
일반 사용자와 연결되지 않은 자격 증명(예: 프로젝트 및 그룹 액세스 토큰, 배포 키)에 대해서도 SSO 체크가 시행되지 않습니다.
사용자는 Dependency Proxy를 사용하여 이미지를 수동으로 끌어오기 전에 SSO를 통해 로그인해야 합니다.
이 그룹에 대한 Git 및 Dependency Proxy 활동에 대해 SSO 전용 인증 시행 옵션이 활성화되면 Git 활동이 포함된 API 엔드포인트는 SSO 시행 하에 있습니다. 예를 들어, 브랜치, 커밋 또는 태그를 생성하거나 삭제하는 것입니다. SSH 및 HTTPS를 통한 Git 활동의 경우 사용자는 GitLab 저장소에 푸시하거나 가져오기 전에 SSO를 통해 로그인한 최소 하나의 활성 세션이 있어야 합니다. 활성 세션은 다른 디바이스에서 생성될 수 있습니다.

웹 활동에 대한 SSO가 시행되면 비-SSO 그룹 멤버는 즉시 접근 권한을 잃지 않습니다. 사용자가:

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

새로운 ID 공급자로 마이그레이션하기

새로운 ID 공급자로 마이그레이션하려면 SAML API를 사용하여 모든 그룹 구성원의 ID를 업데이트하세요.

예를 들어:

해당 시간에 활성 사용자가 없도록 유지보수 시간을 설정합니다.
SAML API 를 사용하여 각 사용자의 ID를 업데이트하세요.
새로운 ID 공급자를 구성합니다.
로그인 작동 여부를 테스트합니다.

문제 해결

GitLab과 ID 공급자 간의 다양한 SAML 용어를 맞추기 어려운 경우:

ID 공급자의 문서를 확인하십시오. 사용하는 용어에 대한 정보는 그들의 예제 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

Assertions 구성

메타데이터 사용

신원 프로바이더 관리

신원 공급자 변경

이메일 도메인 변경

GitLab 구성

사용자 접근 및 관리

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

SAML로 GitLab.com에 로그인

사용자 SAML 신원 관리

사용자 NameID 변경

SAML 응답에서 엔터프라이즈 사용자 설정 구성

지원되는 사용자 속성

예시 SAML 응답

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

엔터프라이즈 사용자를 위한 비밀번호 인증 비활성화

복귀하는 사용자 (자동 신원 재연결)

사용자 접근 차단

계정 연결 해제

SSO 시행

웹 활동에 대한 SSO 전용 시행

새로운 ID 공급자로 마이그레이션하기

관련 주제

문제 해결

도움말

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

도움받기