GitLab.comグループのSCIMを設定する

オープンスタンダードのSystem for Cross-domain Identity Management（SCIM）を使用して、以下を自動的に実行できます:

• ユーザーを作成します。
• ユーザーを削除します（SCIMアイデンティティを無効化）。
• ユーザーを再追加します（SCIMアイデンティティを再アクティブ化）。

GitLab SAML SSO SCIMは、ユーザーの更新をサポートしていません。

SCIMがGitLabグループで有効になっている場合、そのグループのグループメンバーシップは、GitLabとIdentity Provider間で同期されます。

内部GitLabグループSCIM APIは、RFC7644プロトコルの一部を実装しています。Identity Providerは、内部GitLabグループSCIM APIを使用してSCIMアプリを開発できます。

GitLab Self-ManagedでSCIMをセットアップするには、GitLab Self-ManagedのSCIMを設定を参照してください。

GitLabを設定する

前提条件:

• グループシングルサインオンを設定する必要があります。

GitLab SAML SSO SCIMを設定するには:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 設定 > SAML SSOを選択します。
3. SCIMトークンを生成を選択します。
4. Identity Providerの設定については、以下を保存します:
   • あなたのSCIMトークンフィールドからトークン。
   • SCIM APIエンドポイントのURLフィールドからURL。

Identity Providerを設定する

次のいずれかをIdentity Providerとして設定できます:

• Azure Active Directory。
• Okta。

Microsoft Entra ID（以前のAzure Active Directory）を設定する

前提条件:

• GitLabが設定されています。
• グループシングルサインオンが設定されています。

シングルサインオンのセットアップ中に作成されたAzure Active Directory用のSAMLアプリケーションは、SCIM用に設定する必要があります。例については、設定例を参照してください。

Microsoft Entra IDのSCIMを設定するには:

1. アプリで、Provisioningタブに移動し、始めましょうを選択します。
2. Provisioning ModeをAutomaticに設定します。
3. Admin Credentialsを次の値を使用して完了します:
   • Tenant URLフィールドについては、GitLabのSCIM APIエンドポイントのURL。
   • Secret Tokenフィールドについては、GitLabのあなたのSCIMトークン。
4. Test Connectionを選択します。テストが成功した場合は、続行する前に設定を保存するか、トラブルシューティング情報を参照してください。
5. Saveを選択します。

保存後、Mappingsと設定セクションが表示されます。

マッピングを設定する

Mappingsセクションで、まずグループをプロビジョニングします:

1. Provision Microsoft Entra ID Groupsを選択します。

2. 属性マッピングページで、有効切替をオフにします。SCIMグループプロビジョニングはGitLabではサポートされていません。グループプロビジョニングを有効のままにしてもSCIMユーザープロビジョニングが中断されることはありませんが、Entra ID SCIMプロビジョニングログで混乱や誤解を招くようなエラーが発生する可能性があります。

   Provision Microsoft Entra ID Groupsが無効になっている場合でも、マッピングセクションには「有効: 可能」と表示される場合があります。この動作は、安全に無視できる表示バグです。

3. Saveを選択します。

次に、ユーザーをプロビジョニングします:

1. Provision Microsoft Entra ID Usersを選択します。
2. 有効切替が可能に設定されていることを確認します。
3. すべてのTarget Object Actionsが有効になっていることを確認します。
4. Attribute Mappingsで、設定済みの属性マッピングと一致するようにマッピングを設定します:
   1. オプション。オプション。customappsso AttributeカラムでexternalIdを見つけて削除します。
   2. 最初の属性を次のように編集します:
      • source attributeはobjectId
      • target attributeはexternalId
      • matching precedenceは1
   3. 既存のcustomappsso属性を設定済みの属性マッピングと一致するように更新します。
   4. 次の表に記載されていない追加の属性をすべて削除します。削除しなくても問題は発生しませんが、GitLabはこれらの属性を使用しません。
5. マッピングリストで、Show advanced optionsチェックボックスを選択します。
6. Edit attribute list for customappssoリンクを選択します。
7. idがプライマリで必須フィールドであり、externalIdも必須であることを確認します。
8. 保存を選択すると、属性マッピング設定ページに戻ります。
9. Attribute Mapping設定ページを閉じるには、右上隅のXを選択します。

設定を設定する

設定セクションで:

1. オプション。オプション。必要に応じて、Send an email notification when a failure occursチェックボックスを選択します。
2. オプション。オプション。必要に応じて、Prevent accidental deletionチェックボックスを選択します。
3. 必要な場合は、すべての変更が保存されていることを確認するために保存を選択します。

マッピングと設定を設定したら、アプリの概要ページに戻り、Start provisioningを選択して、GitLabでのユーザーの自動SCIMプロビジョニングを開始します。

属性マッピングを設定する

Entra IDのSCIMを設定する際に、属性マッピングを設定します。例については、設定例を参照してください。

次の表は、GitLabに必要な属性マッピングを示しています。

1. userPrincipalNameがメールアドレスではないか、配信可能ではない場合は、mailをソース属性として使用します。
2. displayNameがFirstname Lastnameの形式と一致しない場合は、Join式を使用します。
3. これは式マッピングタイプであり、直接マッピングではありません。Mapping typeドロップダウンリストでExpressionを選択します。

各属性マッピングには以下があります:

• customappsso Attributeは、target attributeに対応します。
• Microsoft Entra ID Attributeは、source attributeに対応します。
• 照合の優先順位。

各属性について:

1. 既存の属性を編集するか、新しい属性を追加します。
2. ドロップダウンリストから、必要なソースとターゲット属性マッピングを選択します。
3. OKを選択します。
4. Saveを選択します。

SAML設定が推奨されるSAML設定と異なる場合は、マッピング属性を選択し、それに応じて変更します。externalIdターゲット属性にマップするソース属性は、SAML NameIDに使用される属性と一致する必要があります。

マッピングがリストにない場合は、Microsoft Entra IDのデフォルトを使用します。必須属性のリストについては、内部グループSCIM APIドキュメントを参照してください。

Oktaを設定する

シングルサインオンのセットアップ中に作成されたOkta用のSAMLアプリケーションは、SCIM用に設定する必要があります。

前提条件:

• Okta Lifecycle Management製品を使用する必要があります。この製品ティアは、OktaでSCIMを使用するために必要です。
• GitLabが設定されています。
• Oktaのセットアップノートに記載されているとおりに設定されたOkta用のSAMLアプリケーション。
• OktaのSAMLセットアップは、設定手順、特にNameID設定と完全に一致します。

OktaのSCIMを設定するには:

1. Oktaにサインインします。
2. 右上隅で、管理者を選択します。ボタンは管理者エリアからは表示されません。
3. Applicationタブで、Browse App Catalogを選択します。
4. GitLabを検索し、GitLabアプリケーションを見つけて選択します。
5. GitLabアプリケーションの概要ページで、追加を選択します。
6. Application Visibilityで両方のチェックボックスを選択します。現在、GitLabアプリケーションはSAML認証をサポートしていないため、アイコンはユーザーに表示されるべきではありません。
7. 完了を選択して、アプリケーションの追加を完了します。
8. Provisioningタブで、Configure API integrationを選択します。
9. Enable API integrationを選択します。
   • Base URLには、GitLab SCIM設定ページでSCIM APIエンドポイントのURLからコピーしたURLを貼り付けます。
   • API Tokenには、GitLab SCIM設定ページであなたのSCIMトークンからコピーしたSCIMトークンを貼り付けます。
10. 設定を確認するには、Test API Credentialsを選択します。
11. Saveを選択します。
12. 保存後、APIインテグレーションの詳細に、新しい設定タブが左側に表示されます。To Appを選択します。
13. 編集を選択します。
14. Create UsersとDeactivate Usersの両方のチェックボックスで有効を選択します。
15. Saveを選択します。
16. 割り当てタブでユーザーを割り当てます。割り当てられたユーザーは、GitLabグループで作成および管理されます。

ユーザーアクセス

同期プロセス中に、すべての新しいユーザーは次のようになります:

• GitLabアカウントを受け取ります。
• 招待メールでグループに歓迎されます。メール確認を確認済みのドメインでバイパスすることができます。

プロビジョニングの動作（制限付きアクセス）

制限付きアクセスが有効でサブスクリプションシートが利用可能でない場合、SCIMを通じてプロビジョニングされたユーザーには最小アクセスロールが割り当てられます。

これが発生すると、ユーザーはMinimal Access（レスポンスHTTP 201 Created）で正常に作成され、ユーザーのroles属性にこの割り当てが反映されます。その後のロール更新操作は、シートが利用可能でない場合、失敗する可能性があります。

詳細については、SAML、SCIM、およびLDAPによるプロビジョニングの動作を参照してください。

次の図は、SCIMアプリにユーザーを追加したときに発生することを説明しています:

%%{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回試行しても未使用のユーザー名が見つからない場合、ランダムな文字列がユーザー名に付加されます。

その後の訪問では、新規および既存のユーザーは次のいずれかの方法でグループにアクセスできます:

• Identity Providerのダッシュボードを介して。
• リンクを直接訪問して。

ロール情報については、グループSAMLページを参照してください。

GitLabグループのSCIMを通じて作成されたユーザーのパスワード

GitLabはすべてのユーザーアカウントにパスワードを要求します。SCIMプロビジョニングを使用して作成されたユーザーの場合、GitLabは自動的にランダムなパスワードを生成し、ユーザーは最初のサインイン時にパスワードを設定する必要はありません。GitLabグループのSCIMを通じて作成されたユーザーのパスワードをGitLabがどのように生成するかについての詳細は、統合認証を通じて作成されたユーザーの生成されたパスワードを参照してください。

SCIMおよびSAMLアイデンティティをリンクする

グループSAMLが設定されており、既存のGitLab.comアカウントがある場合、ユーザーはSCIMおよびSAMLアイデンティティをリンクできます。同期がオンになる前に、ユーザーはこれを実行する必要があります。これは、同期がアクティブな場合に、既存のユーザーに対してプロビジョニングエラーが発生する可能性があるためです。

SCIMおよびSAMLアイデンティティをリンクするには:

1. GitLab.comユーザーアカウントのプライマリメールアドレスを、Identity Providerのユーザープロファイルメールアドレスと一致するように更新します。
2. あなたのSAMLアイデンティティをリンクします。

アクセスを削除する

Identity Providerでユーザーを削除または無効にすると、そのユーザーの次のものへのアクセスが削除されます:

• トップレベルグループ。
• すべてのサブグループとプロジェクト。

Identity Providerが設定されたスケジュールに基づいて同期を実行すると、ユーザーのメンバーシップは失効するし、アクセスを失います。

SCIMを有効にしても、SAMLアイデンティティを持たない既存のユーザーが自動的に削除されることはありません。

%%{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]

アクセスを再アクティブ化する

SCIMを通じてユーザーが削除または無効にされた後、そのユーザーをSCIM Identity Providerに追加することで再アクティブ化できます。

Identity Providerが設定されたスケジュールに基づいて同期を実行すると、ユーザーのSCIMアイデンティティは再アクティブ化され、グループメンバーシップは復元されます。