Oktaでのプロビジョニング
Oktaプラットフォームを利用したSAML 2.0認証およびSCIMプロビジョニング
Last updated
Oktaプラットフォームを利用したSAML 2.0認証およびSCIMプロビジョニング
Last updated
本ページでは、SCIMを使用したOkta自動プロビジョニングについて解説します。設定の前に、まずリアルタイムなユーザー認証とジャストインタイムなプロビジョニングを実現するSSOコネクトとOktaとの統合を有効にしておきましょう。
Okta SSOの導入について詳しくはをご参照ください。
Keeper/Oktaの自動プロビジョニングは、以下の機能に対応しています。
Keeperでユーザーを作成
ユーザー属性の更新
ユーザーのアクティブ化または非アクティブ化 (Keeperでのユーザーのロックまたはロック解除)
Keeperでチームを作成 (Oktaグループから)
シームレスな認証
ユーザーをプロビジョニングする場合、Oktaディレクトリは単一のKeeperノードにマッピングされます。Oktaでは、ユーザーとグループは保留状態で作成され、新規ユーザーにはKeeperアカウントの作成を案内する招待メールが送信されます。
Oktaを使用したKeeperのユーザープロビジョニングを設定するには、Keeper管理コンソールとOkta管理者アカウントにアクセスする必要があります。
Okta管理設定にKeeperを追加していない場合、[Application] (アプリケーション) タブを選択してから[Browse App Catalog] (アプリカタログを参照) を選択し、「Keeper」を検索します。
Keeper管理コンソールを開き、お使いのOktaアカウントと同期させるノードに移動します。SAML 2.0認証を使用している場合、SCIMコネクタを同じノードに追加します。[メソッドを追加] 、[SCIM]の順に選択して[次へ]をクリックします。
URLをコピーします。
Okta管理者アカウントに戻り、Okta API Integration (Okta API統合) 画面の[Base URL] (ベースURL) KeeperのURLをコピー&ペーストします。
次に、Keeper側で[生成]をクリックします。
生成されたトークンを直ちにクリップボードにコピーし、[保存]をクリックします (重要)。
注: トークンをKeeperに保存する前に、Okta側で[Test] (テスト) をクリックすると、テストは失敗します。
次に、トークンをOktaコンソールに貼り付けます。
Oktaで[Save] (保存) を選択して、Keeperのプロビジョニング手順を完了します。
Oktaの[Provisioning] (プロビジョニング) タブの「Provisioning to App」 (アプリへのプロビジョニング) の下にある[Edit] (編集) をクリックします。 「Create Users」 (ユーザーの作成)、「Update User Attributes」 (ユーザー属性の更新)、「Deactivate Users」 (ユーザーの無効化) の各機能を有効にし、[Save] (保存) をクリックします。
Oktaでアプリをユーザーに割り当て、しばらくしてからKeeper管理コンソールで[完全同期]ボタンを選択します。
ユーザーのユーザー名とメールアドレスが、ユーザー割り当て時と同じであることを確かにします。
Keeper管理コンソール画面では、ユーザーは「招待済み」か「移管承認待ち」のいずれかの状態で表示されます。(デフォルトのロールに対してボルト移管ポリシーが有効である場合)。
ユーザーは招待メールを受信します (ロールポリシーで招待メールが無効となっている場合は除く)。招待リンクをクリックすると、ユーザーはOktaでログインできるようになり、プロビジョニングプロセスが完了します。
メールアドレスまたは法人ドメインを使用してKeeperにログインすることで、サインインプロセスを完了することもできます。
ユーザーがKeeperボルトを作成すると、管理コンソールのステータスが「有効」に変化します。
KeeperはOktaの「Push Groups」 (プッシュグループ) を介したチームプロビジョニングに対応しています。
Push Groups (プッシュグループ) は、管理コンソール内にKeeperチームとして追加されます。
Push Groups (プッシュグループ) に割り当てられたユーザーは、Keeperチームに割り当てられます。
その後、Keeperチームを共有フォルダにプロビジョニングできます。
Keeperチームは、チームとロールのマッピングを行うことで、ロールポリシーにマッピングできます。
Keeperにおけるユーザーのチーム割り当てやチームメンバーシップの管理は、直接管理コンソールで行うか、Keeperの自動化ツールを使用して実行する必要があります。
トランザクションを処理し承認するには、Keeper管理コンソールにユーザーやチームをプッシュした後、単にログインするか「完全同期)」をクリックします。
ユーザーまたはチームのデータをKeeper管理コンソールに送信した後、管理コンソールにログインするか[完全同期]ボタンをクリックすることで、送信されたデータの処理と承認が行われます。
チームの承認が処理されると、画面の下部に通知が表示されます。
チームとユーザーの承認は、KeeperオートメーターサービスやKeeperコマンダーでteam-approve
コマンドを使用して行うこともできます。
Oktaの自動プロビジョニングでは、Push Groups (プッシュグループ) をKeeperチームにマッピングされます。 チームごとにKeeperロールを自動的に割り当てるには、チームとロールのマッピング機能を使用します。
「ロール」画面で、チームをロールに追加します。
チームとロールのマッピングの際には、管理者はロールを個々のユーザーに対してではなく、チーム全体に割り当てます。各チームには、ロール強制適用ポリシーを使用して異なる要件や制限を設定できます。チームとロールのマッピングは、管理者ロールでは適用できません。
管理コンソールでSCIMプロビジョニング方法を保存する前に「Test」 (テスト) ボタンをクリックすると、テストは失敗します。
Keeperユーザーはメールアドレスで識別されるため、OktaユーザーをKeeperアプリに割り当てるときは、ユーザー名に有効なメールアドレスが含まれていることを確かにしてください。
Keeper Oktaアプリケーションに割り当てられたグループは、デフォルトではKeeper内でチームとして作成されず、メンバーだけがプッシュされます。グループ全体とそのメンバーを同期するには、Keeper Oktaアプリケーションの「Push Groups」にグループを追加する必要があります。
Oktaからグループメンバーを同期する場合、Keeperにチームメンバーが作成されますが、すぐには表示されません。プロビジョニングされたユーザーが実際のチームメンバーになるには、ユーザーはKeeperに登録し、招待を受諾した後、Keeper管理者によるグループ加入の承認を受けるか、ウェブボルトにログインしている既存のKeeperチームメンバーによって自動承認される必要があります。
新しいPush Groupを作成するときは、Oktaの管理者が少なくとも一度は手動でグループをプッシュし、グループ同期を完了させる必要があります。
Oktaを使用してユーザーとチームのSCIMプロビジョニングを設定する場合は、以下の点を確認してください。
SAMLアプリケーションでOktaグループをプッシュグループとして割り当てます。
Oktaからユーザーを招待するか、プッシュグループとしてプロビジョニングされたグループにユーザーを割り当てると、OktaからKeeperへリクエストが送信され、ユーザーの招待、ユーザーのチームへの追加、チームの作成のいずれかを行います。
ユーザーがKeeperにまだ存在しない場合は、サインアップへの招待を受け取ります (または、ジャストインタイムプロビジョニングを使用できます)。
ユーザーがKeeperアカウントを作成した後、以下のいずれかが発生するまで、ユーザーがKeeperチームに割り当てられることはありません。 (a) 管理者が管理コンソールにログインし、 管理画面で「完全同期」をクリックする。 (b) 関連チームのユーザーがウェブボルトまたはデスクトップアプリにログインする。 (c) 管理者がKeeperコマンダーからチーム承認を実行する。 SCIMを介してチームとユーザーを即座に作成できない理由は、暗号化モデルとユーザー間で秘密キーを共有する必要があるためです。暗号化キー (チームキーなど) の共有は、ログインし、必要な秘密キーにアクセスできるユーザーのみが実行できます。
「Unable to update Group Push mapping target App group xxx: Error while updating user group membership... Not Found」 (グループプッシュマッピングターゲットのアプリグループ xxx を更新できません: ユーザーグループ メンバーシップの更新中にエラーが発生しました... 見つかりません) というエラーが表示された場合
このエラーは、KeeperエンタープライズユーザーIDが KeeperバックエンドとOkta管理者の間で異なる場合に発生することがあります。これは、適切にSCIM招待からユーザーを作成せずに、Keeper側からユーザーのアカウントを削除して再作成した場合に発生することがあります。 この状態では、Okta側ではユーザーの新しいエンタープライズユーザーIDがわかりません。
この問題を解決するには、Keeperへのアプリケーション割り当てを削除し、ユーザーをKeeperアプリケーションに割り当て直します。
サインオン認証については、Keeper SSOコネクトのOktaのページをご参照ください。
Keeperオートメーターサービス (バージョン3.2現在) を使用すると、チームとチーム割り当ての即時承認が可能です。オートメーターサービスの詳細については、をご覧ください。
クラウドSSOコネクトの (推奨)
オンプレミスSSOコネクトの