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

サードパーティIDプロバイダへの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エンドポイントはユーザーグループのリソース、および以下のメッセージタイプに対応しています。

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

  • ユーザー/チーム情報の取得

  • ユーザー/チームの追加

  • ユーザー/チームプロファイルの更新

  • ユーザー/チームの削除

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

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

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

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

リソース/メソッド
URLサンプル

Users/GET

https://keepersecurity.com/api/rest/scim/v2/123/Users

ノード123のすべてのユーザーを返します

Users/GET

https://keepersecurity.com/api/rest/scim/v2/123/Users/456

ノード123のユーザー456を返し、見つからない場合は404を返します。

Users/POST

https://keepersecurity.com/api/rest/scim/v2/123/Users

リスエストのSCIMコンテンツ (User) を解析し、ユーザーをノード123に追加します。

Users/PATCH

https://keepersecurity.com/api/rest/scim/v2/123/Users/456

SCIMコンテンツ (Operations) を解析し、ユーザー456を、追加/削除操作で参照されるチームにグループとして追加または削除します。また「アクティブ」なプロパティを処理して、Keeperでユーザーをロックまたはロック解除することもできます。 参照されるチームは同じノードに属している必要があります。ユーザーが見つからない場合、404を返します。

Users/DELETE

https://keepersecurity.com/api/rest/scim/v2/123/Users/456

ノード123からユーザー456をロックします。ユーザーが見つからない場合、404を返します。

注: データの損失を防ぐため、アカウントを削除せずにロックします。管理者は、管理コンソールのインターフェースまたはCommander API内で、ユーザーを完全に削除できます。

Groups/GET

https://keepersecurity.com/api/rest/scim/v2/123/Groups

ノード123のすべてのチームを返します。

Groups/GET

https://keepersecurity.com/api/rest/scim/v2/123/Groups/789

ノード123のチーム789を返し、見つからない場合は404を返します。

Groups/POST

https://keepersecurity.com/api/rest/scim/v2/123/Groups

リスエストのSCIMコンテンツ (Group) を解析し、チームをノード123に追加します。

Groups/PATCH

https://keepersecurity.com/api/rest/scim/v2/123/Groups/789

SCIMコンテンツ (Operations) を解析し、追加/削除操作で参照されるユーザーを、チーム789に追加または削除します。参照されるユーザーは同じノードに属している必要があります。チームが見つからない場合、404を返します。

Groups/DELETE

https://keepersecurity.com/api/rest/scim/v2/123/Groups/789

ノード123からチーム789を削除します。チームが見つからない場合、404を返します。

ServiceProviderConfig/GET

https://keepersecurity.com/api/rest/scim/v2/123/ServiceProviderConfig

Keeper SCIMサービスのSCIMサービスプロバイダ構成を返します

除外される属性

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ページネーションパラメータを使用します。

統合に関する注記

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

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

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

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

SCIM経由でチームに追加されたユーザーも「保留」の状態で追加され、承認が必要となります。管理者がKeeper管理コンソールにログインする際に、チームとユーザーの承認が自動的に行われます。 また、KeeperオートメーターサービスKeeperコマンダーを使用して承認処理を自動化することもできます。この承認処理は、暗号化キーが生成 (および共有) される必要があるためです。Keeperのゼロ知識環境では、Keeper管理者、別のチームメンバー、自動化サービスのどれかによってこの処理が実行される必要があります。必要に応じて、Keeperのサポート自動化サービスのインストールのお手伝いをさせていただきます。

固有のグループ名

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

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

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

チームとユーザーの承認

SCIMプッシュコマンド

SCIMはKeeperコマンダーSDKに統合されていますので、ユーザーとグループは任意のディレクトリソースからKeeper SCIMエンドポイントに直接プッシュできます。 SCIM Pushコマンドの詳細については、こちらのページをご覧ください。

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

  • 管理コンソールでSCIMプロビジョニング方法を保存する前に[テスト]ボタンをクリックした場合、テストは失敗します。まずトークンをコピーしてから[保存]をクリックしてください。

  • Keeperユーザーはメールアドレスで識別されるため、割り当て時にユーザー名に有効なメールアドレスが含まれていることを確かにしてください。

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

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

  • SCIMからユーザーを招待する際、そのユーザーがまだKeeper内に存在しない場合、サインアップの招待メールが送信されます (ジャストインタイミングプロビジョニングも使用できます)。

  • ユーザーがKeeperのアカウントを作成した後は、以下のいずれかが発生するまでユーザーがKeeperのチームに割り当てられることはありません。 (a) 管理者が管理コンソールにログインし、管理画面から[完全同期]をクリックする。 (b) 該当チームのユーザーがウェブボルトかデスクトップアプリにログインする。 (c) 管理者がKeeperコマンダーからチーム承認を行う。 (d) Keeperオートメーターサービスで承認を行う。 SCIM経由でチームとユーザーを即座に作成できない理由は、暗号化モデルおよびユーザー間で秘密鍵を共有する必要があるためです。暗号化キー (チームキーなど) は、ログイン状態で必要な秘密鍵にアクセスできるユーザーによってしか共有できません。

  • この処理を簡潔にするため、バージョン3.2以降のKeeperオートメーターサービスでは、チームおよびチーム割り当てを即時で承認します。オートメーターサービスの詳細についてはこちらのページをご覧ください。

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

KeeperのSCIM APIを検証またはプログラムしているされている方に向けて、Postmanを使用してKeeperと連携する方法についてのページを作成しました。

Last updated