InfoGrab Docs

GitLab.com 그룹에 대한 SCIM 구성

요약

오픈 표준인 SCIM(System for Cross-domain Identity Management)을 사용하여 다음을 자동화할 수 있습니다: GitLab SAML SSO SCIM은 사용자 업데이트를 지원하지 않습니다.

오픈 표준인 SCIM(System for Cross-domain Identity Management)을 사용하여 다음을 자동화할 수 있습니다:

  • 사용자 생성.
  • 사용자 제거(SCIM ID 비활성화).
  • 사용자 재추가(SCIM ID 재활성화).

GitLab SAML SSO SCIM은 사용자 업데이트를 지원하지 않습니다.

GitLab 그룹에 SCIM이 활성화되면 해당 그룹의 구성원이 GitLab과 ID 공급자 간에 동기화됩니다.

GitLab 그룹 SCIM 내부 APIRFC7644 프로토콜의 일부를 구현합니다. ID 공급자는 GitLab 그룹 SCIM 내부 API를 사용하여 SCIM 앱을 개발할 수 있습니다.

GitLab Self-Managed에서 SCIM을 설정하려면 GitLab Self-Managed에 대한 SCIM 구성을 참조하세요.

GitLab 구성#

사전 요구 사항:

GitLab SAML SSO SCIM을 구성하려면:

  1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Settings > SAML SSO를 선택합니다.
  3. Generate a SCIM token을 선택합니다.
  4. ID 공급자 구성을 위해 다음을 저장합니다:
    • Your SCIM token 필드의 토큰.
    • SCIM API endpoint URL 필드의 URL.

ID 공급자 구성#

GitLab은 여러 ID 공급자와 함께 SCIM을 지원합니다. 다른 공급자도 GitLab과 작동할 수 있지만 테스트되지 않았으며 지원되지 않습니다. 지원되지 않는 공급자에 대한 도움이 필요하면 해당 공급자에게 직접 문의하세요. GitLab 지원팀은 관련 로그 항목을 검토하여 도움을 드릴 수 있습니다.

Okta 구성#

Okta에 대한 싱글 사인온 설정 중에 생성된 SAML 애플리케이션은 SCIM을 위해 설정되어야 합니다.

사전 요구 사항:

  • Okta Lifecycle Management 제품을 사용해야 합니다. 이 제품 티어는 Okta에서 SCIM을 사용하는 데 필요합니다.
  • GitLab이 구성되어 있어야 합니다.
  • Okta에 대한 SAML 애플리케이션이 Okta 설정 노트에 설명된 대로 설정되어 있어야 합니다.
  • Okta SAML 설정이 NameID 구성을 포함하여 구성 단계와 정확히 일치해야 합니다.

Okta를 SCIM용으로 구성하려면:

  1. Okta에 로그인합니다.
  2. 오른쪽 상단에서 Admin을 선택합니다. 버튼은 Admin 영역에서는 보이지 않습니다.
  3. Application 탭에서 Browse App Catalog를 선택합니다.
  4. GitLab을 검색하고 GitLab 애플리케이션을 찾아 선택합니다.
  5. GitLab 애플리케이션 개요 페이지에서 Add를 선택합니다.
  6. Application Visibility에서 두 체크박스를 모두 선택합니다. 현재 GitLab 애플리케이션은 SAML 인증을 지원하지 않으므로 사용자에게 아이콘이 표시되지 않아야 합니다.
  7. Done을 선택하여 애플리케이션 추가를 완료합니다.
  8. Provisioning 탭에서 Configure API integration을 선택합니다.
  9. Enable API integration을 선택합니다.
    • Base URL에 GitLab SCIM 구성 페이지의 SCIM API endpoint URL에서 복사한 URL을 붙여넣습니다.
    • API Token에 GitLab SCIM 구성 페이지의 Your SCIM token에서 복사한 SCIM 토큰을 붙여넣습니다.
  10. 구성을 확인하려면 Test API Credentials를 선택합니다.
  11. Save를 선택합니다.
  12. API 통합 세부 정보를 저장한 후 왼쪽에 새 설정 탭이 나타납니다. To App을 선택합니다.
  13. Edit를 선택합니다.
  14. Create UsersDeactivate Users 모두에 대해 Enable 체크박스를 선택합니다.
  15. Save를 선택합니다.
  16. Assignments 탭에서 사용자를 할당합니다. 할당된 사용자는 GitLab 그룹에서 생성 및 관리됩니다.

Microsoft Entra ID 구성#

히스토리
  • GitLab 16.10에서 Microsoft Entra ID 용어로 변경되었습니다.

사전 요구 사항:

Azure Active Directory에 대한 싱글 사인온 설정 중에 생성된 SAML 애플리케이션은 SCIM을 위해 설정되어야 합니다. 예시는 구성 예시를 참조하세요.

Note

SCIM 프로비저닝은 다음 지침에 따라 정확하게 구성해야 합니다. 잘못 구성하면 사용자 프로비저닝 및 로그인에 문제가 발생하며, 이를 해결하는 데 많은 노력이 필요합니다. 단계에 문제나 질문이 있으면 GitLab 지원팀에 문의하세요.

Microsoft Entra ID를 SCIM용으로 구성하려면:

  1. 앱에서 Provisioning 탭으로 이동하여 Get started를 선택합니다.
  2. Provisioning ModeAutomatic으로 설정합니다.
  3. 다음 값을 사용하여 Admin Credentials를 완료합니다:
    • Tenant URL 필드에 GitLab의 SCIM API endpoint URL 값.
    • Secret Token 필드에 GitLab의 Your SCIM token 값.
  4. Test Connection을 선택합니다. 테스트가 성공하면 계속하기 전에 구성을 저장하거나 문제 해결 정보를 참조합니다.
  5. Save를 선택합니다.

저장 후 MappingsSettings 섹션이 나타납니다.

매핑 구성#

Mappings 섹션에서 먼저 그룹을 프로비저닝합니다:

  1. Provision Microsoft Entra ID Groups를 선택합니다.

  2. 속성 매핑 페이지에서 Enabled 토글을 끕니다. SCIM 그룹 프로비저닝은 GitLab에서 지원되지 않습니다. 그룹 프로비저닝을 활성화해도 SCIM 사용자 프로비저닝이 중단되지는 않지만 혼란스럽고 오해를 일으킬 수 있는 Entra ID SCIM 프로비저닝 로그에 오류가 발생합니다.

    [!note] Provision Microsoft Entra ID Groups가 비활성화되어 있어도 매핑 섹션에 "Enabled: Yes"가 표시될 수 있습니다. 이 동작은 안전하게 무시할 수 있는 표시 버그입니다.

  3. Save를 선택합니다.

다음으로 사용자를 프로비저닝합니다:

  1. Provision Microsoft Entra ID Users를 선택합니다.
  2. Enabled 토글이 Yes로 설정되어 있는지 확인합니다.
  3. 모든 Target Object Actions가 활성화되어 있는지 확인합니다.
  4. Attribute Mappings에서 구성된 속성 매핑과 일치하도록 매핑을 구성합니다:
    1. 선택 사항. customappsso Attribute 열에서 externalId를 찾아 삭제합니다.
    2. 다음을 포함하도록 첫 번째 속성을 편집합니다:
      • source attributeobjectId
      • target attributeexternalId
      • matching precedence1
    3. 기존 customappsso 속성을 구성된 속성 매핑과 일치하도록 업데이트합니다.
    4. 다음 표에 없는 추가 속성을 삭제합니다. 삭제하지 않아도 문제가 발생하지 않지만 GitLab은 해당 속성을 사용하지 않습니다.
  5. 매핑 목록 아래에서 Show advanced options 체크박스를 선택합니다.
  6. Edit attribute list for customappsso 링크를 선택합니다.
  7. id가 기본(primary) 및 필수 필드이고 externalId도 필수인지 확인합니다.
  8. Save를 선택하면 속성 매핑 구성 페이지로 돌아갑니다.
  9. Attribute Mapping 구성 페이지를 닫으려면 오른쪽 상단의 X를 선택합니다.

설정 구성#

Settings 섹션에서:

  1. 선택 사항. 원하는 경우 Send an email notification when a failure occurs 체크박스를 선택합니다.
  2. 선택 사항. 원하는 경우 Prevent accidental deletion 체크박스를 선택합니다.
  3. 필요한 경우 Save를 선택하여 모든 변경 사항이 저장되었는지 확인합니다.

매핑과 설정을 구성한 후, 앱 개요 페이지로 돌아가 Start provisioning을 선택하여 GitLab에서 사용자의 자동 SCIM 프로비저닝을 시작합니다.

Warning

동기화된 후에 idexternalId에 매핑된 필드를 변경하면 오류가 발생할 수 있습니다. 여기에는 프로비저닝 오류, 중복 사용자가 포함되며 기존 사용자가 GitLab 그룹에 액세스하지 못할 수도 있습니다.

속성 매핑 구성#

Note

Microsoft가 Azure Active Directory에서 Entra ID 명명 체계로 전환하는 동안 사용자 인터페이스에서 불일치가 나타날 수 있습니다. 문제가 있는 경우 이 문서의 이전 버전을 보거나 GitLab 지원팀에 문의할 수 있습니다.

SCIM용 Entra ID 구성 시 속성 매핑을 구성합니다. 예시는 구성 예시를 참조하세요.

다음 표는 GitLab에 필요한 속성 매핑을 제공합니다.

소스 속성 대상 속성 일치 우선순위
objectId externalId 1
userPrincipalName 또는 mail 1 emails[type eq "work"].value
mailNickname userName
displayName 또는 Join(" ", [givenName], [surname]) 2 name.formatted
Switch([IsSoftDeleted], , "False", "True", "True", "False") 3 active
  1. userPrincipalName이 이메일 주소가 아니거나 전달할 수 없는 경우 mail을 소스 속성으로 사용합니다.
  2. displayNameFirstname Lastname 형식과 일치하지 않는 경우 Join 표현식을 사용합니다.
  3. 이것은 직접 매핑이 아닌 표현식 매핑 유형입니다. Mapping type 드롭다운 목록에서 Expression을 선택합니다.

각 속성 매핑에는 다음이 있습니다:

  • 대상 속성에 해당하는 customappsso Attribute.
  • 소스 속성에 해당하는 Microsoft Entra ID Attribute.
  • 일치 우선순위.

각 속성에 대해:

  1. 기존 속성을 편집하거나 새 속성을 추가합니다.
  2. 드롭다운 목록에서 필요한 소스 및 대상 속성 매핑을 선택합니다.
  3. Ok를 선택합니다.
  4. Save를 선택합니다.

SAML 구성이 권장 SAML 설정과 다른 경우 매핑 속성을 선택하고 적절히 수정합니다. externalId 대상 속성에 매핑하는 소스 속성은 SAML NameID에 사용되는 속성과 일치해야 합니다.

매핑이 표에 없는 경우 Microsoft Entra ID 기본값을 사용합니다. 필수 속성 목록은 내부 그룹 SCIM API 문서를 참조하세요.

사용자 액세스#

동기화 프로세스 중에 모든 새 사용자는:

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

히스토리

제한된 액세스가 활성화되고 구독 시트가 없는 경우, SCIM을 통해 프로비저닝된 사용자에게 최소 액세스 권한이 할당됩니다.

이런 경우 사용자는 최소 액세스(응답 HTTP 201 Created)로 성공적으로 생성되며, 사용자의 roles 속성이 이 할당을 반영합니다. 사용 가능한 시트가 없는 경우 후속 권한 업데이트 작업이 실패할 수 있습니다.

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

다음 다이어그램은 SCIM 앱에 사용자를 추가할 때 발생하는 일을 설명합니다:

Mermaid 다이어그램 (13줄)
소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
accTitle: Adding users to your SCIM application
accDescr: How GitLab determines whether or not to associate a SCIM identity with a user.

A[Add User to SCIM app] -->|IdP sends user info to GitLab| B(GitLab: Does the email exist?) B -->|No| C[GitLab creates user with SCIM identity] B -->|Yes| D(GitLab: Is the user part of the group?) D -->|No| E(GitLab: Is SSO enforcement enabled?) E -->|No| G E -->|Yes| F[GitLab sends message back: The member's email address is not linked to a SAML account] D -->|Yes| G[Associate SCIM identity to user]

프로비저닝 중:

  • GitLab 사용자 계정이 존재하는지 확인할 때 기본 및 보조 이메일이 모두 고려됩니다.
  • 중복 사용자 이름은 사용자를 생성할 때 접미사 1을 추가하여 처리됩니다. 예를 들어 test_user가 이미 존재하면 test_user1이 사용됩니다. test_user1이 이미 존재하면 GitLab은 사용되지 않은 사용자 이름을 찾기 위해 접미사를 증가시킵니다. 4번 시도 후 사용되지 않은 사용자 이름을 찾을 수 없으면 사용자 이름에 임의의 문자열이 첨부됩니다.

이후 방문 시 신규 및 기존 사용자는 다음을 통해 그룹에 액세스할 수 있습니다:

  • ID 공급자의 대시보드.
  • 링크에 직접 방문.

권한 정보는 그룹 SAML 페이지를 참조하세요.

GitLab 그룹에 대한 SCIM을 통해 생성된 사용자의 비밀번호#

GitLab은 모든 사용자 계정에 비밀번호가 필요합니다. SCIM 프로비저닝을 사용하여 생성된 사용자의 경우, GitLab이 자동으로 임의의 비밀번호를 생성하므로 첫 번째 로그인 중에 비밀번호를 설정할 필요가 없습니다. GitLab이 GitLab 그룹에 대한 SCIM을 통해 생성된 사용자의 비밀번호를 생성하는 방법에 대한 자세한 내용은 통합 인증을 통해 생성된 사용자의 생성된 비밀번호를 참조하세요.

SCIM 및 SAML ID 연결#

그룹 SAML이 구성되어 있고 기존 GitLab.com 계정이 있는 경우, 사용자는 SCIM 및 SAML ID를 연결할 수 있습니다. 동기화가 활성화되면 기존 사용자에 대한 프로비저닝 오류가 발생할 수 있으므로 사용자는 동기화가 켜지기 전에 이 작업을 수행해야 합니다.

SCIM 및 SAML ID를 연결하려면:

  1. GitLab.com 사용자 계정의 기본 이메일 주소를 ID 공급자의 사용자 프로필 이메일 주소와 일치하도록 업데이트합니다.
  2. SAML ID를 연결합니다.

액세스 제거#

ID 공급자에서 사용자를 제거하거나 비활성화하여 다음에 대한 액세스를 제거합니다:

  • 최상위 그룹.
  • 모든 서브그룹 및 프로젝트.

ID 공급자가 구성된 일정에 따라 동기화를 수행하면 사용자의 구성원 자격이 취소되고 액세스 권한을 잃습니다.

SCIM을 활성화해도 SAML ID가 없는 기존 사용자가 자동으로 제거되지 않습니다.

Note

프로비저닝 해제는 GitLab 사용자 계정을 삭제하지 않습니다.

Mermaid 다이어그램 (8줄)
소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
accTitle: Deprovisioning users
accDescr: How removing users from your SCIM app removes them from GitLab groups.

A[Remove User from SCIM app] -->|IdP sends request to GitLab| B(GitLab: Is the user part of the group?) B -->|No| C[Nothing to do] B -->|Yes| D[GitLab removes user from GitLab group]

액세스 재활성화#

히스토리
  • GitLab 16.0에서 skip_saml_identity_destroy_during_scim_deprovision이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
  • GitLab 16.4에서 일반 제공(Generally available)됩니다. 기능 플래그 skip_saml_identity_destroy_during_scim_deprovision이 제거됩니다.

SCIM을 통해 사용자가 제거되거나 비활성화된 후, SCIM ID 공급자에 다시 추가하여 해당 사용자를 재활성화할 수 있습니다.

ID 공급자가 구성된 일정에 따라 동기화를 수행하면 사용자의 SCIM ID가 재활성화되고 그룹 구성원 자격이 복원됩니다.

GitLab.com 그룹에 대한 SCIM 구성

Tier: Premium, Ultimate
Offering: GitLab.com
원문 보기
요약

오픈 표준인 SCIM(System for Cross-domain Identity Management)을 사용하여 다음을 자동화할 수 있습니다: GitLab SAML SSO SCIM은 사용자 업데이트를 지원하지 않습니다.

오픈 표준인 SCIM(System for Cross-domain Identity Management)을 사용하여 다음을 자동화할 수 있습니다:

  • 사용자 생성.
  • 사용자 제거(SCIM ID 비활성화).
  • 사용자 재추가(SCIM ID 재활성화).

GitLab SAML SSO SCIM은 사용자 업데이트를 지원하지 않습니다.

GitLab 그룹에 SCIM이 활성화되면 해당 그룹의 구성원이 GitLab과 ID 공급자 간에 동기화됩니다.

GitLab 그룹 SCIM 내부 APIRFC7644 프로토콜의 일부를 구현합니다. ID 공급자는 GitLab 그룹 SCIM 내부 API를 사용하여 SCIM 앱을 개발할 수 있습니다.

GitLab Self-Managed에서 SCIM을 설정하려면 GitLab Self-Managed에 대한 SCIM 구성을 참조하세요.

GitLab 구성#

사전 요구 사항:

GitLab SAML SSO SCIM을 구성하려면:

  1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Settings > SAML SSO를 선택합니다.
  3. Generate a SCIM token을 선택합니다.
  4. ID 공급자 구성을 위해 다음을 저장합니다:
    • Your SCIM token 필드의 토큰.
    • SCIM API endpoint URL 필드의 URL.

ID 공급자 구성#

GitLab은 여러 ID 공급자와 함께 SCIM을 지원합니다. 다른 공급자도 GitLab과 작동할 수 있지만 테스트되지 않았으며 지원되지 않습니다. 지원되지 않는 공급자에 대한 도움이 필요하면 해당 공급자에게 직접 문의하세요. GitLab 지원팀은 관련 로그 항목을 검토하여 도움을 드릴 수 있습니다.

Okta 구성#

Okta에 대한 싱글 사인온 설정 중에 생성된 SAML 애플리케이션은 SCIM을 위해 설정되어야 합니다.

사전 요구 사항:

  • Okta Lifecycle Management 제품을 사용해야 합니다. 이 제품 티어는 Okta에서 SCIM을 사용하는 데 필요합니다.
  • GitLab이 구성되어 있어야 합니다.
  • Okta에 대한 SAML 애플리케이션이 Okta 설정 노트에 설명된 대로 설정되어 있어야 합니다.
  • Okta SAML 설정이 NameID 구성을 포함하여 구성 단계와 정확히 일치해야 합니다.

Okta를 SCIM용으로 구성하려면:

  1. Okta에 로그인합니다.
  2. 오른쪽 상단에서 Admin을 선택합니다. 버튼은 Admin 영역에서는 보이지 않습니다.
  3. Application 탭에서 Browse App Catalog를 선택합니다.
  4. GitLab을 검색하고 GitLab 애플리케이션을 찾아 선택합니다.
  5. GitLab 애플리케이션 개요 페이지에서 Add를 선택합니다.
  6. Application Visibility에서 두 체크박스를 모두 선택합니다. 현재 GitLab 애플리케이션은 SAML 인증을 지원하지 않으므로 사용자에게 아이콘이 표시되지 않아야 합니다.
  7. Done을 선택하여 애플리케이션 추가를 완료합니다.
  8. Provisioning 탭에서 Configure API integration을 선택합니다.
  9. Enable API integration을 선택합니다.
    • Base URL에 GitLab SCIM 구성 페이지의 SCIM API endpoint URL에서 복사한 URL을 붙여넣습니다.
    • API Token에 GitLab SCIM 구성 페이지의 Your SCIM token에서 복사한 SCIM 토큰을 붙여넣습니다.
  10. 구성을 확인하려면 Test API Credentials를 선택합니다.
  11. Save를 선택합니다.
  12. API 통합 세부 정보를 저장한 후 왼쪽에 새 설정 탭이 나타납니다. To App을 선택합니다.
  13. Edit를 선택합니다.
  14. Create UsersDeactivate Users 모두에 대해 Enable 체크박스를 선택합니다.
  15. Save를 선택합니다.
  16. Assignments 탭에서 사용자를 할당합니다. 할당된 사용자는 GitLab 그룹에서 생성 및 관리됩니다.

Microsoft Entra ID 구성#

히스토리
  • GitLab 16.10에서 Microsoft Entra ID 용어로 변경되었습니다.

사전 요구 사항:

Azure Active Directory에 대한 싱글 사인온 설정 중에 생성된 SAML 애플리케이션은 SCIM을 위해 설정되어야 합니다. 예시는 구성 예시를 참조하세요.

Note

SCIM 프로비저닝은 다음 지침에 따라 정확하게 구성해야 합니다. 잘못 구성하면 사용자 프로비저닝 및 로그인에 문제가 발생하며, 이를 해결하는 데 많은 노력이 필요합니다. 단계에 문제나 질문이 있으면 GitLab 지원팀에 문의하세요.

Microsoft Entra ID를 SCIM용으로 구성하려면:

  1. 앱에서 Provisioning 탭으로 이동하여 Get started를 선택합니다.
  2. Provisioning ModeAutomatic으로 설정합니다.
  3. 다음 값을 사용하여 Admin Credentials를 완료합니다:
    • Tenant URL 필드에 GitLab의 SCIM API endpoint URL 값.
    • Secret Token 필드에 GitLab의 Your SCIM token 값.
  4. Test Connection을 선택합니다. 테스트가 성공하면 계속하기 전에 구성을 저장하거나 문제 해결 정보를 참조합니다.
  5. Save를 선택합니다.

저장 후 MappingsSettings 섹션이 나타납니다.

매핑 구성#

Mappings 섹션에서 먼저 그룹을 프로비저닝합니다:

  1. Provision Microsoft Entra ID Groups를 선택합니다.

  2. 속성 매핑 페이지에서 Enabled 토글을 끕니다. SCIM 그룹 프로비저닝은 GitLab에서 지원되지 않습니다. 그룹 프로비저닝을 활성화해도 SCIM 사용자 프로비저닝이 중단되지는 않지만 혼란스럽고 오해를 일으킬 수 있는 Entra ID SCIM 프로비저닝 로그에 오류가 발생합니다.

    [!note] Provision Microsoft Entra ID Groups가 비활성화되어 있어도 매핑 섹션에 "Enabled: Yes"가 표시될 수 있습니다. 이 동작은 안전하게 무시할 수 있는 표시 버그입니다.

  3. Save를 선택합니다.

다음으로 사용자를 프로비저닝합니다:

  1. Provision Microsoft Entra ID Users를 선택합니다.
  2. Enabled 토글이 Yes로 설정되어 있는지 확인합니다.
  3. 모든 Target Object Actions가 활성화되어 있는지 확인합니다.
  4. Attribute Mappings에서 구성된 속성 매핑과 일치하도록 매핑을 구성합니다:
    1. 선택 사항. customappsso Attribute 열에서 externalId를 찾아 삭제합니다.
    2. 다음을 포함하도록 첫 번째 속성을 편집합니다:
      • source attributeobjectId
      • target attributeexternalId
      • matching precedence1
    3. 기존 customappsso 속성을 구성된 속성 매핑과 일치하도록 업데이트합니다.
    4. 다음 표에 없는 추가 속성을 삭제합니다. 삭제하지 않아도 문제가 발생하지 않지만 GitLab은 해당 속성을 사용하지 않습니다.
  5. 매핑 목록 아래에서 Show advanced options 체크박스를 선택합니다.
  6. Edit attribute list for customappsso 링크를 선택합니다.
  7. id가 기본(primary) 및 필수 필드이고 externalId도 필수인지 확인합니다.
  8. Save를 선택하면 속성 매핑 구성 페이지로 돌아갑니다.
  9. Attribute Mapping 구성 페이지를 닫으려면 오른쪽 상단의 X를 선택합니다.

설정 구성#

Settings 섹션에서:

  1. 선택 사항. 원하는 경우 Send an email notification when a failure occurs 체크박스를 선택합니다.
  2. 선택 사항. 원하는 경우 Prevent accidental deletion 체크박스를 선택합니다.
  3. 필요한 경우 Save를 선택하여 모든 변경 사항이 저장되었는지 확인합니다.

매핑과 설정을 구성한 후, 앱 개요 페이지로 돌아가 Start provisioning을 선택하여 GitLab에서 사용자의 자동 SCIM 프로비저닝을 시작합니다.

Warning

동기화된 후에 idexternalId에 매핑된 필드를 변경하면 오류가 발생할 수 있습니다. 여기에는 프로비저닝 오류, 중복 사용자가 포함되며 기존 사용자가 GitLab 그룹에 액세스하지 못할 수도 있습니다.

속성 매핑 구성#

Note

Microsoft가 Azure Active Directory에서 Entra ID 명명 체계로 전환하는 동안 사용자 인터페이스에서 불일치가 나타날 수 있습니다. 문제가 있는 경우 이 문서의 이전 버전을 보거나 GitLab 지원팀에 문의할 수 있습니다.

SCIM용 Entra ID 구성 시 속성 매핑을 구성합니다. 예시는 구성 예시를 참조하세요.

다음 표는 GitLab에 필요한 속성 매핑을 제공합니다.

소스 속성 대상 속성 일치 우선순위
objectId externalId 1
userPrincipalName 또는 mail 1 emails[type eq "work"].value
mailNickname userName
displayName 또는 Join(" ", [givenName], [surname]) 2 name.formatted
Switch([IsSoftDeleted], , "False", "True", "True", "False") 3 active
  1. userPrincipalName이 이메일 주소가 아니거나 전달할 수 없는 경우 mail을 소스 속성으로 사용합니다.
  2. displayNameFirstname Lastname 형식과 일치하지 않는 경우 Join 표현식을 사용합니다.
  3. 이것은 직접 매핑이 아닌 표현식 매핑 유형입니다. Mapping type 드롭다운 목록에서 Expression을 선택합니다.

각 속성 매핑에는 다음이 있습니다:

  • 대상 속성에 해당하는 customappsso Attribute.
  • 소스 속성에 해당하는 Microsoft Entra ID Attribute.
  • 일치 우선순위.

각 속성에 대해:

  1. 기존 속성을 편집하거나 새 속성을 추가합니다.
  2. 드롭다운 목록에서 필요한 소스 및 대상 속성 매핑을 선택합니다.
  3. Ok를 선택합니다.
  4. Save를 선택합니다.

SAML 구성이 권장 SAML 설정과 다른 경우 매핑 속성을 선택하고 적절히 수정합니다. externalId 대상 속성에 매핑하는 소스 속성은 SAML NameID에 사용되는 속성과 일치해야 합니다.

매핑이 표에 없는 경우 Microsoft Entra ID 기본값을 사용합니다. 필수 속성 목록은 내부 그룹 SCIM API 문서를 참조하세요.

사용자 액세스#

동기화 프로세스 중에 모든 새 사용자는:

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

히스토리

제한된 액세스가 활성화되고 구독 시트가 없는 경우, SCIM을 통해 프로비저닝된 사용자에게 최소 액세스 권한이 할당됩니다.

이런 경우 사용자는 최소 액세스(응답 HTTP 201 Created)로 성공적으로 생성되며, 사용자의 roles 속성이 이 할당을 반영합니다. 사용 가능한 시트가 없는 경우 후속 권한 업데이트 작업이 실패할 수 있습니다.

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

다음 다이어그램은 SCIM 앱에 사용자를 추가할 때 발생하는 일을 설명합니다:

Mermaid 다이어그램 (13줄)
소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
accTitle: Adding users to your SCIM application
accDescr: How GitLab determines whether or not to associate a SCIM identity with a user.

A[Add User to SCIM app] -->|IdP sends user info to GitLab| B(GitLab: Does the email exist?) B -->|No| C[GitLab creates user with SCIM identity] B -->|Yes| D(GitLab: Is the user part of the group?) D -->|No| E(GitLab: Is SSO enforcement enabled?) E -->|No| G E -->|Yes| F[GitLab sends message back: The member's email address is not linked to a SAML account] D -->|Yes| G[Associate SCIM identity to user]

프로비저닝 중:

  • GitLab 사용자 계정이 존재하는지 확인할 때 기본 및 보조 이메일이 모두 고려됩니다.
  • 중복 사용자 이름은 사용자를 생성할 때 접미사 1을 추가하여 처리됩니다. 예를 들어 test_user가 이미 존재하면 test_user1이 사용됩니다. test_user1이 이미 존재하면 GitLab은 사용되지 않은 사용자 이름을 찾기 위해 접미사를 증가시킵니다. 4번 시도 후 사용되지 않은 사용자 이름을 찾을 수 없으면 사용자 이름에 임의의 문자열이 첨부됩니다.

이후 방문 시 신규 및 기존 사용자는 다음을 통해 그룹에 액세스할 수 있습니다:

  • ID 공급자의 대시보드.
  • 링크에 직접 방문.

권한 정보는 그룹 SAML 페이지를 참조하세요.

GitLab 그룹에 대한 SCIM을 통해 생성된 사용자의 비밀번호#

GitLab은 모든 사용자 계정에 비밀번호가 필요합니다. SCIM 프로비저닝을 사용하여 생성된 사용자의 경우, GitLab이 자동으로 임의의 비밀번호를 생성하므로 첫 번째 로그인 중에 비밀번호를 설정할 필요가 없습니다. GitLab이 GitLab 그룹에 대한 SCIM을 통해 생성된 사용자의 비밀번호를 생성하는 방법에 대한 자세한 내용은 통합 인증을 통해 생성된 사용자의 생성된 비밀번호를 참조하세요.

SCIM 및 SAML ID 연결#

그룹 SAML이 구성되어 있고 기존 GitLab.com 계정이 있는 경우, 사용자는 SCIM 및 SAML ID를 연결할 수 있습니다. 동기화가 활성화되면 기존 사용자에 대한 프로비저닝 오류가 발생할 수 있으므로 사용자는 동기화가 켜지기 전에 이 작업을 수행해야 합니다.

SCIM 및 SAML ID를 연결하려면:

  1. GitLab.com 사용자 계정의 기본 이메일 주소를 ID 공급자의 사용자 프로필 이메일 주소와 일치하도록 업데이트합니다.
  2. SAML ID를 연결합니다.

액세스 제거#

ID 공급자에서 사용자를 제거하거나 비활성화하여 다음에 대한 액세스를 제거합니다:

  • 최상위 그룹.
  • 모든 서브그룹 및 프로젝트.

ID 공급자가 구성된 일정에 따라 동기화를 수행하면 사용자의 구성원 자격이 취소되고 액세스 권한을 잃습니다.

SCIM을 활성화해도 SAML ID가 없는 기존 사용자가 자동으로 제거되지 않습니다.

Note

프로비저닝 해제는 GitLab 사용자 계정을 삭제하지 않습니다.

Mermaid 다이어그램 (8줄)
소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
accTitle: Deprovisioning users
accDescr: How removing users from your SCIM app removes them from GitLab groups.

A[Remove User from SCIM app] -->|IdP sends request to GitLab| B(GitLab: Is the user part of the group?) B -->|No| C[Nothing to do] B -->|Yes| D[GitLab removes user from GitLab group]

액세스 재활성화#

히스토리
  • GitLab 16.0에서 skip_saml_identity_destroy_during_scim_deprovision이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
  • GitLab 16.4에서 일반 제공(Generally available)됩니다. 기능 플래그 skip_saml_identity_destroy_during_scim_deprovision이 제거됩니다.

SCIM을 통해 사용자가 제거되거나 비활성화된 후, SCIM ID 공급자에 다시 추가하여 해당 사용자를 재활성화할 수 있습니다.

ID 공급자가 구성된 일정에 따라 동기화를 수행하면 사용자의 SCIM ID가 재활성화되고 그룹 구성원 자격이 복원됩니다.