사용자는 SAML 아이덴티티 제공자를 통해 GitLab에 로그인할 수 있습니다.

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

• SCIM 앱에서 사용자를 추가하거나 제거하면 SCIM이 GitLab 그룹에서 사용자를 추가하거나 제거합니다.
• 사용자가 아직 그룹 멤버가 아닌 경우 로그인 프로세스의 일환으로 그룹에 추가됩니다.

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

아이덴티티 제공자 설정#

SAML 표준은 GitLab에서 다양한 아이덴티티 제공자를 사용할 수 있음을 의미합니다. 아이덴티티 제공자에 관련 문서가 있을 수 있습니다. GitLab을 위한 일반 SAML 문서이거나 특별히 GitLab을 대상으로 하는 문서일 수 있습니다.

아이덴티티 제공자를 설정할 때 일반적인 문제를 피하고 사용되는 용어 안내를 위해 다음 제공자별 문서를 사용하세요.

나열되지 않은 아이덴티티 제공자의 경우 제공자가 요구할 수 있는 정보에 대한 추가 지침은 인스턴스 SAML의 아이덴티티 제공자 구성 참고 사항을 참조할 수 있습니다.

GitLab은 다음 정보를 안내용으로만 제공합니다. SAML 앱 구성에 대한 질문이 있으면 제공자의 지원팀에 문의하세요.

아이덴티티 제공자 설정에 문제가 있는 경우 트러블슈팅 문서를 참조하세요.

Azure#

Azure를 아이덴티티 제공자로 SSO를 설정하려면:

1. 상단 표시줄에서 검색 또는 이동을 선택하고 그룹을 찾습니다.

2. 왼쪽 사이드바에서 설정 > SAML SSO를 선택합니다.

3. 이 페이지의 정보를 메모합니다.

4. Azure로 이동하여 비갤러리 애플리케이션을 만들고 애플리케이션을 위한 SSO를 구성합니다. 다음 GitLab 설정은 Azure 필드에 해당합니다.

   GitLab 설정	Azure 필드
   식별자	식별자 (엔터티 ID)
   어설션 컨슈머 서비스 URL	회신 URL (어설션 컨슈머 서비스 URL)
   GitLab 단일 로그인 URL	로그온 URL
   아이덴티티 제공자 단일 로그인 URL	로그인 URL
   인증서 지문	지문

5. 다음 속성을 설정해야 합니다:

   • **고유 사용자 식별자 (Name ID)**를 user.objectID로 설정합니다.
     • Name 식별자 형식을 persistent로 설정합니다. 자세한 내용은 사용자 SAML 아이덴티티 관리를 참조하세요.
   • 추가 클레임을 지원되는 속성으로 설정합니다.

6. 기존 GitLab 계정을 연결하기 위해 아이덴티티 제공자가 제공자 주도 호출을 갖도록 설정되어 있는지 확인합니다.

7. 선택 사항. 그룹 동기화를 사용하는 경우 그룹 클레임의 이름을 필요한 속성과 일치하도록 사용자 정의합니다.

그룹을 위한 SAML SSO를 사용하는 Azure의 SCIM 프로비저닝 데모를 시청하세요. 이 비디오의 objectID 매핑은 구식입니다. 대신 Microsoft Entra ID용 SCIM 구성 지침을 따르세요.

자세한 내용은 Azure 구성 예시를 참조하세요.

Google Workspace#

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

1. 상단 표시줄에서 검색 또는 이동을 선택하고 그룹을 찾습니다.

2. 왼쪽 사이드바에서 설정 > SAML SSO를 선택합니다.

3. 이 페이지의 정보를 메모합니다.

4. Google을 아이덴티티 제공자로 사용하는 SSO 설정 지침을 따릅니다. 다음 GitLab 설정은 Google Workspace 필드에 해당합니다.

   GitLab 설정	Google Workspace 필드
   식별자	엔터티 ID
   어설션 컨슈머 서비스 URL	ACS URL
   GitLab 단일 로그인 URL	시작 URL
   아이덴티티 제공자 단일 로그인 URL	SSO URL

5. Google Workspace는 인증서를 검색할 때 SHA256 지문을 표시합니다. 나중에 SHA256 지문을 생성해야 하는 경우 지문 계산을 참조하세요.

6. 다음 값을 설정합니다:

   • 기본 이메일의 경우: email.
   • 이름의 경우: first_name.
   • 성의 경우: last_name.
   • Name ID 형식의 경우: EMAIL.
   • NameID의 경우: 기본 정보 > 기본 이메일. 자세한 내용은 지원되는 속성을 참조하세요.

7. 기존 GitLab 계정을 연결하기 위해 아이덴티티 제공자가 제공자 주도 호출을 갖도록 설정되어 있는지 확인합니다.

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

자세한 내용은 Google Workspace 구성 예시를 참조하세요.

SAML과 Google Workspaces를 구성하고 그룹 동기화를 설정하는 방법 데모를 시청하세요.

Okta#

Okta를 아이덴티티 제공자로 SSO를 설정하려면:

1. 상단 표시줄에서 검색 또는 이동을 선택하고 그룹을 찾습니다.

2. 왼쪽 사이드바에서 설정 > SAML SSO를 선택합니다.

3. 이 페이지의 정보를 메모합니다.

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

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

   GitLab 설정	Okta 필드
   식별자	Audience URI
   어설션 컨슈머 서비스 URL	Single sign-on URL
   GitLab 단일 로그인 URL	Login page URL (Application Login Page 설정 아래)
   아이덴티티 제공자 단일 로그인 URL	Identity Provider Single Sign-On URL

5. Okta Single sign-on URL 필드 아래에서 Recipient URL 및 Destination URL에 이를 사용 체크박스를 선택합니다.

6. 다음 값을 설정합니다:

   • **Application username (NameID)**의 경우: Custom user.getInternalProperty("id").
   • Name ID Format의 경우: Persistent. 자세한 내용은 사용자 SAML 아이덴티티 관리를 참조하세요.
   • email의 경우: user.email 또는 유사한 것.
   • 추가 속성 명세는 지원되는 속성을 참조하세요.

7. 기존 GitLab 계정을 연결하기 위해 아이덴티티 제공자가 제공자 주도 호출을 갖도록 설정되어 있는지 확인합니다.

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

SCIM을 포함한 Okta SAML 설정 데모는 데모: Okta 그룹 SAML & SCIM 설정을 시청하세요.

자세한 내용은 Okta 구성 예시를 참조하세요.

OneLogin#

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

OneLogin을 아이덴티티 제공자로 설정하려면:

1. 상단 표시줄에서 검색 또는 이동을 선택하고 그룹을 찾습니다.

2. 왼쪽 사이드바에서 설정 > SAML SSO를 선택합니다.

3. 이 페이지의 정보를 메모합니다.

4. OneLogin 일반 SAML Test Connector (Advanced)를 사용하는 경우 OneLogin SAML Test Connector를 사용해야 합니다. 다음 GitLab 설정은 OneLogin 필드에 해당합니다:

   GitLab 설정	OneLogin 필드
   식별자	Audience
   어설션 컨슈머 서비스 URL	Recipient
   어설션 컨슈머 서비스 URL	ACS (Consumer) URL
   어설션 컨슈머 서비스 URL (이스케이프된 버전)	ACS (Consumer) URL Validator
   GitLab 단일 로그인 URL	Login URL
   아이덴티티 제공자 단일 로그인 URL	SAML 2.0 Endpoint

5. NameID에는 OneLogin ID를 사용합니다. 자세한 내용은 사용자 SAML 아이덴티티 관리를 참조하세요.

6. 필수 및 지원되는 속성을 구성합니다.

7. 기존 GitLab 계정을 연결하기 위해 아이덴티티 제공자가 제공자 주도 호출을 갖도록 설정되어 있는지 확인합니다.

자세한 내용은 OneLogin 구성 예시를 참조하세요.

Keycloak#

Keycloak을 아이덴티티 제공자로 설정하려면:

1. 상단 표시줄에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > SAML SSO를 선택합니다.
3. 이 페이지의 정보를 메모합니다.
4. Keycloak에서 SAML 클라이언트 만들기 지침을 따릅니다.

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

1. Keycloak에서 GitLab 클라이언트를 구성합니다.
   1. Keycloak에서 클라이언트로 이동하여 GitLab 클라이언트 구성을 선택합니다.
   2. 설정 탭의 SAML 기능 섹션에서:
      1. Name ID 형식을 persistent로 설정합니다.
      2. Name ID 형식 강제 적용을 켭니다.
      3. POST 바인딩 강제 적용을 켭니다.
      4. AuthnStatement 포함을 켭니다.
   3. 서명 및 암호화 섹션에서 문서 서명을 켭니다.
   4. 키 탭에서 모든 섹션이 비활성화되어 있는지 확인합니다.
   5. 클라이언트 범위 탭에서:
      1. GitLab의 클라이언트 범위를 선택합니다. 범위 이름은 https://gitlab.com/groups/your-group-name-dedicated와 같은 형식이어야 합니다.
      2. 새 매퍼 구성을 선택하고 열리는 창에서 사용자 속성을 선택합니다.
      3. 매퍼 추가 페이지에서 이름, 사용자 속성, SAML 속성 이름 필드를 email로 설정합니다.
      4. 저장을 선택합니다.
2. Keycloak에서 클라이언트 정보를 검색합니다.
   1. 작업 드롭다운 목록에서 어댑터 구성 다운로드를 선택합니다.
   2. 어댑터 구성 다운로드 대화 상자에서 드롭다운 목록에서 mod-auth-mellon을 선택합니다.
   3. 다운로드를 선택합니다.
   4. 다운로드된 아카이브를 추출하고 idp-metadata.xml을 엽니다.
   5. 아이덴티티 제공자 단일 로그인 URL을 검색합니다.
      1. <md:SingleSignOnService> 태그를 찾습니다.
      2. Location 속성의 값을 메모합니다.
   6. 인증서 지문을 검색합니다.
      1. <ds:X509Certificate> 태그의 값을 메모합니다.
      2. 값을 별도의 파일에 복사하고 값을 PEM 형식으로 변환합니다. 이렇게 하려면 파일 시작에 -----BEGIN CERTIFICATE-----를, 끝에 새 줄로 -----END CERTIFICATE-----를 추가합니다.
      3. 지문을 계산합니다.

어설션 구성#

최소한 다음 어설션을 구성해야 합니다:

1. NameID.
2. 이메일.

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

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

사용 가능한 속성에 대한 자세한 내용은 GitLab Self-Managed를 위한 SAML SSO를 참조하세요.

메타데이터 사용#

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

1. 상단 표시줄에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > SAML SSO를 선택합니다.
3. 제공된 GitLab 메타데이터 URL을 복사합니다.
4. 아이덴티티 제공자의 문서를 따르고 메타데이터 URL을 요청하는 경우 붙여 넣습니다.

아이덴티티 제공자의 문서에서 GitLab 메타데이터 URL을 지원하는지 확인하세요.

아이덴티티 제공자 관리#

아이덴티티 제공자를 설정한 후 다음을 수행할 수 있습니다:

• 아이덴티티 제공자 변경.
• 이메일 도메인 변경.

아이덴티티 제공자 변경#

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

아이덴티티 제공자를 변경하려면:

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

이메일 도메인 변경#

사용자를 새 이메일 도메인으로 마이그레이션하려면 사용자에게 다음을 지시합니다:

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

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

GitLab 구성#

히스토리

• GitLab 16.7에서 기본 멤버십 역할로 사용자 정의 역할 설정 기능 도입됨.

GitLab과 함께 작동하도록 아이덴티티 제공자를 설정한 후 인증에 사용하도록 GitLab을 구성해야 합니다:

1. 상단 표시줄에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > SAML SSO를 선택합니다.
3. 필드를 입력합니다:
   • 아이덴티티 제공자 단일 로그인 URL 필드에 아이덴티티 제공자의 SSO URL을 입력합니다.
   • 인증서 지문 필드에 SAML 토큰 서명 인증서의 지문을 입력합니다.
4. GitLab.com의 그룹의 경우: 기본 멤버십 역할 필드에서 다음을 선택합니다:
   1. 새 사용자에게 할당할 역할.
   2. SAML 그룹 링크가 그룹에 구성된 경우 매핑된 SAML 그룹의 멤버가 아닌 사용자에게 할당할 역할.
5. GitLab Self-Managed 인스턴스의 그룹의 경우: 기본 멤버십 역할 필드에서 새 사용자에게 할당할 역할을 선택합니다. 기본 역할은 Guest입니다. 해당 역할은 그룹에 추가된 모든 사용자의 시작 역할이 됩니다:
   • GitLab 16.7 이상에서 그룹 Owner는 사용자 정의 역할을 설정할 수 있습니다.
   • GitLab 16.6 이하에서 그룹 Owner는 Guest 이외의 기본 멤버십 역할을 기본 멤버십 역할로 설정할 수 있습니다.
6. 이 그룹에 대한 SAML 인증 활성화 체크박스를 선택합니다.
7. 권장. 다음을 선택합니다:
   • GitLab 17.4 이상에서 엔터프라이즈 사용자의 비밀번호 및 패스키 인증 비활성화. 자세한 내용은 엔터프라이즈 사용자의 비밀번호 및 패스키 인증 비활성화 문서를 참조하세요.
   • 이 그룹의 웹 활동에 대해 SSO 전용 인증 적용.
   • 이 그룹의 Git 및 Dependency Proxy 활동에 대해 SSO 전용 인증 적용. 자세한 내용은 SSO 적용 문서를 참조하세요.
8. 변경 사항 저장을 선택합니다.

GitLab 구성에 문제가 있는 경우 트러블슈팅 문서를 참조하세요.

사용자 액세스 및 관리#

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

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

• 일치하는 SAML 아이덴티티가 있는 기존 사용자를 찾습니다. 사용자의 계정이 SCIM에 의해 만들어지거나 이전에 그룹의 SAML IdP로 로그인한 경우입니다.
• 동일한 이메일 주소를 가진 계정이 아직 없는 경우 새 계정을 자동으로 만듭니다. GitLab은 기본 및 보조 이메일 주소를 모두 매칭하려고 합니다.
• 동일한 이메일 주소를 가진 계정이 이미 있는 경우 사용자를 로그인 페이지로 리디렉션합니다:
  • 다른 이메일 주소로 새 계정을 만듭니다.
  • 기존 계정에 로그인하여 SAML 아이덴티티를 연결합니다.

제한된 액세스로 프로비저닝 동작#

히스토리

• GitLab 18.6에서 bso_minimal_access_fallback라는 플래그와 함께 도입됨. 기본적으로 비활성화.
• GitLab 18.10에서 기본적으로 활성화됨.

제한된 액세스가 사용 가능한 시트 없이 활성화된 경우 SAML을 통해 프로비저닝된 사용자에게 최소 액세스 역할이 할당됩니다.

자세한 내용은 SAML, SCIM 및 LDAP를 사용한 프로비저닝 동작을 참조하세요.

SAML을 기존 GitLab.com 계정에 연결#

히스토리

• GitLab 15.7에서 기억하기 체크박스 도입됨.

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

1. GitLab.com 계정에 로그인합니다. 필요한 경우 비밀번호를 재설정합니다.
2. 로그인하려는 그룹의 GitLab 단일 로그인 URL을 찾아 방문합니다. 그룹 Owner는 그룹의 설정 > SAML SSO 페이지에서 이를 찾을 수 있습니다. 로그인 URL이 구성된 경우 사용자는 아이덴티티 제공자에서 GitLab 앱에 연결할 수 있습니다.
3. 선택 사항. 2주 동안 GitLab에 로그인 상태를 유지하려면 기억하기 체크박스를 선택합니다. SAML 제공자로 더 자주 재인증하라는 요청을 받을 수 있습니다.
4. 승인을 선택합니다.
5. 메시지가 표시되면 아이덴티티 제공자에 자격 증명을 입력합니다.
6. GitLab.com으로 다시 리디렉션되어 이제 그룹에 액세스할 수 있습니다. 앞으로 SAML을 사용하여 GitLab.com에 로그인할 수 있습니다.

사용자가 이미 그룹의 멤버인 경우 SAML 아이덴티티를 연결해도 역할은 변경되지 않습니다.

이후 방문에서 SAML로 GitLab.com에 로그인하거나 링크를 직접 방문할 수 있습니다. SSO 적용 옵션이 켜져 있으면 아이덴티티 제공자를 통해 로그인하도록 리디렉션됩니다.

엔터프라이즈 사용자를 위한 자동 아이덴티티 연결#

엔터프라이즈 사용자가 그룹에서 제거된 후 다시 돌아오는 경우 엔터프라이즈 SSO 계정으로 로그인할 수 있습니다. 아이덴티티 제공자의 사용자 이메일 주소가 기존 GitLab 계정의 이메일 주소와 동일하게 유지되는 한 SSO 아이덴티티는 계정에 자동으로 연결되고 사용자는 문제 없이 로그인할 수 있습니다. 이 기능은 엔터프라이즈 사용자로 청구되었지만 아직 그룹에 로그인하지 않은 기존 사용자에게도 적용됩니다.

SAML로 GitLab.com에 로그인#

1. 아이덴티티 제공자에 로그인합니다.
2. 앱 목록에서 "GitLab.com" 앱을 선택합니다. (이름은 아이덴티티 제공자의 관리자가 설정합니다.)
3. GitLab.com에 로그인되어 그룹으로 리디렉션됩니다.

사용자 SAML 아이덴티티 관리#

히스토리

• GitLab 15.5에서 SAML API를 사용한 SAML 아이덴티티 업데이트 도입됨.

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

• SAML 응답의 필수 필드입니다.
• 대소문자를 구분하지 않습니다.

NameID는:

• 각 사용자에게 고유해야 합니다.
• 무작위로 생성된 고유한 사용자 ID와 같이 변경되지 않는 영구적인 값이어야 합니다.
• 이후 로그인 시도에서 정확히 일치해야 하므로 대소문자 사이에서 변경될 수 있는 사용자 입력에 의존해서는 안 됩니다.

NameID는 이메일 주소나 사용자 이름이어서는 안 됩니다:

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

NameID 형식은 이메일처럼 다른 형식이 필요한 필드를 사용하지 않는 한 Persistent여야 합니다. Transient를 제외한 모든 형식을 사용할 수 있습니다.

사용자 NameID 변경#

그룹 Owner는 SAML API를 사용하여 그룹 멤버의 NameID를 변경하고 SAML 아이덴티티를 업데이트할 수 있습니다.

SCIM이 구성된 경우 그룹 Owner는 SCIM API를 사용하여 SCIM 아이덴티티를 업데이트할 수 있습니다.

또는 사용자에게 SAML 계정을 다시 연결하도록 요청합니다.

1. 관련 사용자에게 그룹에서 계정 연결을 해제하도록 요청합니다.
2. 관련 사용자에게 새 SAML 앱에 계정을 연결하도록 요청합니다.

특정 아이덴티티 제공자의 권장 값과 형식에 대한 자세한 내용은 아이덴티티 제공자 설정을 참조하세요.

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

히스토리

• GitLab 16.7에서 엔터프라이즈 사용자 설정만 구성하도록 변경됨.

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

지원되는 사용자 속성#

• can_create_group - 엔터프라이즈 사용자가 새 최상위 그룹을 만들 수 있는지 여부를 나타내는 true 또는 false. 기본값은 true.
• projects_limit - 엔터프라이즈 사용자가 만들 수 있는 총 개인 프로젝트 수. 값이 0이면 사용자는 개인 네임스페이스에서 새 프로젝트를 만들 수 없습니다. 기본값은 100000.
• SessionNotOnOrAfter - 사용자 SAML 세션을 종료할 시점을 나타내는 ISO 8601 타임스탬프 값.

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>

SAML 세션 타임아웃 사용자 정의#

히스토리

• GitLab 18.2에서 saml_timeout_supplied_by_idp_override라는 플래그와 함께 도입됨.

기본적으로 GitLab은 24시간 후에 SAML 세션을 종료합니다. SAML2 AuthnStatement의 SessionNotOnOrAfter 속성으로 이 기간을 사용자 정의할 수 있습니다. 이 속성에는 사용자 세션을 종료할 시점을 나타내는 ISO 8601 타임스탬프 값이 포함됩니다. 지정된 경우 이 값은 기본 SAML 세션 타임아웃인 24시간을 재정의합니다.

기본적으로 GitLab은 7일(10080분)의 비활성 후 세션을 종료합니다. SessionNotOnOrAfter 타임스탬프가 이 시간 이후인 경우 세션이 종료될 때 사용자는 재인증해야 합니다.

응답 예시#

   <saml:AuthnStatement SessionIndex="WDE5aBYjNEj_9IjCFiK0E1YelZT" SessionNotOnOrAfter="2025-08-25T01:23:45.067Z" AuthnInstant="2025-08-24T13:23:45.067Z">
      <saml:AuthnContext>
         <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
      </saml:AuthnContext>
   </saml:AuthnStatement>

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

히스토리

• GitLab 15.4에서 도입됨.

기본적으로 SAML 또는 SCIM으로 프로비저닝된 사용자에게는 신원 확인을 위한 확인 이메일이 전송됩니다. 대신 GitLab에 사용자 정의 도메인을 구성하면 GitLab이 사용자 계정을 자동으로 확인합니다. 사용자는 여전히 엔터프라이즈 사용자 환영 이메일을 받습니다. 다음 두 가지가 모두 해당되는 경우 확인이 우회됩니다:

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

엔터프라이즈 사용자의 비밀번호 및 패스키 인증 비활성화#

히스토리

• GitLab 17.4에서 도입됨.

사전 조건:

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

그룹의 모든 엔터프라이즈 사용자에 대한 비밀번호 인증을 비활성화할 수 있습니다. 이는 그룹의 관리자인 엔터프라이즈 사용자에게도 적용됩니다. 이 설정을 구성하면 엔터프라이즈 사용자가 비밀번호를 변경, 재설정하거나 비밀번호로 인증하는 것이 중지됩니다. 대신 이 사용자들은 다음으로 인증할 수 있습니다:

• GitLab 웹 UI를 위한 그룹 SAML IdP.
• 그룹에서 엔터프라이즈 사용자의 개인 액세스 토큰을 비활성화하지 않은 경우 GitLab API 및 HTTP 기본 인증을 통한 Git을 위한 개인 액세스 토큰.

엔터프라이즈 사용자의 비밀번호 및 패스키 인증을 비활성화하려면:

1. 상단 표시줄에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > SAML SSO를 선택합니다.
3. 구성 아래에서 엔터프라이즈 사용자의 비밀번호 및 패스키 인증 비활성화를 선택합니다.
4. 변경 사항 저장을 선택합니다.

사용자 액세스 차단#

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

• 다음 순서로 사용자를 제거합니다:
  1. 아이덴티티 제공자의 사용자 데이터 저장소 또는 특정 앱의 사용자 목록.
  2. GitLab.com 그룹.
• 그룹의 최상위 수준에서 그룹 동기화를 사용하고 기본 역할을 최소 액세스로 설정하여 그룹의 모든 리소스에 대한 액세스를 자동으로 차단합니다.

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

계정 연결 해제#

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

• 더 이상 그룹이 GitLab.com에 로그인하는 것을 허용하지 않으려는 경우.
• SAML NameID가 변경되어 GitLab이 더 이상 사용자를 찾을 수 없는 경우.

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

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

1. 오른쪽 상단 모서리에서 아바타를 선택합니다.
2. 프로필 편집을 선택합니다.
3. 왼쪽 사이드바에서 계정을 선택합니다.
4. 서비스 로그인 섹션에서 연결된 계정 옆의 연결 해제를 선택합니다.

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 아이덴티티가 있는 경우 다음 중 하나 또는 둘 모두가 해당됩니다:

• 그룹의 단일 로그인 URL을 사용하여 GitLab에 로그인했습니다.
• SCIM으로 프로비저닝되었습니다.

사용자는 매 방문 시 SSO를 통해 로그인하라는 메시지가 표시되지 않습니다. GitLab은 사용자가 SSO를 통해 인증했는지 확인합니다. 사용자가 마지막으로 로그인한 시간이 24시간 이상 전인 경우 GitLab은 SSO를 통해 다시 로그인하도록 메시지를 표시합니다.

SSO는 다음과 같이 적용됩니다:

웹 활동에 대한 SSO 전용 적용#

이 그룹의 웹 활동에 대해 SSO 전용 인증 적용 옵션이 활성화된 경우:

• 모든 멤버는 기존 SAML 아이덴티티가 있는지 여부에 관계없이 그룹 리소스에 액세스하기 위해 GitLab 그룹의 단일 로그인 URL을 사용하여 GitLab에 액세스해야 합니다.
• SSO는 사용자가 조직의 그룹 계층 구조에서 그룹과 프로젝트에 액세스할 때 적용됩니다. 사용자는 SAML SSO를 통해 로그인하지 않고도 조직 외부의 다른 그룹 및 프로젝트를 볼 수 있습니다.
• 사용자를 새 멤버로 수동으로 추가할 수 없습니다.
• Owner 역할을 가진 사용자는 최상위 그룹 설정에 필요한 변경을 수행하기 위해 표준 로그인 프로세스를 사용할 수 있습니다.
• 비멤버이거나 로그인하지 않은 사용자의 경우:
  • 공개 그룹 리소스에 액세스할 때 SSO가 적용되지 않습니다.
  • 비공개 그룹 리소스에 액세스할 때 SSO가 적용됩니다.
• 조직의 그룹 계층 구조의 항목에 대해 대시보드 가시성은 다음과 같습니다:
  • 할 일 목록을 볼 때 SSO가 적용됩니다. SSO 세션이 만료되면 할 일 항목이 숨겨지고 알림이 표시됩니다.
  • 할당된 이슈 목록을 볼 때 SSO가 적용됩니다. SSO 세션이 만료되면 이슈가 숨겨집니다. 이슈 414475에서 이슈가 표시되도록 동작을 변경하도록 제안되고 있습니다.
  • 담당자 또는 검토자인 머지 리퀘스트를 볼 때 SSO가 적용되지 않습니다. SSO 세션이 만료된 경우에도 머지 리퀘스트를 볼 수 있습니다.
  • Guest, Planner, Reporter, Developer, Maintainer 또는 Owner 역할을 가진 비공개 프로젝트의 스니펫을 볼 때 SSO가 적용되지 않습니다.

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

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

웹 활동에 대한 SSO가 적용되는 경우 비SSO 그룹 멤버는 즉시 액세스를 잃지 않습니다. 사용자가:

• 활성 세션이 있는 경우 아이덴티티 제공자 세션이 타임아웃될 때까지 최대 24시간 동안 그룹에 계속 액세스할 수 있습니다.
• 로그아웃된 경우 아이덴티티 제공자에서 제거된 후 그룹에 액세스할 수 없습니다.

SSO 적용이 있는 저장소 미러링#

이 그룹의 Git 및 Dependency Proxy 활동에 대해 SSO 전용 인증 적용을 활성화하면 저장소 미러링은 SSO 세션 요구 사항의 적용을 받습니다. 자세한 내용은 SSO 적용이 있는 풀 미러링을 참조하세요.

새 아이덴티티 제공자로 마이그레이션#

새 아이덴티티 제공자로 마이그레이션하려면 SAML API를 사용하여 모든 그룹 멤버의 아이덴티티를 업데이트합니다.

예를 들어:

1. 해당 시간에 활성 사용자가 없도록 유지 관리 창을 설정합니다.
2. SAML API를 사용하여 각 사용자의 아이덴티티를 업데이트합니다.
3. 새 아이덴티티 제공자를 구성합니다.
4. 로그인이 작동하는지 테스트합니다.

관련 주제#

• GitLab Self-Managed를 위한 SAML SSO
• 용어집
• 블로그 포스트: GitLab.com에서 SAML 및 SSO 활성화를 위한 완벽한 가이드
• GitLab.com과 GitLab Self-Managed 간의 인증 비교
• 통합 인증을 통해 만들어진 사용자를 위한 비밀번호
• SAML 그룹 동기화

트러블슈팅#

GitLab과 아이덴티티 제공자 간에 다양한 SAML 용어를 매칭하기 어려운 경우:

1. 아이덴티티 제공자의 문서를 확인합니다. 사용하는 용어에 대한 정보는 SAML 구성 예시를 살펴보세요.
2. GitLab Self-Managed SAML SSO 문서를 확인합니다. GitLab Self-Managed SAML 구성 파일은 GitLab.com 파일보다 더 많은 옵션을 지원합니다. GitLab Self-Managed 인스턴스 파일에 대한 정보는 다음에서 찾을 수 있습니다:
   • 외부 OmniAuth SAML 문서.
   • ruby-saml 라이브러리.
3. 제공자의 XML 응답을 내부 테스트에 사용되는 예시 XML과 비교합니다.

다른 트러블슈팅 정보는 SAML 트러블슈팅 가이드를 참조하세요.