# SCIMを使用したAPIのプロビジョニング

## SCIMとは

**クロスドメインID管理システム (System for Cross-domain Identity Management: SCIM)** は、IDドメイン間またはITシステム間でユーザーID情報のやりとりを自動化するために作られた規格です。

Okta、Entra ID / Azure AD、Google G Suite、JumpCloudなど、一般的なIDプロバイダ (IdP) ではチームおよびユーザーをKeeperエンタープライズにプロビジョニングする際にSCIMを使用できます。その呼び方はプラットフォームによって異なりますが、OktaやAzureでは「自動プロビジョニング」と呼ばれています。

SailPointなど他のIDマネジメント製品でもSCIM2.0でのユーザーの自動プロビジョニングに対応しています。

KeeperはJSONメッセージ構造を使用したRESTベースのAPIであるSCIM 2.0に対応しています。 KeeperのSCIMエンドポイントはユーザーグループのリソース、および以下のメッセージタイプに対応しています。

**ユーザー/チームのプロビジョニング**

* ユーザー/チーム情報の取得
* ユーザー/チームの追加
* ユーザー/チームプロファイルの更新
* ユーザー/チームの削除

{% hint style="info" %}
Keeper SCIM Restエンドポイントとは、<http://keepersecurity.com/api/rest/scim/v2/>\<node\_id>で利用可能なリソースです。ここでのnode\_idは、SCIMプロトコル同期で使用するKeeperエンタープライズノードを特定します。
{% endhint %}

ユーザーは、同じベンダーまたは異なるベンダーからの異なるIDプロバイダ (Azure AD、Oktaディレクトリなど) と同期する複数のノードを持つことができます。ノードはIDプロバイダ毎に1つであり、親子関係はサポートされていません (つまり、あるノードでSCIMが設定されている場合、このノードのサブノードは統合管理されませんが、サブノード自身のプロバイダによって管理が可能です)。

認証はヘッダ認証で、ノードのセットアップ時にKeeperがトークンを生成します。

Keeper SCIMエンドポイントは以下のとおりユーザーとグループのリソースに対応しています。

<table><thead><tr><th width="253.5">リソース/メソッド</th><th>URLサンプル</th></tr></thead><tbody><tr><td>Users/GET</td><td><p>https://keepersecurity.com/api/rest/scim/v2/123/Users</p><p><br>ノード123のすべてのユーザーを返します</p></td></tr><tr><td>Users/GET</td><td><p>https://keepersecurity.com/api/rest/scim/v2/123/Users/456<br></p><p>ノード123のユーザー456を返し、見つからない場合は404を返します。</p></td></tr><tr><td>Users/POST</td><td><p>https://keepersecurity.com/api/rest/scim/v2/123/Users<br></p><p>リスエストのSCIMコンテンツ (<a href="https://tools.ietf.org/html/rfc7643#section-8.2">User</a>) を解析し、ユーザーをノード123に追加します。</p></td></tr><tr><td>Users/PATCH</td><td><p>https://keepersecurity.com/api/rest/scim/v2/123/Users/456<br></p><p>SCIMコンテンツ (<a href="https://tools.ietf.org/html/rfc7644#section-3.5.2">Operations</a>) を解析し、ユーザー456を、追加/削除操作で参照されるチームにグループとして追加または削除します。また「アクティブ」なプロパティを処理して、Keeperでユーザーをロックまたはロック解除することもできます。 参照されるチームは同じノードに属している必要があります。ユーザーが見つからない場合、404を返します。</p></td></tr><tr><td>Users/DELETE</td><td><p>https://keepersecurity.com/api/rest/scim/v2/123/Users/456</p><p>ノード123からユーザー456をロックします。ユーザーが見つからない場合、404を返します。</p><p><br>注: データの損失を防ぐため、アカウントを削除せずにロックします。管理者は、管理コンソールのインターフェースまたはCommander API内で、ユーザーを完全に削除できます。</p></td></tr><tr><td>Groups/GET</td><td><p>https://keepersecurity.com/api/rest/scim/v2/123/Groups</p><p>ノード123のすべてのチームを返します。</p></td></tr><tr><td>Groups/GET</td><td><p>https://keepersecurity.com/api/rest/scim/v2/123/Groups/789<br></p><p>ノード123のチーム789を返し、見つからない場合は404を返します。</p></td></tr><tr><td>Groups/POST</td><td><p>https://keepersecurity.com/api/rest/scim/v2/123/Groups<br></p><p>リスエストのSCIMコンテンツ (<a href="https://tools.ietf.org/html/rfc7643#section-8.4">Group</a>) を解析し、チームをノード123に追加します。</p></td></tr><tr><td>Groups/PATCH</td><td><p>https://keepersecurity.com/api/rest/scim/v2/123/Groups/789<br></p><p>SCIMコンテンツ (<a href="https://tools.ietf.org/html/rfc7644#section-3.5.2">Operations</a>) を解析し、追加/削除操作で参照されるユーザーを、チーム789に追加または削除します。参照されるユーザーは同じノードに属している必要があります。チームが見つからない場合、404を返します。</p></td></tr><tr><td>Groups/DELETE</td><td><p>https://keepersecurity.com/api/rest/scim/v2/123/Groups/789<br></p><p>ノード123からチーム789を削除します。チームが見つからない場合、404を返します。</p></td></tr><tr><td>ServiceProviderConfig/GET</td><td><p>https://keepersecurity.com/api/rest/scim/v2/123/ServiceProviderConfig<br></p><p>Keeper SCIMサービスのSCIMサービスプロバイダ構成を返します</p></td></tr></tbody></table>

## 除外される属性

<https://tools.ietf.org/html/rfc7644#section-3.4.2.5>に記載の仕様に従います。

Keeperは、members属性のexcludedAttributesに対応しています。多数のメンバーを含むグループとの作業パフォーマンスを向上するには、複数グループや単一グループへのSCIMクエリおよびグループへのPATCHクエリに対して以下のようなパラメータを追加できます。

```
?excludedAttributes=members
```

## ページネーション (ページ区切り)

<https://tools.ietf.org/html/rfc7644#section-3.4.2.4>に記載の仕様に従います。

デフォルトでは、Keeper SCIM APIは、大規模な結果を生成するクエリに対しては最初の1000件のエントリのみを返します。データセット全体にクエリを実行するには、仕様に従ってSCIMページネーションパラメータを使用します。ページネーションは、ユーザーおよびグループのGETリクエストで対応しています。

ページネーションを利用するには、リクエスト内で `startIndex` パラメータと `count` パラメータの指定が必要です。

## 一括操作

RFC 7644 セクション3.7に準拠し、Keeperは以下のURL構造を通じて一括API操作 (Bulk API Operations) をサポートしています。

`https://keepersecurity.com/api/rest/scim/v2/xxx/Bulk`

SCIMの一括操作はオプションのサーバー機能であり、クライアントが複数のリソース操作を1回のPOSTリクエストで送信できるようにします。

一括操作の本文には、APIでサポートされているHTTPメソッド (POST、PUT、PATCH、DELETEのいずれか) を使用したHTTPリソース操作のセットが含まれます。

現在の制限値は、`/ServiceProviderConfig` リクエストのレスポンスから確認できます。

`... "bulk": { "supported": true, "maxOperations": 1000, "maxPayloadSize": 1048576 }, ...`

これら3つのパラメータは、`SCIM_BULK_SUPPORTED`、`SCIM_BULK_MAX_OPERATIONS`、`SCIM_BULK_MAX_PAYLOAD_SIZE` のプロパティから設定されます。

循環参照を含む一括操作はサポートしていません。その場合、HTTPステータスコード409 (Conflict) が返されます。

## セキュリティ

セキュリティ上の理由により、SCIMによるプロビジョニングは、対象のメールドメインがエンタープライズテナントに予約されている場合にのみ処理されます。たとえば、`example.com`ドメインのメールアドレスをプロビジョニングする場合、そのドメインは該当のテナントに予約されている必要があります。

ドメイン予約の手順については、[こちらのページ](https://docs.keeper.io/jp/enterprise-guide/domain-reservation)をご参照ください。

## 統合に関する注記

SCIM IDプロバイダは単一のノードに、プロバイダのユーザー名はKeeperのユーザー名 (メールアドレス) にマッピングされますので、Keeperのユーザー名はグローバルで固有である必要があります。したがって、すでに同じまたは別のKeeperエンタープライズアカウントのメンバーのメールアドレスによって定義されたユーザーがIDプロバイダに含まれている場合、そのユーザーをプロビジョニングしようとすると失敗します。そのユーザーがすでに同じノードのメンバーである場合に限り、プロビジョニングが成功し、IDプロバイダとKeeperの連携が確立します。\
\
問題を回避するため、IDプロバイダで使用する予定のユーザーと一致するKeeperのユーザーをすでに手動で作成済みである場合、プロバイダで統合を設定する前に、ユーザーを手動でSCIMノードへ移動しておきます。

ユーザーがプロビジョニングされる際、Keeper側ではユーザー名またはメールアドレスに有効なメールアドレスが含まれていることが必要となります。有効なメールアドレスが存在しない場合、プロビジョニングが拒否されることがあります (たとえば、Oktaではユーザー名を任意の文字列に設定することが可能で、メールアドレスは必須ではありません)。偽のメールアドレスであっても受け入れられますが、その場合、プロビジョニングされたユーザーは招待メールを受信できないため、結果としてエンタープライズに参加できなくなります。

## チームとユーザーの承認手順

SCIM同期によって追加された新しいユーザーは「招待済み」の状態で作成され、Keeperに参加するための招待メールが送信されます。SCIM同期によって作成された新しいチームは、「保留」の状態となり、Keeper管理者またはチームメンバーのいずれかによる最終承認が必要となります。

SCIM経由でチームに追加されたユーザーも「保留」の状態で追加され、承認が必要となります。管理者がKeeper管理コンソールにログインする際に、チームとユーザーの承認が自動的に行われます。 また、[Keeperオートメーターサービス](https://docs.keeper.io/keeper-sso-connect-r-cloud-jp/device-approvals/automator)や[Keeperコマンダー](https://app.gitbook.com/s/PL6k1aGsLiFiiJ3Y7zCl/commander-cli/command-reference/enterprise-management-commands#team-approve-command)を使用して承認処理を自動化することもできます。この承認処理は、暗号化キーが生成 (および共有) される必要があるためです。Keeperのゼロ知識環境では、Keeper管理者、別のチームメンバー、自動化サービスのどれかによってこの処理が実行される必要があります。必要に応じて、Keeperのサポート自動化サービスのインストールのお手伝いをさせていただきます。

## 固有のグループ名

デフォルトでは、グループ名が過去に使用された名前と同一であってもグループの作成が受け入れられます。

重複したグループ名による問題に遭遇した場合は、Keeperまでご連絡ください。ご利用のSCIM接続にフラグを設定して固有の名前が強制適用されるようにします。

{% hint style="info" %}
Keeperサポートまでご連絡いただけますと、ご利用のSCIMインスタンスで固有のグループ名が強制適用されるようにします。
{% endhint %}

{% content-ref url="approval-queue" %}
[approval-queue](https://docs.keeper.io/jp/enterprise-guide/user-and-team-provisioning/approval-queue)
{% endcontent-ref %}

## SCIMプッシュコマンド

SCIMはKeeperコマンダーSDKに統合されていますので、ユーザーとグループは任意のディレクトリソースからKeeper SCIMエンドポイントに直接プッシュできます。\
\
SCIM Pushコマンドの詳細については、[こちらのページ](https://app.gitbook.com/s/PL6k1aGsLiFiiJ3Y7zCl/commander-cli/command-reference/enterprise-management-commands/scim-push-configuration)をご覧ください。

## トラブルシューティングとヒント

* 管理コンソールでSCIMプロビジョニング方法を保存する前&#x306B;**\[テスト]**&#x30DC;タンをクリックした場合、テストは失敗します。まずトークンをコピーしてか&#x3089;**\[保存]**&#x3092;クリックしてください。
* Keeperユーザーはメールアドレスで識別されるため、割り当て時にユーザー名に有効なメールアドレスが含まれていることを確かにしてください。

### チームのプロビジョニングとチーム割り当て

ユーザーとチームのSCIMプロビジョニングを設定する際は以下を確認します。

* SCIMからユーザーを招待する際、そのユーザーがまだKeeper内に存在しない場合、サインアップの招待メールが送信されます (ジャストインタイミングプロビジョニングも使用できます)。
* ユーザーがKeeperのアカウントを作成した後は、以下のいずれかが発生するまでユーザーがKeeperのチームに割り当てられることはありません。\
  \
  (a) 管理者が管理コンソールにログインし、管理画面か&#x3089;**\[完全同期]**&#x3092;クリックする。\
  (b) 該当チームのユーザーがウェブボルトかデスクトップアプリにログインする。\
  (c) 管理者がKeeperコマンダーからチーム承認を行う。\
  (d) Keeperオートメーターサービスで承認を行う。\
  \
  SCIM経由でチームとユーザーを即座に作成できない理由は、暗号化モデルおよびユーザー間で秘密鍵を共有する必要があるためです。暗号化キー (チームキーなど) は、ログイン状態で必要な秘密鍵にアクセスできるユーザーによってしか共有できません。
* この処理を簡潔にするため、バージョン3.2以降のKeeperオートメーターサービスでは、チームおよびチーム割り当てを即時で承認します。オートメーターサービスの詳細については[こちらのページ](https://app.gitbook.com/s/-Mfd2v-YT48Ljtykb8qm/device-approvals/automator)をご覧ください。

### SCIM APIプロビジョニングの使用

KeeperのSCIM APIを検証またはプログラムしているされている方に向けて、Postmanを使用してKeeperと連携する方法についての[ページ](https://docs.keeper.io/jp/enterprise-guide/user-and-team-provisioning/automated-provisioning-with-scim/using-scim-api-provisioning)を作成しました。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.keeper.io/jp/enterprise-guide/user-and-team-provisioning/automated-provisioning-with-scim.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.