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 Enterpriseにプロビジョニングする際に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 Enterpriseノードを識別します。
ユーザーは、同じベンダーまたは様々なベンダーからの様々な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を返します。 注: Keeperはデータの損失を防止するために、アカウントを削除する代わりにロックします。管理者は、管理コンソールのインターフェースまたは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クエリに対して以下のようなパラメータを追加できます。
ページネーション(ページ区切り)
https://tools.ietf.org/html/rfc7644#section-3.4.2.4に記載の仕様に従います。
Keeper SCIM APIは、大きな結果セットを生成するクエリに対してはデフォルトでは最初の1000件のエントリのみを返します。データセット全体にクエリを実行するには、仕様に従ってSCIMページネーションパラメータを使用します。
統合に関する注記
SCIM IDプロバイダは単一のノードに、プロバイダのユーザー名はKeeperのユーザー名(メールアドレス)にマッピングされますので、Keeperのユーザー名はグローバルで固有である必要があります。したがって、すでに同じまたは別のKeeper Enterpriseアカウントのメンバーのメールによって定義されたユーザーがIDプロバイダに含まれている場合、そのユーザーをプロビジョニングしようとすると失敗します。そのユーザーがすでに同じノードのメンバーである場合のみ、プロビジョニングは成功し、IDプロバイダとKeeperの連携が確立します。 問題を回避するため、IDプロバイダで使用する予定のユーザーと一致するKeeperのユーザーをすでに手動で作成済みである場合、プロバイダで統合を設定する前に、SCIMノードでユーザーを手動で移行します。
ユーザーがプロビジョニングされる際、Keeper側ではユーザー名またはメールに有効なメールアドレスが含まれていることが必要となります。有効なメールアドレスが存在しない場合、プロビジョニングが拒否されることがあります(たとえば、Oktaではユーザー名を任意の文字列に設定することが可能で、Eメールは必須ではありません)。Eメールが偽の場合でも受け入れられますが、その場合プロビジョニングされたユーザーは招待メールを受信できないため、結果としてEnterpriseに参加できなくなります。
チームとユーザーの承認手順
SCIM同期を使用して追加された新規ユーザーは「招待済み」状態で作成され、Keeperに参加するための招待を受け取ります。SCIM同期によって作成された新規チームは、「保留」状態で作成され、Keeper管理者またはチームメンバーのいずれかによる最終承認が必要となります。
SCIM経由でチームに追加されたユーザーは「保留」状態で追加され、承認が必要となります。管理者がKeeper管理コンソールにログインする際に、チームとユーザーの承認が自動的に行われます。 また、承認はKeeper AutomatorサービスやKeeper Commanderを使用して自動化することもできます。この方法でチームとユーザーが承認される理由は、暗号化キーが生成(および共有)される必要があるためです。Keeper のゼロ知識環境では、Keeper 管理者、別のチームメンバー、自動化サービスのどれかによってこの手順が実行される必要があります。Keeperのサポートチームがお客様の自動化サービスのインストールのお手伝いをさせていただきます。
バージョン 2.3.0 以降の Keeper Automator サービスは、チームおよびチーム割り当ての即時承認を実行します。
固有のグループ名
デフォルトでは、グループ名が過去に使用された名前と同一であってもグループの作成が受け入れられます。
重複したグループ名による問題に遭遇した場合、Keeperまでご連絡ください。ご利用のSCIM接続にフラグを設定して固有の名前が強制されるようにします。
必要でしたらKeeperサポートにご連絡ください。ご利用のSCIMインスタンスで固有のグループ名が強制されるようにします。
SCIMプッシュコマンド
トラブルシューティングとヒント
管理コンソールでSCIMプロビジョニング方法を保存する前に[テスト]ボタンをクリックした場合、テストは失敗します。まずトークンをコピーしてから[保存]をクリックしてください。
Keeperユーザーはメールアドレスで識別されるため、割り当て時にユーザー名に有効なメールアドレスが含まれていることを確かにしてください。
チームのプロビジョニングとチーム割り当て
ユーザーとチームのSCIMプロビジョニングを設定する際は以下を確認します。
SCIMからユーザーを招待する際、そのユーザーがまだKeeper内に存在しない場合、サインアップの招待を受け取ります(ジャストインタイミングプロビジョニングも使用できます)。
ユーザーがKeeperのアカウントを作成した後は、以下のいずれかが発生するまでユーザーがKeeperのチームに割り当てられません。 (a) 管理者が管理コンソールにログイン > 管理画面から[完全同期]をクリックする。 (b) 該当チームのユーザーがウェブボルトかデスクトップアプリにログインする。 (c) 管理者がKeeper Commanderからチーム承認を行う。 (d) Keeper Automatorサービスが承認を行う。
SCIM経由でチームとユーザーを即座に作成できない理由は、暗号化モデルおよびユーザー間で秘密鍵を共有する必要があるためです。暗号化キー(例:チームキー)は、ログイン状態で必要な秘密鍵にアクセスできるユーザーによってしか共有できません。
この処理を簡潔にするため、バージョン3.2以降のKeeper Automatorサービスは、チームおよびチーム割り当てを即時で承認します。Automatorサービスの詳細についてはこちらをご覧ください。
Last updated