GitLab Self-Managed 또는 GitLab Dedicated에 대한 SCIM 구성
Offering: GitLab Self-Managed, GitLab Dedicated
SCIM(System for Cross-domain Identity Management) 공개 표준을 사용하여 자동으로 다음을 수행할 수 있습니다: GitLab 내부 SCIM API는 RFC7644 프로토콜의 일부를 구현합니다.
SCIM(System for Cross-domain Identity Management) 공개 표준을 사용하여 자동으로 다음을 수행할 수 있습니다:
- 사용자 생성.
- 사용자 차단.
- 사용자 다시 추가 (SCIM 아이덴티티 재활성화).
GitLab 내부 SCIM API는 RFC7644 프로토콜의 일부를 구현합니다.
GitLab.com 사용자인 경우 GitLab.com 그룹에 대한 SCIM 구성을 참조하세요.
GitLab 구성#
사전 요구 사항:
- SAML 싱글 사인온 구성.
- 관리자 접근 권한.
GitLab SCIM을 구성하려면:
- 오른쪽 상단 모서리에서 Admin을 선택합니다.
- 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
- SCIM 토큰 섹션을 펼치고 SCIM 토큰 생성을 선택합니다.
- ID 공급자 구성을 위해 다음을 저장합니다:
- Your SCIM token 필드의 토큰.
- SCIM API endpoint URL 필드의 URL.
ID 공급자 구성#
GitLab은 여러 ID 공급자와 함께 SCIM을 지원합니다. 다른 ID 공급자도 GitLab과 작동할 수 있지만 테스트되지 않았으며 지원되지 않습니다. 지원되지 않는 공급자에 대한 도움은 공급자에게 직접 문의하세요. GitLab 지원팀은 관련 로그 항목 검토를 도와드릴 수 있습니다.
Okta 구성#
Okta에 대해 싱글 사인온 설정 중에 만든 SAML 애플리케이션이 SCIM용으로 설정되어야 합니다.
사전 요구 사항:
- Okta Lifecycle Management 제품을 사용해야 합니다. Okta에서 SCIM을 사용하려면 이 제품 티어가 필요합니다.
- SCIM을 위해 GitLab이 구성되어 있어야 합니다.
- Okta SAML 설정 참고사항에 설명된 대로 Okta용 SAML 애플리케이션이 설정되어 있어야 합니다.
- Okta SAML 설정이 특히 NameID 구성에 대해 구성 단계와 일치해야 합니다.
Okta를 SCIM용으로 구성하려면:
- Okta에 로그인합니다.
- 오른쪽 상단 모서리에서 Admin을 선택합니다. 이 버튼은 Admin 영역에서는 표시되지 않습니다.
- Application 탭에서 Browse App Catalog를 선택합니다.
- GitLab 애플리케이션을 찾아 선택합니다.
- GitLab 애플리케이션 개요 페이지에서 Add Integration을 선택합니다.
- Application Visibility에서 두 체크박스를 모두 선택합니다. GitLab 애플리케이션은 SAML 인증을 지원하지 않으므로 아이콘이 사용자에게 표시되지 않아야 합니다.
- Done을 선택하여 애플리케이션 추가를 완료합니다.
- Provisioning 탭에서 Configure API integration을 선택합니다.
- Enable API integration을 선택합니다.
- Base URL에 GitLab SCIM 구성 페이지의 SCIM API endpoint URL에서 복사한 URL을 붙여넣습니다.
- API Token에 GitLab SCIM 구성 페이지의 Your SCIM token에서 복사한 SCIM 토큰을 붙여넣습니다.
- 구성을 확인하려면 Test API Credentials를 선택합니다.
- Save를 선택합니다.
- API 통합 세부 정보를 저장한 후 왼쪽에 새 설정 탭이 나타납니다. To App을 선택합니다.
- Edit을 선택합니다.
- Create Users 및 Deactivate Users 모두에 대해 Enable 체크박스를 선택합니다.
- Save를 선택합니다.
- Assignments 탭에서 사용자를 할당합니다. 할당된 사용자는 GitLab 그룹에서 생성되고 관리됩니다.
Microsoft Entra ID 구성#
히스토리
- GitLab 16.10에서 Microsoft Entra ID 용어로 변경.
사전 요구 사항:
- SCIM을 위해 GitLab이 구성되어 있어야 합니다.
- Microsoft Entra ID용 SAML 애플리케이션이 설정되어 있어야 합니다.
Azure Active Directory에 대한 싱글 사인온 설정 중에 만든 SAML 애플리케이션이 SCIM용으로 설정되어야 합니다. 예시를 보려면 예시 구성을 참조하세요.
다음 지침에 자세히 설명된 대로 정확하게 SCIM 프로비저닝을 구성해야 합니다. 잘못 구성하면 사용자 프로비저닝 및 로그인 문제가 발생하며, 이를 해결하는 데 많은 노력이 필요합니다. 어떤 단계에서든 문제나 질문이 있으면 GitLab 지원팀에 문의하세요.
Microsoft Entra ID를 구성하려면 다음을 구성합니다:
- SCIM을 위한 Microsoft Entra ID.
- 설정.
- 속성 매핑을 포함한 매핑.
SCIM을 위한 Microsoft Entra ID 구성#
-
앱에서 Provisioning 탭으로 이동하고 Get started를 선택합니다.
-
Provisioning Mode를 Automatic으로 설정합니다.
-
다음 값을 사용하여 Admin Credentials를 완성합니다:
- GitLab의 SCIM API endpoint URL을 Tenant URL 필드에 입력합니다.
- GitLab의 Your SCIM token을 Secret Token 필드에 입력합니다.
-
Test Connection을 선택합니다.
테스트가 성공하면 구성을 저장합니다.
테스트가 실패하면 이를 해결하기 위해 문제 해결을 참조하세요.
-
Save를 선택합니다.
저장한 후 Mappings 및 Settings 섹션이 나타납니다.
매핑 구성#
Mappings 섹션에서 먼저 그룹을 프로비저닝합니다:
-
Provision Microsoft Entra ID Groups를 선택합니다.
-
속성 매핑 페이지에서 Enabled 토글을 끕니다.
SCIM 그룹 프로비저닝은 GitLab에서 지원되지 않습니다. 그룹 프로비저닝을 활성화한 채로 두면 SCIM 사용자 프로비저닝이 중단되지 않지만, 혼란스럽고 오해의 소지가 있는 Entra ID SCIM 프로비저닝 로그에 오류가 발생합니다.
[!note] Provision Microsoft Entra ID Groups를 비활성화해도 매핑 섹션에 Enabled: Yes가 표시될 수 있습니다. 이 동작은 안전하게 무시할 수 있는 디스플레이 버그입니다.
-
Save를 선택합니다.
다음으로 사용자를 프로비저닝합니다:
- Provision Microsoft Entra ID Users를 선택합니다.
- Enabled 토글이 Yes로 설정되어 있는지 확인합니다.
- 모든 Target Object Actions가 활성화되어 있는지 확인합니다.
- Attribute Mappings에서 구성된 속성 매핑과 일치하도록 매핑을 구성합니다:
- 매핑 목록 아래에서 Show advanced options 체크박스를 선택합니다.
- Edit attribute list for customappsso 링크를 선택합니다.
id가 기본 및 필수 필드이고externalId도 필수인지 확인합니다.- Save를 선택하면 속성 매핑 구성 페이지로 돌아갑니다.
- 속성 매핑 구성 페이지를 닫으려면 오른쪽 상단 모서리에서
X를 선택합니다.
속성 매핑 구성#
Microsoft가 Azure Active Directory에서 Entra ID 명명 체계로 전환하는 동안 사용자 인터페이스에 불일치가 있을 수 있습니다. 문제가 있으면 이 문서의 이전 버전을 보거나 GitLab 지원팀에 문의하세요.
SCIM을 위한 Entra ID를 구성하는 동안 속성 매핑을 구성합니다. 예시를 보려면 예시 구성을 참조하세요.
다음 표에서는 GitLab에 필요한 속성 매핑을 제공합니다.
| 소스 속성 | 대상 속성 | 매핑 우선순위 |
|---|---|---|
objectId |
externalId |
1 |
userPrincipalName OR mail 1 |
emails[type eq "work"].value |
|
mailNickname |
userName |
|
displayName OR Join(" ", [givenName], [surname]) 2 |
name.formatted |
|
Switch([IsSoftDeleted], , "False", "True", "True", "False") 3 |
active |
각주:
userPrincipalName이 이메일 주소가 아니거나 전달 불가능한 경우mail을 소스 속성으로 사용합니다.displayName이Firstname Lastname형식과 일치하지 않는 경우Join표현식을 사용합니다.- 이것은 직접 매핑이 아닌 표현식 매핑 유형입니다. Mapping type 드롭다운 목록에서 Expression을 선택합니다.
각 속성 매핑에는 다음이 있습니다:
- 대상 속성에 해당하는 customappsso 속성.
- 소스 속성에 해당하는 Microsoft Entra ID 속성.
- 매핑 우선순위.
각 속성에 대해:
- 기존 속성을 편집하거나 새 속성을 추가합니다.
- 드롭다운 목록에서 필요한 소스 및 대상 속성 매핑을 선택합니다.
- Ok를 선택합니다.
- Save를 선택합니다.
SAML 구성이 권장 SAML 설정과 다른 경우, 매핑 속성을 선택하고 그에 맞게 수정하세요.
externalId 대상 속성에 매핑하는 소스 속성은 SAML NameID에 사용되는 속성과 일치해야 합니다.
표에 나열되지 않은 매핑의 경우 Microsoft Entra ID 기본값을 사용합니다. 필수 속성 목록은 내부 인스턴스 SCIM API 문서를 참조하세요.
설정 구성#
Settings 섹션에서:
- 선택 사항. 원하는 경우 Send an email notification when a failure occurs 체크박스를 선택합니다.
- 선택 사항. 원하는 경우 Prevent accidental deletion 체크박스를 선택합니다.
- 필요한 경우 Save를 선택하여 모든 변경 사항이 저장되었는지 확인합니다.
매핑 및 설정을 구성한 후 앱 개요 페이지로 돌아가 Start provisioning을 선택하여 GitLab에서 사용자의 자동 SCIM 프로비저닝을 시작합니다.
동기화된 후 id 및 externalId에 매핑된 필드를 변경하면 오류가 발생할 수 있습니다. 여기에는
프로비저닝 오류, 중복 사용자가 포함되며 기존 사용자가 GitLab 그룹에 접근하지 못할 수 있습니다.
접근 권한 제거#
ID 공급자에서 사용자를 제거하거나 비활성화하면 GitLab 인스턴스에서 사용자가 차단되며, SCIM 아이덴티티는 GitLab 사용자에게 연결된 상태로 유지됩니다.
사용자 SCIM 아이덴티티를 업데이트하려면 GitLab 내부 SCIM API를 사용하세요.
접근 권한 재활성화#
히스토리
SCIM을 통해 사용자가 제거되거나 비활성화된 후 SCIM ID 공급자에 추가하여 해당 사용자를 재활성화할 수 있습니다.
ID 공급자가 구성된 일정에 따라 동기화를 수행하면 사용자의 SCIM 아이덴티티가 재활성화되고 GitLab 인스턴스 접근이 복원됩니다.
SCIM을 사용한 그룹 동기화#
히스토리
- GitLab 18.0에서
self_managed_scim_group_sync라는 플래그와 함께 도입. 기본적으로 비활성화. - GitLab 18.2에서 GitLab Self-Managed에서 기본적으로 활성화.
- GitLab 18.6에서 일반 공개. 기능 플래그
self_managed_scim_group_sync제거.
사용자 프로비저닝 외에도 SCIM을 사용하여 ID 공급자와 GitLab 간의 그룹 멤버십을 동기화할 수 있습니다. 이 방법을 사용하면 ID 공급자의 그룹 멤버십을 기반으로 GitLab 그룹에서 사용자를 자동으로 추가하거나 제거할 수 있습니다.
사전 요구 사항:
- SAML 그룹 링크를 먼저 구성해야 합니다.
- ID 공급자의 SAML 그룹 이름이 GitLab에 구성된 SAML 그룹 이름과 일치해야 합니다.
SCIM 그룹 동기화는 SAML 그룹 링크와 함께 작동하여 그룹 멤버십을 관리합니다. ID 공급자가 SCIM API를 통해 그룹 멤버십 변경 사항을 전송하면 GitLab은 해당 SCIM 그룹과 연결된 SAML 그룹 링크가 있는 모든 GitLab 그룹에서 사용자 멤버십을 업데이트합니다.
SCIM은 단방향 프로토콜입니다: 변경 사항은 ID 공급자에서 GitLab으로 흐릅니다. GitLab에서 SAML 그룹 링크를 변경하면 (추가하거나 제거하는 등) ID 공급자는 SCIM을 통해 이러한 변경 사항을 감지할 방법이 없습니다.
새 그룹 링크의 알려진 제한 사항#
ID 공급자가 SCIM 그룹을 처음 프로비저닝할 때 (POST /Groups를 통해), GitLab은 SCIM 그룹 ID를 일치하는 그룹 이름을 가진 모든 기존 SAML 그룹 링크와 연결합니다.
그러나 초기 프로비저닝 후에 동일한 그룹 이름을 가진 새 SAML 그룹 링크를 추가하면
새 그룹 링크가 자동으로 SCIM 그룹 ID와 연결되지 않습니다.
이는 ID 공급자의 SCIM 멤버십 업데이트가 새로 추가된 그룹 링크의 사용자에게 영향을 미치지 않음을 의미합니다.
개선 지원은 이슈 582729에서 제안되어 있습니다.
처음부터 모든 그룹 링크가 SCIM 그룹과 연결되도록 하려면 ID 공급자에서 SCIM 그룹 프로비저닝을 설정하기 전에 모든 SAML 그룹 링크를 구성해야 합니다.
초기 프로비저닝 후에 그룹 링크를 추가해야 하는 경우, SCIM 그룹 프로비저닝 (IdP 그룹 자체가 아님)을 삭제한 다음 다시 생성하여 ID 공급자에서 SCIM 그룹을 다시 프로비저닝할 수 있습니다. 이 작업은 현재의 모든 SAML 그룹 링크를 SCIM 그룹과 다시 연결합니다. 자세한 내용은 SCIM 그룹 프로비저닝 관리에 대한 ID 공급자의 문서를 참조하세요.
GitLab에서 SAML 그룹 링크를 삭제하면 해당 링크를 통한 그룹 멤버가 그룹에 남아 있습니다. 그러나 그룹 링크가 제거되었으므로 SCIM은 더 이상 해당 그룹에서의 멤버십을 관리하지 않습니다. 필요한 경우 수동으로 그룹에서 멤버를 제거할 수 있습니다.
ID 공급자에서 그룹 동기화 구성#
ID 공급자에서 그룹 동기화를 구성하는 자세한 지침은 공급자의 문서를 참조하세요. 아래 예시:
- Okta Groups API
- Microsoft Entra ID (Azure AD) SCIM Groups
- 기본적으로
displayName소스 속성은 사용자 친화적인 이름을 가진 SAML 그룹 링크를 찾는 데 사용됩니다. - 그러나 SAML 그룹 링크가 이름에 개체 ID를 사용하는 경우 소스 속성을objectId로 업데이트해야 합니다.
여러 SAML 그룹 링크가 동일한 GitLab 그룹에 매핑되는 경우, 사용자는 모든 매핑 그룹 링크에서 가장 높은 권한을 할당받습니다. IdP 그룹에서 제거된 사용자는 해당 그룹에 연결된 다른 SAML 그룹에 속해 있으면 GitLab 그룹에 남아 있습니다.
Okta 애플리케이션 카탈로그의 표준 GitLab SCIM 애플리케이션은 그룹 동기화를 지원하지 않습니다. 대신 Okta를 사용한 그룹 동기화를 위한 사용자 정의 SCIM 통합을 만들 수 있습니다. 자세한 내용은 이슈 582729를 참조하세요.
문제 해결#
SCIM 문제 해결 가이드를 참조하세요.
