全てのページ
GitBook提供
1 / 24

SSO IDプロバイダ

SSO Connect CloudでIDプロバイダを設定

SAML 2.0準拠IDプロバイダの設定の前に管理コンソールを設定してきます。個々のIDプロバイダの設定する際の助けとなるよう、以下にガイドをご用意しました。

  • Microsoft ADFS

  • Amazon AWS

  • Auth0

  • Entra ID (Azure AD)

  • Centrify

  • Duo SSO

  • F5

  • Google Workspace

  • JumpCloud

  • Okta

  • OneLogin

  • Ping Identity

  • PingOne

  • Rippling

  • RSA SecurID Access

  • SecureAuth

  • Shibboleth

  • HENNGE

  • その他のSAML 2.0プロバイダ

ご利用のIDプロバイダがこちらに記載されていなくても問題ありません。KeeperはすべてのSAML 2.0 SSO IDプロバイダとパスワードレス認証製品と互換性があります。上記のリストから類似のプロバイダがあれば、設定の流れはほぼ同じなので、その設定手順に従って設定してください。

(ご利用のIDプロバイダ用の設定ガイドを作成された場合、共有いただけましたらこちらに掲載させていただきます。)

Amazon AWS

Keeper SSO Connect CloudをAmazon AWS SSOと連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。

AWS SSO

AWSにログインし、[AWS Single Sign-On] (AWSシングルサインオン) を選択します。

SSOダッシュボードで、[Configure SSO access to your cloud applications] (クラウドアプリケーションへのSSOアクセスを設定する) を選択します。

[Applications] (アプリケーション) メニューで、[Adda a new application] (新しいアプリケーションを追加) を選択します。

次に、Keeper Securityを選択して[Add] (追加) を選択します。

KeeperとAWSでアプリケーションコネクタを共同開発中です。

[Details] (詳細) セクションで[Display name] (表示名)と[Description] (説明) (任意) を入力します。

[AWS SSO metadata] (メタデータ) セクションで、[Download] (ダウンロード) ボタンを選択して、AWS SSO SAMLメタデータファイルをエクスポートします。このファイルは、設定画面の[SSO Connect IdPMetadata] (メタデータ) セクションでインポートします。

このファイルをKeeper SSO Connectサーバーにコピーし、ファイルを参照するか、設定画面の[SAMLメタデータ]の箇所にドラッグアンドドロップしてKeeper SSO Connectインターフェースにアップロードします。

次に、Keeperのメタデータファイルをダウンロードし、AWSアプリケーションのメタデータファイルにアップロードします。Keeper SSO Connect Cloud™のプロビジョニングの表示画面に移動します。

表示画面を開く

[メタデータをエクスポート]ボタンをクリックして、config.xmlファイルをダウンロードします。

Keeperメタデータをエクスポート

\

AWS SSOの[Application metadata] (アプリケーションメタデータ) セクションに戻って、[Browse...] (ファイルを参照) ボタンを選択し、上記の手順でダウンロードしたconfig.xmlを選択します。

[Save changes] (変更を保存) をクリックすると、「Configuration for Keeper Password Manager has been saved」 (Keeperパスワードマネージャの設定が保存されました) いうメッセージが表示されます。

Keeper SSL証明書は、2048Kを超えることはできません。超えると、以下のエラーが表示されます。

  • より小さいサイズのSSL証明書の生成、メタデータファイルの再エクスポートとインポート、AWS SSOの設定でACS URLとAudience URLを手動設定のいずれかを行なってください。

次に、AWS SSOにマッピングするKeeperの属性が正しいことを確かにします (デフォルトで設定されています)。[Attribute mappings] (属性マッピング) タブを選択します。 AWSの文字列値を${user:subject}に、形式を空白またはunspecified (未指定) にします。 Keeper属性を以下のように設定します。

Keeper属性
AWS SSO文字列値
形式

Email (メール)

${user:email}

unspecified (未指定)

First (名)

${user:givenName}

unspecified (未指定)

Last (姓)

${user:familyName}

unspecified (未指定)

AWSのメールがAD UPNにマッピングされている場合 (ユーザーの実際のメールアドレスではない可能性があります) 、ユーザーのADプロファイルに関連付けられているメールアドレスに再マッピングできます。

この変更を行うには、AWS SSOページの[Connected Directory] (接続されたディレクトリ) へ移動します。

[Edit attribute mappings] (属性マッピングを編集) ボタンを選択します。

AWS SSOのemail (メール) 属性を${dir:windowsUpn}から${dir:email}に変更します。

[Assigned users] (割り当てられたユーザー) タブを選択してから、[Assign users] (ユーザーを割り当て) ボタンをクリックして、アプリケーションを割り当てるユーザーまたはグループを選択します。

[Assign users] (ユーザーを割り当て) ウィンドウで、以下の操作を行います。

  • グループまたはユーザーを選択

  • グループまたはユーザーの名前を入力

  • [Search connected directory] (接続されたディレクトリを検索) を選択して、検索します。

ディレクトリ検索の結果は、検索ウィンドウの下に表示されます。

アプリケーションへのアクセスが必要なユーザーやグループを選択し、[Assign users] (ユーザーを割り当て) ボタンを選択します。

備考: Keeper SSO Connectは、SAMLレスポンスが署名されていることを想定しています。IDプロバイダがSAMLレスポンスに署名するように設定されていることをご確認ください。

これでKeeper SSO Connectの設定は完了です。

既存のユーザー/初期管理者をSSO認証に移行

ルートノード (最上位) で作成されたユーザーは、SSOが設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスする際にマスターパスワードの入力を求められます。

管理者は、SSOが有効になっているノードに自分自身を移動できません。この操作を行うには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、最初に[法人SSOログイン]のプルダウンからSSO統合で設定した法人ドメインを入力し、Keeperボルトにログインする必要があります。また、マスターパスワード入力による確認を求められる場合があります。

まず[法人SSOログイン]を選択

SSOで認証されると、それ以降はメールアドレスだけでSSO認証を開始できます。

法人ドメインを入力する必要はありません。メールアドレスを入力して[次へ]をクリックしても目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。 ルーティングとドメイン予約の詳細については、こちらをご覧ください。

Auth0

Keeper SSO Connect CloudをAuth0と連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。

Auth0 SSOの設定

Auth0ポータルの管理者セクションにログインします。

[Applications] (アプリケーション) タブを選択し、[Create Application] (アプリケーションを作成) をクリックします。[Regular Web Applications] (通常のウェブアプリケーション) を選択します。

[Applications] (アプリケーション) > [Create Application] (アプリケーションを作成) > [Regular Web Applications] (通常のウェブアプリケーション)

次に、[Addons] (アドオン) タブに移動して、[SAML2 WEB APP] (SAML2ウェブアプリ) をクリックします。

[Addons] (アドオン) > [SAML2 WEB APP] (SAML2ウェブアプリ)

次に表示される設定ページで、Keeper管理コンソールに表示された[Assertion Consumer Service(ACS)エンドポイント]が必要になります。

ACSエンドポイントの例: https://keepersecurity.com/api/rest/sso/saml/XXXXXXXX

この値は、以下のようにサービスプロバイダの情報の一部としてSSO Connect Cloudの設定で確認できます。

設定を表示
ACS(Assertion Consumer Service)エンドポイントをコピー

ACSエンドポイントをAuth0画面の[Application Callback URL] (アプリケーションコールバックURL) フィールドに貼り付けます。

次に、SAML2 Web App編集ウィンドウでサンプルのJSONを削除して以下に置き換えます。

{
  "audience": "https://keepersecurity.eu/api/rest/sso/saml/XXXXX",
  "mappings": {
    "email":"Email",
    "given_name":"First",
    "family_name":"Last"
  },
  "createUpnClaim": false,
  "passthroughClaimsWithNoMapping": false,
  "mapUnknownClaimsAsIs": false,
  "mapIdentities": false,
  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
  "nameIdentifierProbes": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
  ]
}

「audience」の値は法人IDとなります。この値もサービスプロバイダ情報の一部として、SSO Connect Cloudの設定で確認できます。

IDPが起点となるログインエンドポイントをコピー

法人IDを追加した後、[Debug] (デバッグ) ボタンをクリックして、設定に問題がないことをご確認ください。

次に、SAML2 Web Appウィンドウを一番下までスクロールして、[Save] (保存) をクリックします。

SAML2ウェブアプリの設定に加えた変更を保存します

次に、[Usage] (使用) タブをクリックし、IDプロバイダのメタデータファイルをダウンロードします。

IdPメタデータをダウンロード

Keeper側でSSOの設定を編集し、[IDP タイプ]に[GENERIC] (汎用) を選択します。metadata.xmlファイルを参照するか設定画面にドラッグアンドドロップして、Keeper SSO Connectインターフェースにアップロードします。

SSOの設定を編集
Auth0からダウンロードしたメタデータファイルをKeeperにドラッグアンドドロップ

既存のユーザー/初期管理者をSSO認証に移行

ルートノード (最上位) で作成されたユーザーは、SSOが設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスする際にマスターパスワードの入力を求められます。

管理者は、SSOが有効になっているノードに自分自身を移動できません。この操作を行うには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、最初に[法人SSOログイン]のプルダウンからSSO統合で設定した法人ドメインを入力し、Keeperボルトにログインする必要があります。また、マスターパスワード入力による確認を求められる場合があります。

まず[法人SSOログイン]を選択

SSOで認証されると、それ以降はメールアドレスだけでSSO認証を開始できます。

法人ドメインを入力する必要はありません。メールアドレスを入力して[次へ]をクリックしても目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。 ルーティングとドメイン予約の詳細については、こちらをご覧ください。

Centrify

Keeper SSO Connect CloudをCentrifyと連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。

Centrify

クラウドログインを使用して、CentrifyのAdmin portal (管理者ポータル) にログインします。

プルダウンメニューからAdmin portal (管理者ポータル) に切り替えます。

Quick Start Wizard (クイックスタートウィザード) がポップアップ表示された場合は、閉じます。メニューから[Apps] (アプリ) を選択し、[Add Web Apps] (ウェブアプリ) を選択します。

Add Web Apps (ウェブアプリを追加) ウィンドウで、[Custom] (カスタム) タブを選択し、下にスクロールしてSAMLの横の[Add] (追加) を選択します。

Do you want to add this application? (このアプリケーションを追加しますか?) のプロンプトで[Yes] (はい) を選択します。

Add Web Apps (ウェブアプリを追加) ウィンドウを閉じます。

次に、KeeperのSSOメタデータをCentrifyにアップロードします。 Keeper管理コンソールで、SAMLメタデータファイルをエクスポートします。

[表示]をクリックして[メタデータをエクスポート]に移動します。

Centrifyの[SAML Application Settings] (SAMLアプリケーション設定) セクションで、[Upload SP Metadata] (SPメタデータをアップロード) を選択します。

[Upload SP Metadata from a file] (ファイルからSPメタデータをアップロード) を選択し、[Browse]をクリックしてKeeperSSOMetadata.xmlファイルを選択し、[OK]を選択します。

Identity Provider SAML Meta data (IDプロバイダのSAMLメタデータ) をダウンロードします。これをKeeper SSO Connectにアップロードします。

Description (説明) セクションで、Application Name (アプリケーション名) フィールドにKeeper SSO Connectと入力し、Category (カテゴリ) フィールドで[Security] (セキュリティ) を選択します。

Keeperのロゴをダウンロードします。 [Select Logo] (ロゴを選択) を選択して、Keeperのロゴ (keeper60x60.png) をアップロードします。

[User Access] (ユーザーアクセス) セクションで、Keeperにアクセスできるロールを選択します。

Account Mapping (アカウントマッピング) セクションで、「Use the following Directory Service field to supply the user name」 (以下のディレクトリサービスを仕様してユーザー名を供給する) を選択して「mail」と入力します。

Advanced (詳細設定) セクションで、以下のコードを含むスクリプトを追加します。

setAttribute("Email", LoginUser.Get("mail"));
setAttribute("First", LoginUser.FirstName);
setAttribute("Last", LoginUser.LastName);
setSignatureType("Response");
  • 上記のスクリプトで、User Account (ユーザーアカウント) セクションから表示名を読み取ります。FirstName属性は、DisplayNameの最初の文字列から取得し、LastName属性は、DisplayNameの2番目の文字列から取得します。

[Save] (保存) を選択して設定を完了します。

ファイルを編集画面にドラッグアンドドロップして、Identity Provider Metadata (IDプロバイダのSAMLメタデータ) ファイルをKeeper SSO Connect Cloudインスタンスのインターフェースにアップロードします。

アップロードが完了すると、画面をひとつ戻ります。 SSO連携をテストする準備ができました。

CloudGate UNO

KeeperクラウドSSOコネクトをCloudGate UNOと連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。

CloudGate SSOの設定

  1. CloudGate管理者コンソールへログインします。

[Admin Site]のタイルをクリックします。

  1. 左側のメニューから[設定] > [サービスプロバイダー]を選択し、[サービスプロバイダー追加]をクリックします。

「サービスプロバイダー追加」ページの検索バーで「Keeper」を検索します。「Keeper SSO Connect Cloud」のアイコンを選択してクリックします。

  1. 「一般設定」タブの「表示名」を「Keeper_SSO_Cloud_Connet」など任意の名前に設定します。

  1. 「シングルサインオン設定」タブで、「エンティティID」などの情報が必要になりますので、Keeper管理コンソールを開いてコピーします。

コピーした「エンティティID」などの情報をCloudGateのシングルサインオン設定ページに貼り付けます。

SSO IDは、SPエンティティIDの末尾にあります。

例: https://keepersecurity.com/api/rest/sso/saml/3534758084794

  1. 「追加属性」で[追加]をクリックし、「フィールド名」を「Email」に「値」を「${MAIL_ADDRESS}」に設定して保存します。

シングルログアウトを有効にする (任意)

CloudGateでシングルログアウト機能を有効にする場合は、「シングルサインオン設定」タブに移動して「ログアウトURL」を入力してから、Keeper管理コンソールから取得したSP証明書をアップロードします。

SP証明書をダウンロードするには、Keeper管理コンソールでSSO設定ページを表示し、[SP 認証エクスポート]ボタンをクリックします。

次に、「シングルログアウト (SLO) エンドポイント」情報をコピーして、CloudGateのシングルサインオン設定ページに貼り付けます。

  1. 最後に、「シングルサインオン設定」タブの「SMAL 2.0 メタデータ」からメタデータをダウンロードして、KeeperクラウドSSOコネクトへインポートします。

Keeper管理コンソールへ戻り、作成したクラウドSSOコネクトによるSSO設定の編集画面に入ります。「IDPタイプ」を「GENERIC」に設定し、ファイルを「ここにファイルをドロップしてください」と書かれた箇所へドラッグアンドドロップします。

ユーザーの割り当て

CloudGateの左側のメニューの「アカウント管理」 > 「ユーザー」へ移動し、任意のユーザーをクリックします。「ユーザー管理」ページの「ユーザー設定」タブでユーザーを追加できるようになっています。

ユーザーの割り当て

同じページの「ユーザーID」の下の[さらに表示する]をクリックして「メールアドレス」の値が入っていることを確認します。

グループの割り当て

[保存]をクリックして、KeeperクラウドSSOコネクトとCloudGateの設定を完了します。

Keeper SSOコネクトの設定が完了しました!

CloudGate SCIMプロビジョニング

CloudGate SCIMユーザーとグループのプロビジョニングを有効にする方法については、Keeperエンタープライズガイドのこちらのページをご参照ください。

既存のユーザー/初期管理者をSSO認証に移行

ルートノード (最上位) で作成されたユーザーは、SSOが設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスする際にマスターパスワードの入力を求められます。

管理者は、SSOが有効になっているノードに自分自身を移動できません。この操作を行うには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、最初に[法人SSOログイン]のプルダウンからSSO統合で設定した法人ドメインを入力し、Keeperボルトにログインする必要があります。また、マスターパスワード入力による確認を求められる場合があります。

まず[法人SSOログイン]を選択

SSOで認証されると、それ以降はメールアドレスだけでSSO認証を開始できます。

法人ドメインを入力する必要はありません。メールアドレスを入力して[次へ]をクリックしても目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。 ルーティングとドメイン予約の詳細については、こちらのページをご覧ください。

DUO SSO

KeeperクラウドSSOコネクトをDUO SSOと連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。

Duoのセットアップ

以下の手順では、Duoが正常に有効化され、認証ソース (Active DirectoryまたはIdP) が設定済みであることを前提としています。Duo SSO を有効にするには、Duo Admin Panel (管理パネル) にアクセスし、「Single Sign-On」 (シングル サインオン) セクションにアクセスします。

手順 1: DUO SSOの設定

DuoのAdmin Panel (管理パネル) にログインし、左側のナビゲーションバーの[Protect an Application] (アプリケーションの保護) をクリックします。Keeperを検索し、アプリケーションリストから、保護タイプが[2FA with SSO hosted by Duo (Single Sign-On)] (DuoがホストするSSOによる2FA (シングルサインオン)」のKeeper Securityを見つけて、[Protect] (保護) をクリックします。

Keeper Security SSOタイプを保護

手順 2: メタデータ

[Download] (ダウンロード) セクションで、ご利用のSSOプロビジョニングメソッドにアップロードするためのSAMLメタデータファイルをダウンロードします。

DUOメタデータファイルをダウンロード

Keeper管理コンソールに戻り、DUOクラウドSSOコネクトのプロビジョニングメソッドを見つけて、[編集]を選択します。

DUO SSOプロビジョニングメソッドを編集

[アイデンティティプロバイダ]セクションまで下にスクロールし、[IDP タイプ]を[DUO SSO]に設定して、[ファイルを参照]を選択し、先ほどダウンロードしたDUOメタデータファイルを選択します。

引き続き、Keeper管理コンソール内のDUOクラウドSSOコネクトのプロビジョニングメソッドで、編集ビューを終了して、[表示]を選択します。 サービスプロバイダセクション内に、[エンティティID]、[IDP起点ログインエンドポイント]、[アサーションコンシューマーサービス (ACS) エンドポイント]のメタデータの値が表示されます。

[シングルログアウトサービスエンドポイント]はオプションです。

DUO SSOプロビジョニングメソッドを表示

Duo Admin Panel (管理パネル) のアプリケーションページに戻り、Entity ID (エンティティID)、Login Enndpoint (ログインエンドポイント)、ACS Endpoint (ACSエンドポイント) をコピーして、Service Provider (サービスプロバイダ) セクションに貼り付けます。

Keeperメタデータ情報

手順 3: ユーザー属性をマッピング

SAML Response (SAMLレスポンス) セクション内で、Map attribute (属性をマッピング) まで下にスクロールして、以下の属性をマッピングします。

3つの属性 (First (名)、Last (姓)、Email (メール)) が上記のように正確なスペルで設定されていることをご確認ください。

ユーザー属性

手順 4: ポリシー

Policy (ポリシー) セクションでは、ユーザーがこのアプリケーションにアクセスするときの認証のタイミングと方法を定義します。グローバルポリシーは常に適用されますが、そのルールはカスタムポリシーで上書きできます。

ユーザーまたはグループのポリシー

手順 5: グローバルポリシー

Global Policy (グローバルポリシー) セクションでは、DUOまたはKeeperの管理者に表示されるすべてのグローバルポリシーを閲覧、編集、確認できます。

これでKeeper Security EPM - Single Sign-Onの設定が完了しました。

トラブルシューティング

ご利用のDUO環境内へのKeeper Security EPM - Single Sign-Onの実装に関してサポートが必要でしたら、Keeperサポートチームまでお問い合わせください。

既存のユーザー/初期管理者をSSO認証に移行

ユーザーにDuoでログインしてもらいたい場合は、Keeper管理コンソールのルートノード (最上位) で作成されたユーザーをSSO対応ノードに移動する必要があります。管理者は自分自身をSSO対応ノードに移動できません。これには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、メールアドレスを入力し[次へ]をクリックするだけでKeeperボルトにログインできるようになります。機能しない場合は、メールドメイン (例: company.com) がエンタープライズで予約されていること、ジャストインタイムプロビジョニングが有効になっていることを確認してください。

法人ドメインでオンボードするには、ユーザーは[法人SSOログイン]からKeeper管理コンソールで設定された法人ドメインを入力します。

最初に[法人SSOログイン]を選択

ユーザーがSSOで認証されると、今後はメールアドレスを入力するだけSSO認証を開始できます。

メールアドレスを入力して[次へ]をクリックしても目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。 ルーティングとドメイン予約の詳細については、こちらのページをご覧ください。

Entra ID (Azure AD)

KeeperクラウドSSOコネクトをMicrosoft Entra ID (旧Azure AD)に連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。

概要

Keeperは、すべてのMicrosoft Azure AD / Entra ID環境と互換性があり、SAML 2.0認証および自動プロビジョニングに対応しています。

  • Keeperアプリケーション (ウェブボルト、KeeperFill、Keeperデスクトップ、iOS/Android用Keeperなど) は、条件付きアクセスポリシーに完全対応しています。

  • Keeperでは商用 (portal.azure.com) とAzure Governmentクラウド (portal.azure.us) の両方の環境がサポートされています。

Azureの設定

AzureにクラウドSSOコネクトを設定する手順の詳細については以下の動画をご覧ください。

AzureにSSO Connect Cloudを設定

以下の手順を実行します。

  1. Keeper Enterpriseアプリケーションを追加

https://portal.azure.comからAzure Adminアカウントへ移動し、[Azure Active Directory] > [Enterprise Applications] (エンタープライズアプリケーション) をクリックします。SCIMプロビジョニング用にKeeperアプリケーションがすでに設定されている場合は、既存のアプリケーションを編集します。

米国の公的機関の場合はhttps://portal.azure.usへログインして同じ手順を実行します。

エンタープライズアプリケーション
  1. [New Application] (新規のアプリケーション) をクリックし、Keeperを検索してKeeper Password Managerを選択します。

  1. [Create] (作成) をクリックしてアプリケーションを作成します。

  2. [Set up single sign on] (シングルサインオンの設定) をクリックしてから [SAML] をクリックします。

SAMLメタデータをエクスポートする前に、対象ノードでSSOプロビジョニング方式が必ず構成されている必要があります。以下をご確認ください。

  • Keeper管理コンソールを開き、[管理者] 画面に移動します。

  • 対象ノードを選択し、[プロビジョニング] タブをクリックします。

  • [SSO Connect Cloud] を選択して [次へ] をクリックします。

  • 必要な構成情報を入力し、[次へ] をクリックします。

  • すると、[メタデータのエクスポート] ボタンが表示され、ダウンロードできるようになります。

  1. [Upload metadata file] (メタデータファイルのアップロード) ボタンを選択してKeeper管理コンソールからダウンロードしたばかりのファイルを選択します。

[Add] (追加) ボタンを押してAzureインターフェースにメタデータファイルをアップロードします。

  1. AzureのSAML設定画面が表示されます。

Sign on URL (サインオンURL) 蘭が空白なので赤いエラーが表示されます。

エラーを修正するには、管理コンソールのクラウドSSOインスタンスの詳細]画面で [IDP起点のログインエンドポイント] のURLをコピーし、[Sign on URL] (サインオンURL) 蘭に貼り付けます。

IdP-initiated方式のログインエンドポイントをサインオンURL蘭にコピーする

シングルログアウトサービスエンドポイント (SLO)

KeeperのURLエンドポイントで、IDプロバイダからのログアウトリクエストの送信先となります。シングルログアウトは任意で、IDプロバイダ側で設定します。

ログアウトURL

IDプロバイダを使用したKeeper起点のシングルログアウトの制御については、こちらをご参照ください。

デフォルトでは、ログアウト後にKeeperが強制的にEntra/Azureからのログアウトセッションを行います。この動作が発生しないようにしたい場合は、AzureメタデータファイルをKeeper にアップロードする前に編集し、SingleLogoutServiceの行を削除します。セキュリティ上の理由から、この行はそのまま含めておくことを推奨します。

SingleLogoutService
  1. [Save] (保存) をクリックしてからSAML設定ウィンドウを閉じます。

  1. 保存後、設定のテストを求められますがテストは行わなず、数秒待ってからウェブブラウザでAzureポータルページを更新します。これで、[SAML Signing Certificate] (署名証明書) の箇所に証明書の項目が表示されます。

[Federation Metadata XML] (フェデレーションメタデータXML) の箇所の [Download] (ダウンロード) をクリックします。

  1. メタデータファイルをKeeper管理コンソールにアップロードします。

管理コンソールで、[IDPタイプ] にAzureを選択し、手順9で保存したフェデレーションメタデータファイルをインポートします。

SAMLメタデータをKeeperにアップロード
  1. [User Attributes & Claims] (ユーザー属性と要求) を編集します。

[User Attributes] (ユーザー属性) セクションでは、AzureがユーザーID、名、姓、メールに対する要求を自動的に作成します。

[Additional clams] (追加要求) セクションの4つの要求は不要ですので、削除してください。

Additional Claimsを削除

ご利用の環境で、user.userprincipalname (UPN) がユーザーの実際のメールアドレスと異なる場合は、メール要求を編集してメール属性の値をuser.mailに変更できます。

ForceAuthnの設定

Keeper管理コンソールで、IDプロバイダとの新しいログインセッションを実施するオプションがご利用になれます。SAMLリクエストでForceAuthn="true" が設定されていると、ユーザーがすでに認証されている場合でもサービスプロバイダ (Keeper) から新しい認証済みセッションを強制しなければならない旨IDプロバイダに伝えます。セキュリティポリシーやエンドユーザー環境によっては望ましい動作となります。

任意のForceAuthn設定

証明書更新のリマインダ

Entra ID / Azure AD のSAML署名証明書は1年後に失効します。

証明書の有効期限前に更新できるよう、カレンダーでリマインダを設定しておきましょう。更新が終わるまでKeeperユーザーはログインできなくなります。

証明書の更新手順については、こちらのページをご参照ください。

ユーザープロビジョニング

手動または自動のプロビジョニングを使用して、AzureポータルからKeeperにユーザーをプロビジョニングできます。

手動

Keeperパスワードマネージャに特定のユーザーまたはグループのみを割り当てる場合は、以下の設定を変更する必要があります。Azureコンソールで、[Azure Active Directory] > [Enterprise Applications] (エンタープライズアプリケーション) > Keeper Password Managerへ進み、[Properties] (プロパティ) を選択します。

[User assignment required] (ユーザーの割り当てが必要ですか) を [Yes] (はい) に変更して保存します。これにより、アプリケーションに割り当てられたユーザーとグループのみが使用できるようになります。

[Users and groups] (ユーザーおよびグループ) の箇所で、Keeperアプリケーションにプロビジョニングするユーザーやグループを選択します。

SCIMを使用した自動プロビジョニング

詳細についてはこちらををご参照ください。

既存のユーザー/初期管理者をSSO認証に移行

ルートノード (最上位レベル) で作成されたユーザーについては、SSO連携が設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスするときにマスターパスワードの入力を求められます。

管理者はSSO対応ノードに自ら移動できません。移動するには、別の管理者が必要となります。

メールでのボルトへのログイン

ジャストインタイムプロビジョニングが有効になっている予約済みドメインの場合、ボルトへのログイン画面でメールアドレスを入力するだけで正しいSSOプロバイダにルーティングされます。ここからボルトを作成するか、既存のボルトにログインできます。

メールでのボルトへのログイン

法人ドメインでボルトへのログイン

ドメインが予約されていない場合、最初に [法人SSOログイン] を選択し、SSO統合で設定された法人ドメインを入力することでKeeperボルトへログインできます。ユーザーが最近非SSOノードからSSOノードに移動した場合、マスターパスワードの入力を求められる場合があります。

最初に[Enterprise SSO Login]を選択します。

ユーザーがSSO認証されると、それ以後はメールアドレスを使用するだけでSSO認証を開始できます。

メールアドレスを入力して [次へ] をクリックしても目的のSSOにルーティングされない場合は、KeeperのSSO設定でジャストインタイムプロビジョニングが有効になっていることを確認し、メールドメインがKeeperによって予約されていることを確かにします。ルーティングとドメイン予約の詳細については、こちらを参照してください。

IdP起点のログイン

Keeperは、AzureのIdP起点のログインをサポートしています。以下のURLからアプリケーションダッシュボードへ移動します。

https://myapplications.microsoft.com/ これにより、割り当てられたKeeperのアプリケーションがロードされ、アイコンをクリックできるようになります。

MicrosoftアプリケーションダッシュボードからのAzure IdP-initiated方式によるログイン

F5

Keeper SSO Connect CloudをF5 BIG-IP APMと連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。

F5

F5 BIG-IP APMで、Keeperプラットフォーム用の新しいSAML IdPサービスを設定します。 Access Policy (アクセスポリシー) -> SAML -> BIG-IP as IdP (IdPとしてのBIG-IP) -> Local IdP services (ローカルIdPサービス) に移動します。

[Access Policy] (アクセスポリシー) > SAML: BIG-IP as IdP (IdPとしてのBIG-IP) > Local IdP services (ローカルIdP サービス) へ移動します。該当するIdP接続ポイントを選択し、Export Metadata (メタデータをエクスポート) を選択します。

F5 BIG-IP APMから抽出したメタデータファイルをSSO Connect Cloudインスタンスにインポートし、IDPタイプにF5を選択します。

[保存]を選択して設定を保存し、すべての設定が正しいことを確認します。 [メタデータをエクスポート]をクリックして、Keeper SSO Connect Cloudメタデータファイルをエクスポートし、F5 BIG-IP APMの設定に使用します。

これでKeeper SSO Connectの設定は完了です。

Google Workspace

Keeper SSO Connect CloudをGoogle Workspaceと連携させてスムーズで安全なSAML 2.0認証とユーザーおよびチームプロビジョニングを実現

最初に管理コンソールの設定を完了してください。

Google WorkspaceとKeeperの連携では以下がサポートされています。

  • SAML 2.0を使用したSSO認証

  • Google Cloud APIとSCIMを使用した自動プロビジョニング (ユーザーとグループ)

  • SCIMを使用した自動プロビジョニング (ユーザーのみ)

SSO、SSOとプロビジョニング、プロビジョニングのみのいずれかを設定できます。

Google Workspaceの設定

Google Workspace管理コンソールにアクセスするには、https://admin.google.com/にログインします。

[Apps] (アプリ) > [Web and Mobile Apps] (ウェブアプリおよびモバイルアプリ)画面にアクセスします。

ウェブアプリおよびモバイルアプリ

続いて、[Add App] (アプリを追加)、[Search for apps] (アプリを検索)の順に選択します。

新しいKeeper SAMLアプリを追加

[Enter app name] (アプリ名を入力)の箇所で「Keeper」を検索し、「Keeper Web (SAML)」を選択します。

Keeper Web (SAML)アプリを選択

Keeperアプリを設定

[Option1] (オプション1)を使用して、IdPのメタデータをダウンロードし、[CONTINUE] (続行) を選択します。

Googleメタデータをダウンロード

サービスプロバイダの詳細情報

[Service Provider Details] (サービスプロバイダの詳細情報) 画面には、入力フィールドがいくつかあります。ACS URLとEntity IDを、SSO Connect Cloudインスタンスで使用する値に置き換えます。

Keeper SPの詳細

ACS URLとEntity IDを取得するには、Keeper管理コンソール内でSSO Connect Cloudプロビジョニングメソッドを見つけて、[表示]を選択します。

SSO Connect Cloud情報

Service providerの箇所に、ACS URLとEntity IDの値が表示されます。

ACS URLおよびエンティティID

ACS URLとEntity IDをコピーして、Service provider details (サービスプロバイダの情報) に貼り付け、[Signed Response] (署名付きレスポンス) をチェックして、[CONTINUE] (続行)を選択します。

Keeper SPの詳細情報入力

属性マッピング

Attributes (属性) 画面で、以下に表示されているとおり3つのマッピングがあることを確かにします。以下に表示されているように、マッピングフィールドをFirst Name (ファーストネーム) 、Last Name (ラストネーム) 、Primary Email (プライマリメール) に設定し、[Finish] (完了)を選択します。 これで、Google WorkspaceのKeeperへのSAML連携が完了しました。

カスタムSAMLアプリを選択または作成した場合は、[Add New Mapping] (新規マッピングを追加) をクリックして、First (名)、Last (姓)、Email (メール)の3つのフィールドを作成する必要があります。

Google属性

Keeper SAMLアプリの詳細

設定が完了すると、Keeper SAMLアプリの詳細ページが表示され、SAML接続およびサービスの詳細を確認できます。SSOを有効にするには、[OFF for everyone] (すべてのユーザーに対してOFF) をクリックします。

全ユーザーでSSO Connectを有効にする

全ユーザーでKeeper SSO Connectを有効にするには、[ON for everyone] (すべてユーザーに対してON) を選択して、[SAVE] (保存)をクリックします。

グループのSSO Connectを有効にする

特定のグループでKeeper SSO Connectを有効にするには、[Service status] (サービスステータス) の左側にある[Groups] (グループ) を選択し、Keeper SSO Connectに関連付けたいグループを検索して選択し、ONをチェックして[SAVE] (保存) をクリックします。

注: Googleは現在Keeperチームへのグループプロビジョニングに対応していません。

Google Workspaceメタデータをインポート

Keeper管理コンソールに戻り、SSO Connect Cloudプロビジョニングメソッドを見つけて[編集]を選択します。

SSO Connect Cloudを編集

[Browse Files] (ファイルを参照) を選択し、以前にダウンロードしたGoogleメタデータファイルを選択します。

Googleメタデータファイルをアップロード

メタデータファイルがプロビジョニングメソッドに反映されると、成功したことになります。 これで、プロビジョニング設定を終了します。

Google Workspaceのシングルログアウト (SLO) 設定に関する注意

2022年現在、Googleはシングルログアウトを有効にしない設定をデフォルトにしています。 つまり、KeeperからログアウトしてもGoogleからの完全なログアウトは開始されません。

SSOの設定が完了しました。

これでKeeper SSO ConnectをGoogle Workspaceと連携させる設定は完了となります。以下の手順で、Googleアカウントを使用してKeeperにログインできるようになります。

  1. Keeperボルトを開き、[法人SSOログイン]をクリックします。

  2. SSOの設定時にKeeper管理コンソールに指定した法人ドメインを入力します。SSO Connectのステータス画面ではSSO Connectドメインという名前になっています。

  3. [接続]をクリックし、Google Workspaceの認証情報でログインします。

エンドユーザーの操作手順(Keeperが起点となるログイン)については、以下をご参照ください。 https://docs.keeper.io/user-guides/enterprise-end-user-setup-sso#keeper-initiated-login-flow

以下はSSOエンドユーザー向け動画です。 https://vimeo.com/329680541

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

次に、Google Workspaceからユーザーとチームのプロビジョニングを設定する方法を解説します。 Google Workspaceと統合するには以下の2つの方法があります。

オプション 1 (推奨): ユーザーとグループのプロビジョニング

Google WorkspaceではSCIMグループがネイティブでサポートされていないため、Keeperではユーザーとグループのプロビジョニングを自動化するためにGoogle Workspaceと統合するGoogle Cloud Functionを開発しました。このサービスの設定手順については、以下をご参照ください。

Cloud Serviceを使用したGoogle Workplaceのユーザーとチームのプロビジョニング

オプション 2: ユーザーのみをプロビジョニングする

SCIM直接統合を使用して直接Google WorkspaceからKeeperへのユーザー (グループではなくユーザーのみ) をプロビジョニングする手順については、以下をご参照ください。

SCIMを使用したGoogle Workplaceユーザープロビジョニング

Cloud Serviceを使用したGoogle Workplaceのユーザーとチームのプロビジョニング

Cloud Functionを使用してGoogle Workspaceからユーザーとグループを自動的にプロビジョニングする方法

概要

Google Cloud Functionを使用してGoogle WorkspaceからKeeperにユーザーを自動的にプロビジョニングする方法について解説します。これには、ユーザー、グループ、ユーザー割り当てのプロビジョニングが含まれます。ユーザーとチームのプロビジョニングには、ライフサイクル管理のためのいくつかの機能が備わっています。

  • どのGoogleグループやユーザーをKeeperにプロビジョニングするかを指定できます。

  • Keeperに割り当てられたGoogleグループはKeeperチームとして作成されます。

  • Keeperチームをボルト内の共有フォルダに割り当てられます。

  • グループに追加された新しいユーザーは自動的にKeeperに招待されます。

  • グループとユーザーの割り当ては同期のたびに適用されます。

  • ユーザーのプロビジョニングが解除されると、Keeperカウントが自動的にロックされます。

本ページの設定手順で、Google Workspaceアカウントからユーザーとグループをプロビジョニングします。設定には以下のリソースにアクセスする必要があります。

  • ​Google Cloud​

  • ​Google Workspace​

  • ​Keeper管理コンソール​

  • ​Keeperボルト​

  • ​Keeperシークレットマネージャー​

この実装ではKeeperシークレットマネージャーを使用して、最小限の権限でGoogleとKeeperを最も安全に統合します。Keeperシークレットマネージャーをご使用でない場合は、Keeperカスタマーサクセス チームにお問い合わせください。

手順 1. Google Cloudプロジェクトの作成

Google Cloudにログインし、プロジェクトを作成するか既存のプロジェクトを選択します。プロジェクト名は「Keeper SCIM Push」など任意の名前にします。

新しいGoogle Cloudプロジェクトを作成

手順 2. Admin SDK APIを有効にする

  • APIs & Servicesで、[+ ENABLE APIS AND SERVICES] (APIとサービスを有効にする) をクリックします。

  • Search for APIs & Servicesで、Admin SDK APIを入力します。

  • [ENABLE] (有効にする) をクリックします。

APIとサービスを有効にする
Admin SDK APIを有効にする

手順 3. サービスアカウントを作成

ここで作成したサービスアカウントは、Google Workspaceのユーザーとグループの情報にアクセスするために使用されます。

  • IAM and Adminメニューで、Service accounts (サービスアカウント)を選択します。

  • keeper-scimというサービスアカウント名で[+ CREATE SERVICE ACCOUNT]をクリックします。

Create Service Account

新規作成のサービスアカウントの場合、Actionsの3つの点をクリックして[Manage keys] (キーの管理) を選択します。

キーとcredentials.jsonの作成

[ADD KEYS] (鍵を追加) から[Create new Key] (新しい鍵を作成) をクリックし、鍵のタイプとして[JSON]を選択してから[CREATE] (作成) をクリックします。

サービスアカウントの認証情報が含まれたJSONファイルがコンピュータにダウンロードされます。

新しい鍵を作成
JSON形式を選択

ファイル名をcredentials.jsonに変更し、上のセットアップ手順で作成したKeeper設定レコードに添付ファイルとして追加します。

credentials.jsonとして保存

手順 4. Client IDをコピー

サービスアカウントへと移動し、[DETAILS]タブから[Advanced Settings]へ進みます。

[Domain-wide delegation]でClient IDをコピーします。次の手順でこのClient IDにGoogle Workspace Directoryへのアクセスを付与します。

Client IDをコピー

手順 5. Google Workspaceでサービスアカウントを承認

Google Workspace Panel (https://admin.google.com)で以下を行います。

  • [Security] (セキュリティ) > [API controls] (API制御) へ進みます。

  • Domain wide delegationの下の[MANAGE DOMAIN WIDE DELEGATION]をクリックします。

  • API Clientsで[Add new]をクリックします。

  • 前の手順でコピーしたClient IDを貼り付けます。

以下のテキストをOAuth scopes (comma-delimited)に貼り付けます。

https://www.googleapis.com/auth/admin.directory.group.readonly,https://www.googleapis.com/auth/admin.directory.group.member.readonly,https://www.googleapis.com/auth/admin.directory.user.readonly
新しいClient IDを追加

[AUTHORIZE] (承認) をクリックします。これらのスコープにより、サービスアカウントにGoogle Workspaceディレクトリユーザー、グループ、メンバーシップへの読み取り専用アクセスが付与されます。

手順 6. Primary Emailを取得

  • Google Workspace (https://admin.google.com) で[Account] (アカウント) > [Account settings] (アカウント設定) へ進みます。

  • 次の手順で使うため、Primary adminメールアドレス (右上) をクリップボードにコピーします。

Primary adminのメールアドレスを取得

手順 7. Keeperボルトで共有フォルダを作成

Keeperボルトで、新しい共有フォルダを作成します。このフォルダーには「Google SCIM Push」などの任意の名前を付けます。ユーザー権限とレコード権限については、任意の権限を選択します。

新しい共有フォルダを作成

STEP 8. シークレットマネージャを作成

ボルトでKeeperシークレットマネージャーを有効にしてから、左側のメニューから[シークレットマネージャー]をクリックし、[アプリケーションの作成]を選択します。

アプリケーションの作成

アプリケーションに「Google SCIM Push」などの名前を付けて、[アクセストークンの作成]をクリックします。 このトークンは破棄され、このシナリオでは使用されません。

アクセストークンの生成

次に、一覧から「Google SCIM Push」を選択し、[編集]、[デバイスの追加]の順にクリックします。

アプリケーションを編集
デバイスの追加

設定タイプにはBase64を選択してコンピュータにダウンロードします。

ファイルをconfig.base64としてコンピュータに保存します。

config.base64を保存

手順 9. SCIMプロビジョニングメソッドを作成

Keeper管理コンソールから、Google Workspaceノードの[プロビジョニング]タブに移動し、[メソッドを追加]をクリックします。

SCIMを選択して[次へ]をクリックします。

KeeperでのSCIM設定

[プロビジョニングトークンを作成]をクリックします。

プロビジョニングトークンの作成

URLとトークンが表示されるので、URLとトークンをファイルに一時的に保存してから、[保存] をクリックします。

SCIM URLとトークンを保存

URLとトークンを必ず保存してから[保存] をクリックするようにします。 これらのパラメータは次の手順で必要となります。

手順 10. 共有フォルダでKeeperレコードを作成

手順7で作成した共有フォルダ内に、以下のフィールドを含むレコードを作成します。

フィールド
値

ログイン

Google Workspace admin email

パスワード

手順9で生成したSCIMトークン

ウェブサイトアドレス

手順9で生成したSCIM URL

credentials.json

手順3のGoogle Serviceアカウント認証情報の添付ファイル

SCIM Group

プロビジョニングされるすべてのグループのリストを含む複数行のカスタムテキストフィールド。名前はグループメールかグループ名のいずれかとなります。

指定したグループとそのユーザーがKeeperにプロビジョニングされます。

Keeperボルトのレコード

グループのリストには、グループのメールアドレスかグループ名のいずれかを指定できます。Keeperがいずれかの値を照合し、関連するすべてのユーザーとグループをプロビジョニングします。

この時点で、Keeper側の設定は完了となります。残りの手順はGoogle CloudコンソールでのCloud Functionの設定となります。

手順 11. Google Cloud Functionを作成

Google CloudコンソールからCloud Functionsを開き、[関数を作成]をクリックします。

Functionの作成

Basics:

  • Environment (環境) に2nd gen (第2世代) を選択します。

  • Function name (関数名) は「keeper-scim-push」にします。

  • Region (地域) には任意の地域を選択してメモしておきます。

  • TriggerのTrigger typeををHTTPSにします。

  • Authentication (認証) を「Require authentication」 (認証が必要) にします。

Advanced -> Runtime:

  • Memory allocated (メモリの割り当て) : 256MiB

  • CPU: 0.333

  • Timeout (タイムアウト) : 120秒

  • Concurrency (同時実行) のコンテナあたりの最大リクエスト数: 1

  • Autoscaling (自動スケーリング) のインスタンスの最小数 : 0

  • Autoscaling (自動スケーリング) のインスタンスの最大数 : 1

  • Runtime service account (ランタイムサービスアカウント) : 選択

  • Runtime service account (ランタイムサービスアカウント) で, 「Default compute service account」を選択

Default compute service accountがまだ存在しない場合は、一時的に別のアカウントを選択し保存してから戻ってサービスアカウントを編集します。

以下は設定例です。

ランタイムの設定

Runtime environment variables (ランタイム環境変数)

変数を2つ作成します。

  • Name 1をKSM_CONFIG_BASE64、Value 1を手順8で生成したKSM設定ファイルの内容に設定します。

  • Name 2をKSM_RECORD_UID、Value 2を手順10でボルトで作成したレコードUIDに設定します。

Keeperボルトのレコードで情報アイコンをクリックすると、レコードUIDを確認できます。レコードUIDをクリックして値をコピーします。

[CONNECTIONS] (接続) をクリックし、[Allow internal traffic only] (内部トラフィックのみ) を選択します。

[Allow internal traffic only] (内部トラフィックのみ)

下へスクロールして[NEXT] (次へ) をクリックし、Cloud Function Sourceをアップロードします。

NEXTをクリック

手順 12. Cloud Function Sourceをアップロード

  • Keeper Google SCIM Pushのリリースページへ移動します。 https://github.com/Keeper-Security/ksm-google-scim/releases

  • source.zipファイルをダウンロードしてコンピュータに保存します。

Cloud Function Code Source
  • Runtime (ランタイム) は「Go 1.21」にします。

  • Source code (ソースコード) にはZip Uploadを選択します。

  • Entry point (エントリーポイント) にはGcpScimSyncHttpを入力します。

  • Zip upload (Zipアップロード) のDestination bucketには、デフォルトバケット許可 (非公開) を用いて任意の名前のバケットを作成します。

  • Zip file (Zipファイル) : 前の手順で保存したsource.zipを アップロードします。

[DEPLOY] (デプロイ) をクリックしてクラウド関数を作成します。 数分後、関数が作成され、パブリッシュされます。

この関数はプライベートであり、認証を必要とするため、次の手順ではCloud Schedulerを作成します。

手順 13. Cloud Function URLをコピー

Cloud Function画面で、以下に見られるようにURLをコピーします。

手順 14. Cloud Schedulerを作成

Google Cloudコンソールで、Cloud Schedulerを検索して開きます。

Cloudスケジューラ
  • [SCHEDULE A JOB] (ジョブをスケジュール) をクリックします。

以下のようにスケジュールを定義します。

  • 「Keeper SCIM Push for Google Workspace」など、任意の名前を付けます。

  • 1時間に1回実行の場合0 * * * *など、頻度を設定します。

  • ロケーションに応じてタイムゾーンを設定します。

  • Target type (ターゲットタイプ) をHTTPにします。

  • URLを手順13でコピーしたCloud Function URLに設定します。

  • HTTP method (HTTPメソッド) をGETに設定します。

  • Auth Header (Authヘッダ) をAdd OIDC tokenに設定します。

  • ServiceアカウントをDefault compute service accountに設定します。

  • [CONTINUE] (続行) 、[CREATE] (作成) の順にクリックします。

手順 15. Schedulerをテスト

Scheduler Jobs画面にジョブが表示されます。強制的に実行するには、右側のオーバーフロー メニューをクリックし、[Force run] (強制実行) を選択します。

即座にCloud Functionが実行されます。

成功すると、[Status of last execution] (最後の実行のステータス) に[Success] (成功) と表示されます。

スケジューラSuccess

Keeperが同期情報を受信したことを確認するには、Keeper管理コンソールにログインします。保留中および招待状態のユーザー、チーム、チーム割り当てのリストが表示されます。

手順 16. ローカルファイルを削除

プロセスが正常に動作すると、この過程で作成されたすべてのローカルファイルとシークレットを削除します。

重要: 以下のような、コンピュータにあるローカルファイルや一時ファイルをすべて削除します。

  • config.base64ファイル

  • credentials.jsonファイル

  • SCIMトークン

  • その他スクリーンショットやローカルファイル

破壊操作

デフォルトでは、Keeper管理コンソール内の管理されていないチームとチーム割り当てが同期処理中に削除されることはありません。ただし、管理されていないチームもチーム割り当てもすべて削除される同期方法をご希望の場合は、Keeperレコードにカスタムフィールドを作成して特定の値を入力します。

Destructiveフィールドの値
説明

-1

同期中Keeper側では何も削除されません

0 (デフォルト)

同期中、SCIM で制御されているグループとメンバーシップのみが削除されます (デフォルト設定)

1

同期中、手動で作成されたグループやメンバーシップとSCIMで制御されたグループやメンバーシップが削除されます。

デバッグログ

Keeperレコードを変更することで、Google Cloud Functionログに詳細なログを作成できます。

Verboseフィールドの値
説明

0 (デフォルト)

ログなし

1

詳細ログが有効

同期について

  • Keeperは、Cloud Functionプロビジョニングを実行する際に、グループ名またはグループのメールアドレスに対して厳密な文字列照合を実行します。グループ名とグループメールアドレスでは大文字と小文字が区別されます。

  • 招待状態のユーザーは、ユーザーがボルトを作成し、Keeper管理者が管理コンソールにログインするまで、割り当てられたチームに追加されされることはありません。 ユーザーのチームへの参加も、チームの別のメンバーがボルトにログインする際に行われます。管理コンソールから[同期]をクリックすることでもチーム参加が行われます。

  • チームの作成などの一部の操作は、Keeper管理コンソールへのログイン時、またはKeeper Automatorの実行時にのみ発生します。これは、暗号化キーを生成する必要があるためです。

  • 大規模なデプロイの場合、Keeper Automatorを設定して、デバイスの承認、ユーザーの承認、チームの承認のプロセスを自動化することを推奨します。

  • 新しいグループを追加する場合は、Keeperボルトのレコード内のリストにグループを追加します (手順10参照)。Keeperがターゲットを識別する際にはグループのメールアドレスまたはグループ名のいずれかを照会します。

  • Google Workspaceでネストされたグループは、Keeperと同期する際にフラット化されます。 ネストされたグループのユーザーは、Keeper側の親グループに追加されます。

Cloud Function Sourceの更新

Cloud Functionの新しいバージョンが作成される際のコードのアップデートは簡単です。

  • Githubリポジトリのksm-google-scimのリリースページから新しいsource.zipファイルをダウンロードします。

  • Google CloudのCloud Functionsの箇所へ移動します。

  • Cloud Functionの詳細をクリックし、[EDIT]をクリックしします。

  • Codeをクリックします。

  • Source codeで、[ZIP Upload]を選択します。

  • コンピュータに保存したsource.zipファイルを選択します。

  • [DEPLOY] (デプロイ) をクリックします。

  • 新しい関数がデプロイされるまで数分間待ちます。

  • Cloud Schedulerへ移動します。

  • [Actions] > [Force Run]をクリックします。

SCIMを使用したGoogle Workplaceユーザープロビジョニング

SCIMを直接Google Workplaceに統合してユーザープロビジョニング

本ページでは、SCIMの直接統合を使用してGoogle WorkspaceからKeeper にユーザーをプロビジョニングする手順について解説します。このメソッドでは、グループとグループ割り当てのプッシュがサポートされていません。グループプッシュとグループ割り当てが必要な場合は、「Cloud Serviceを使用したGoogle Workspaceユーザーとチームのプロビジョニング」のページをご参照ください。

概要

ユーザー プロビジョニングには、以下のライフサイクルマネジメント向け機能が備わっています。

  • Google Workspaceに新しくユーザーを追加すると、そのユーザーにKeeperボルトセットアップの招待メールが届きます。

  • ユーザーは、ユーザーまたはチーム単位でKeeperに割り当てることができます。

  • ユーザーのプロビジョニングが解除されると、Keeperアカウントが自動的にロックされます。

Keeper管理コンソールから、Google Workspaceノードの[プロビジョニング]タブに移動し、[メソッドを追加]をクリックします。

SCIMを選択して[次へ]をクリックします。

[プロビジョニングトークンを作成]をクリックします。

次の画面に表示されるURLとトークンは、Google Workspace管理コンソールで必要となりますので、URLとトークンをファイルに一時的に保存してから[保存] をクリックします。

URLとトークンを必ず保存してから[保存] をクリックするようにします。 これらのパラメータは次の手順で必要となります。

Google Workspace管理コンソールに戻って、Home (ホーム) > [Apps] (アプリ) > [SAML Apps] (SAMLアプリ) に移動し、セットアップしたKeeperの横の[Provisioning Available] (プロビジョニングが利用可能) というテキストをクリックします。

ページ下部にある[Configure auto-provisioning] (自動プロビジョニングの設定) を選択します。

SCIMプロビジョニング

手順 1: アプリケーションの認証

Keeper管理コンソールでSCIMプロビジョニングメソッドを作成したときに保存したアクセストークンを貼り付け、[CONTINUE] (続行) をクリックします。

手順 2: エンドポイントURL

Keeper 管理コンソールでSCIMプロビジョニングメソッドを作成したときに保存したエンドポイント URLを貼り付け、[CONTINUE] (続行) をクリックします。

手順 3: デフォルトの属性マッピング

デフォルトの属性マッピングのまま[CONTINUE] (続行) をクリックします。

手順 4: Provisioning Scope (プロビジョニングスコープ)

Keeper SSO Connectに割り当てられたすべてのユーザーをプロビジョニングする場合は、[CONTINUE] (続行) をクリックします。

手順 5: Deprovisioning (プロビジョニング解除)

Deprovisioning (プロビジョニング解除) 画面で、[FINISH] (完了)をクリックすると、ユーザーのプロビジョニング解除を自動化できます。

Auto-provisioning (自動プロビジョニング) を有効にする

自動プロビジョニングのセットアップが完了すると、Keeperの詳細画面に戻ります。自動プロビジョニングが非アクティブになっているのでアクティブに切り替えます。

切り替えた後、自動プロビジョニングをアクティブにする準備ができていることを確認するポップアウトウィンドウが表示されるので、[TURN ON]をクリックします。

Keeperの詳細画面に戻ると、自動プロビジョニングがアクティブになっています。

自動プロビジョニングの設定が完了しました。今後、Google WorkspaceでKeeperを使用するように設定され、プロビジョニングスコープの定義内にある新しいユーザーは、Keeperボルト使用の招待を受け取り、Google Workspaceの制御下に置かれます。

SSOを使用せずにSCIMでユーザーをプロビジョニング

Google Workspace SCIMプロビジョニングを介してKeeperにユーザーをプロビジョニングしつつSSOでユーザーを認証しない場合は、以下の手順を行います。

  1. 上記のSSO設定の場合と同じ手順に従い、サービスプロバイダの詳細画面でACS URLとEntity IDを、コントロール内のドメインを指し、通信可能なソースがないNULL値で置き換えます。 例: Entity ID=https://null.yourdomain.com/sso-connect ACS URL=https://null.yourdomain.com/sso-connect/saml/sso

  2. Google Workspaceで Keeper アプリケーションがセットアップされると、本ページで前述した通りに自動プロビジョニングメソッドを有効にします。

注: Googleは現在Keeperチームへのグループプロビジョニングに対応していません。

トラブルシューティング

「not_a_saml_app」というエラーが表示された場合は、SAML アプリケーションで「自動プロビジョニング」が「オン」になっていることを確かにしてください。

Google証明書の更新

SAMLアサーションへの署名用GoogleのIdP x.509証明書は5年後に期限が切れるように設定されています。Google Workspaceの[Manage Certificates] (証明書の管理) の箇所で有効期限をメモし、将来の機能停止を防ぐためにカレンダーのアラートを設定する必要があります。

証明書の有効期限が迫っている場合や証明書の有効期限が切れている場合は、以下の手順に従います。

  1. Google Workspace管理コンソールにログインします。

  2. [アプリ]をクリックしてから[ウェブアプリとモバイルアプリ]を選択します。

  3. Keeperを選択します。

  4. サービスプロバイダを開きます。

  5. [証明書を管理]をクリックします。

  6. [ADD CERTIFICATE] (証明書の追加) をクリックします。

  7. [DOWNLOAD METADATA] (メタデータのダウンロード) をクリックします。  

  8. メタデータファイルを保存します。これがIdPメタデータとなります。

  9. Keeper管理コンソールへログインします。

  10. [管理者] > SSOノード > プロビジョニングへ移動し、SSO Cloudプロビジョニングメソッドを編集します。

  11. Google IdPメタデータをKeeperへアップロードします。

本件の詳細については、以下のGoogleサポートページをご参照ください。

https://support.google.com/a/answer/7394709

既存のユーザーや初期管理者をSSO認証に移行させる

ルートノード (最上位) で作成されたユーザーは、SSO統合が設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスする際にマスターパスワードの入力が必要となります。

管理者は、SSOが有効になっているノードに自分自身を移動することはできません。この操作を実行するには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、最初に[法人SSOログイン]のプルダウンを選択し、SSO統合で設定した法人ドメインを入力し、Keeperボルトにログインする必要があります。また、マスターパスワード入力による確認を求められる場合があります。

Initially select 'Enterprise SSO Login'

SSOで認証されると、それ以降はメールアドレスだけでSSO認証を開始できます。

メールアドレスを入力して[次へ]をクリックしてもユーザーが目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。ルーティングとドメイン予約の詳細については、こちらをご覧ください。

HENNGE

KeeperクラウドSSOコネクトをHENNGEと連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。

HENNGE SSO設定

  1. HENNGE管理者コンソールへログインします。

メニューの[Administration] (管理) タイルをクリックします。

  1. [Connected Services] (接続済みサービス) を選択し、[Add Service] (サービスを追加) をクリックします。

[Add New Service] (新規サービスを追加) ページの[Add Service for SSO]で、[Add Service Manually] (手動でサービスを追加) をクリックします。

  1. サービス名を「Keeper Password Manager and Digital Vault」など任意の名前に設定し、「UsePrincipleName (UPN)」という値の属性Emailクレームを追加して[Submit]ボタンをクリックします。

お使いの環境で、user.userprincipalname (UPN) がユーザーの実際のメールアドレスと異なる場合は、Emailクレームを編集して、Email属性の値をuser.mailに変更できます。

これで、手順5のKeeper 側の設定に必要な値がすべて表示されます。右上の[X]をクリックして、このページから一旦離れます。

[Connected Services menu] (接続サービス) メニューで作成したサービス名をクリックし、[Upload Using Metadata] (メタデータを使用してアップロード) ボタンをクリックします。

Keeper メタデータは管理コンソールで利用できます。 プロビジョニングのメソッド -> [表示] -> [メタデータをエクスポート]に移動します。

  1. メタデータをアップロードした後、HENNGE Connected Service設定ページに戻り、https://keepersecurity.com/api/rest/sso/ext_login/<SSOID>のようにログインURLを入力します。

SSO IDはSPエンティティIDの末尾にあります。 例: https://keepersecurity.com/api/rest/sso/saml/3534758084794

ページの一番下までスクロールし、[Save Changes] (変更を保存) ボタンを選択して設定を完了します。

  1. 最後に、このコネクタからメタデータをエクスポートしてKeeper SSO Connect Cloud™へインポートします。

HENNGEメタデータのインポート

[IDPタイプ]を[Generic]に設定し、このファイルを編集画面にドラッグアンドドロップしてKeeper SSO Connect Cloud™ プロビジョニングインターフェイスにアップロードします。

ユーザーの割り当て

HENNGEで、[User list] (ユーザーリスト) ページの [Access Policy] (アクセスポリシー) でユーザーを追加したり、[Access Policy Groups] (アクセスポリシーグループ) ページの[Allowed services] ( 許可されたサービス) の箇所でグループを追加したりできるようになりました。

グループの割り当て
グループの割り当て

KeeperクラウドSSOコネクトのセットアップが完了しました。

既存のユーザー/初期管理者をSSO認証に移行

ルートノード (最上位) で作成されたユーザーは、SSOが設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスする際にマスターパスワードの入力を求められます。

管理者は、SSOが有効になっているノードに自分自身を移動できません。この操作を行うには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、最初に[法人SSOログイン]のプルダウンからSSO統合で設定した法人ドメインを入力し、Keeperボルトにログインする必要があります。また、マスターパスワード入力による確認を求められる場合があります。

まず[法人SSOログイン]を選択

SSOで認証されると、それ以降はメールアドレスだけでSSO認証を開始できます。

法人ドメインを入力する必要はありません。メールアドレスを入力して[次へ]をクリックしても目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。 ルーティングとドメイン予約の詳細については、こちらをご覧ください。

Imprivata (英語)

只今本ページの日本語化を進めております。以下の英語版ページをご利用ください。

LogoImprivata | Keeper Documentation

JumpCloud

KeeperクラウドSSOコネクトをJumpCloudと連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。

JumpCloud

  1. JumpCloud管理者コンソールにログインします。

サイドメニューのSSOタブを選択します。

  1. 次に、左上隅の + アイコンを選択します。

「SSOアプリケーションを導入する (Get Started with SSO Application)」ページの検索バーで、Keeperを検索します。Keeperアプリケーションの設定 (Configure) を選択します。

  1. 次に、Keeperアプリケーションのコネクタページの一般情報 (General Info) セクションで、表示ラベル (Display Label) を設定します。 Keeper Securityパスワードマネージャ

JumpCloudの一般情報

シングルサインオン設定 (Single Sign-On Configuration) で、[メタデータをアップロード (Upload Metadata)] ボタンをクリックします。

Keeperのメタデータは管理コンソールで取得できます。 プロビジョニングインスタンス -> 表示 (View) -> メタデータをエクスポート (Export Metadata) に移動します。

  1. メタデータをアップロードしたら、JumpCloudのSSO設定ページに戻り、ログインURLをhttps://keepersecurity.com/api/rest/sso/ext_login/<ご利用のSSO IDをこちらに入力> のように入力します。

ご利用のSSO IDは、SPエンティティIDの最後に記載されています。 例: https://keepersecurity.com/api/rest/sso/saml/459561502469

ページの一番下までスクロールして設定を完了し、[有効化 (activate)] ボタンを選択します。

JumpCloudでKeeperを有効化
  1. 最後の手順では、このコネクタからメタデータをエクスポートして、KeeperクラウドSSOコネクトにインポートします。

JumpCloudメタデータをエクスポート

IDPタイプ (IDP Type) を汎用 (GENERIC) に設定し、このファイルを編集画面にドラッグアンドドロップして、KeeperクラウドSSOコネクトのプロビジョニングインターフェースにアップロードします。

KeeperクラウドSSOコネクトのセットアップが完了しました。

ユーザープロビジョニング SSO+SCIM

JumpCloud®はSCIM (System for Cross Domain Identity Management) によるユーザーおよびチームの自動プロビジョニングをサポートしており、JumpCloud®で変更が加えられると、Keeperユーザーアカウントを更新して無効化します。 順を追った説明は、こちらのページでご確認ください。

既存のユーザー/初期管理者をSSO認証に移行

ルートノード (最上位) で作成されたユーザーは、SSOが設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスする際にマスターパスワードの入力を求められます。

管理者は、SSOが有効になっているノードに自分自身を移動できません。この操作を行うには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、最初に[法人SSOログイン]のプルダウンからSSO統合で設定した法人ドメインを入力し、Keeperボルトにログインする必要があります。また、マスターパスワード入力による確認を求められる場合があります。

まず[法人SSOログイン]を選択

SSOで認証されると、それ以降はメールアドレスだけでSSO認証を開始できます。

法人ドメインを入力する必要はありません。メールアドレスを入力して[次へ]をクリックしても目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。 ルーティングとドメイン予約の詳細については、こちらをご覧ください。

Microsoft AD FS

Keeper SSO Connect CloudをMicrosoft AD FSと連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。

Microsoft AD FS

フェデレーションメタデータXMLを取得

AD FS管理アプリケーション内で、フェデレーションメタデータxmlファイルを特定します。AD FS > Service (サービス) > Endpoint (エンドポイント) をクリックしてから、「Metadata」 (メタデータ) セクションでURLのパスを探して確認します。パスは通常以下に見られるように、/FederationMetadata/2007-06/FederationMetadata.xmlとなります。

フェデレーションメタデータXMLファイルの場所
メタデータのパス

メタデータをダウンロード

メタデータファイルをダウンロードするには通常サーバー上でブラウザにURLをロードします。 以下はその例です。 https://localhost/FederationMetadata/2007-06/FederationMetadata.xml このファイルをダウンロードして、コンピュータに保存します。

メタデータXMLファイルをダウンロード

フェデレーションメタデータをインポート

Keeper管理コンソールのSSOクラウド設定画面で、IdPタイプとして[ADFS]を選択し、前の手順で保存したフェデレーションメタデータファイルをインポートします。

IDPタイプを選択してSAMLメタデータをアップロード

Keeperメタデータをエクスポート

プロビジョニング画面に戻り、[表示]をクリックします。

設定を表示

次に、後ほど証明書利用者信頼 (Relying Party Trust) ウィザードでインポートするため、Keeperメタデータファイルをダウンロードします。Keeper SSO Connect Cloud™のプロビジョニングの[表示]をクリックします。

[メタデータをエクスポート]ボタンをクリックして、config.xmlファイルをダウンロードします。

メタデータをエクスポート

AD FSの設定を完了

KeeperのCloud SSO SP証明書の有効期限は1年間のみです。毎年、管理コンソールから最新のKeeper SP証明書をダウンロードして、AD FSのRelying Party Trust (証明書利用者信頼) の設定にアップロードする必要があります。

証明書の有効期限が迫っている際には、Keeperからすべてのユーザーにお知らせします。

証明書利用者信頼 (Relying Party Trust) を作成

Keeper SSO Connectを証明書利用者信頼として作成します。

証明書利用者信頼を追加

Keeperメタデータをインポート

以下に見られるように、証明書利用者信頼 (Relying Party Trust) ウィザードを完了して、Keeper SSO Connect Cloudの表示画面から前もってエクスポートしたKeeperメタデータファイルをインポートします。

Welcome (ようこそ) 画面で[Claim aware] (要求に対応する) を選択し、Keeperから保存したメタデータファイルを選択します。

Keeperメタデータをインポート
表示名にKeeper SSO Connect Cloudを入力
アクセス制御ポリシーを選択
SAMLログアウトエンドポイント

ログアウトエラーを防ぐには、証明書利用者信頼 (Relying Party Trust) のSAMLログアウトエンドポイントをhttps://<ご利用のADFSサーバーのドメイン名>/adfs/ls/?wa=wsignout1.0に変更します。

要求発行ポリシーを設定
証明書利用者信頼

要求発行ポリシー規則を作成

AD FSとKeeperの間で属性をマッピングするには、[LDAP 属性を要求として送信する] (Send LDAP Attributes as Claims) で要求発行ポリシーを作成し、LDAPの属性をKeeper Connectの属性にマッピングする必要があります。

要求発行ポリシーを編集
規則を追加
規則のタイプを選択
要求規則名 - マッピング

3つの属性 (First (名)、Last (姓)、Email (メール)) が上記のように正確なスペルで設定されていることをご確認ください。

発行変換規則

ログアウトのサポート用に、さらに2つの要求発行ポリシー規則を追加する必要があります。

カスタム規則を使用して要求を送信
不透明な永続識別子を作成

要求規則に追加する構文をコピーするには、以下のテキストをコピーしてカスタム規則に貼り付けます。

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
 && c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant"]
 => add(store = "_OpaqueIdStore", types = ("http://mycompany/internal/sessionid"), query = "{0};{1};{2};{3};{4}", param = "useEntropy", param = c1.Value, param = c1.OriginalIssuer, param = "", param = c2.Value);
入力方向の要求を変換
永続名前識別子を作成

入力方向の要求の種類 (Incoming claim type): http://mycompany/internal/sessionid 送信方向の要求の種類 (Outgoing claim type) : Name ID (名前ID) 送信される名前IDの形式 (Outgoing name ID format) : Transient Identifier (一時識別子)

送信方向の要求と名前IDの形式を設定

SAML署名の設定

a. AD FSサーバーで管理者としてPowershellを開きます。 b. 以下のコマンドを実行してSSO Connect Relying Party Trust Identifier (証明書利用者信頼の識別子) の文字列を特定します。

Get-ADFSRelyingPartyTrust

このコマンドを実行すると、長い出力リストが生成されます。SSO Connectセクションと「識別子」(Identifier) の文字列を探します。 この文字列は以下のようになります。 https://keepersecurity.com/api/rest/sso/saml/459561502484

c.以下のコマンドを実行し、<Identifier>を手順(b)で見つけた文字列に置き換えます。

Set-ADFSRelyingPartyTrust -TargetIdentifier <Identifier> -samlResponseSignature MessageAndAssertion

Get-ADFSRelyingPartyTrustを再度実行すると、SamlResponseSignatureセクションが「MessageAndAssertion」に設定されていることが確認できます。

AD FSサービスを再起動

サービスマネージャから、AD FSサービスを再起動します。

SAMLアサーションの署名は、AD FS環境で適切に設定する必要があります。署名が設定されていない場合は、署名を設定してから、再設定後にAD FSとKeeper SSO Connect間でメタデータを再度交換する必要があります。

トラブルシューティング

テスト目的または内部PKI証明書のために、IdPでの証明書の有効性確認を無効にする必要がある場合は、以下のPowershellコマンドをご使用ください。 < Identifier>を上記の「SAML署名の設定」 の手順で特定した文字列に置き換えます。

Set-ADFSRelyingPartyTrust -TargetIdentifier 
<Identifier> -EncryptionCertificateRevocationCheck None
Set-ADFSRelyingPartyTrust -TargetIdentifier 
<Identifier> -SigningCertificateRevocationCheck None

備考: 署名設定に何らかの変更を加えると、IdPとSSO Connectの間でXMLメタデータの交換が必要になる場合があります。

既存のユーザー/初期管理者をSSO認証に移行

ルートノード (最上位) で作成されたユーザーは、SSOが設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスする際にマスターパスワードの入力を求められます。

管理者は、SSOが有効になっているノードに自分自身を移動できません。この操作を行うには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、最初に[法人SSOログイン]のプルダウンからSSO統合で設定した法人ドメインを入力し、Keeperボルトにログインする必要があります。また、マスターパスワード入力による確認を求められる場合があります。

まず[法人SSOログイン]を選択

SSOで認証されると、それ以降はメールアドレスだけでSSO認証を開始できます。

法人ドメインを入力する必要はありません。メールアドレスを入力して[次へ]をクリックしても目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。 ルーティングとドメイン予約の詳細については、こちらをご覧ください。

Okta

KeeperクラウドSSOコネクトをOktaと連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。

Okta SSOの設定

Oktaポータルの管理者セクションにログインします。

Okta管理者としてログイン

左側のメニューから[Applications] (アプリケーション) を選択して、[Browse App Catalog] (アプリカタログを見る) をクリックします。

Applications > Browse App Catalog

Keeperパスワードマネージャー (Keeper Password Manager) を検索し、Keeperパスワードマネージャ&デジタルボルト (Keeper Password Manager and Digital Vault) アプリケーションの[追加] (Add) ボタンを選択します。

Keeperを検索
アプリケーションを追加

次に表示される全般設定 (General Settings) ページで、Keeper管理コンソールに表示された「Entity ID」が必要になります。

サーバーベースURLの例: https://keepersecurity.com/api/rest/sso/saml/XXXXXXXX

XXXXXXXXの値は、ユーザーの企業に関連付けられた特定のSSO Connectインスタンスを表し、以下に示すように、サービスプロバイダ情報の一部として管理コンソールのSSO設定で確認できます。

設定を表示
エンティティIDをコピー

Okta画面のベースURL (Base URL) フィールドにエンティティIDを貼り付けます。

次に、サインオン (Sign On) タブを選択します。

サインオンタブ

SAML署名証明書の設定セクションまで下にスクロールし、アクション (Actions) > IdPメタデータを表示 (View IdP metadata) を選択します。

IdPメタデータを表示

表示されたXMLファイルをコンピュータに保存します。Chrome、Edge、Firefoxで、ファイル (File) > 名前を付けてページを保存... (Save Page As...) を選択して、metadata.xmlファイルを保存します。

metadata.xmlを保存

Keeper側でSSO設定を編集して、IDPタイプにOKTAを選択し、metadata.xmlファイルを参照するか、または設定画面にドラッグアンドドロップして、KeeperクラウドSSOコネクトインターフェースにアップロードします。

SSOの設定を編集
OktaからKeeperにメタデータファイルをドラッグアンドドロップ

(オプション) シングルログアウトを有効化

Oktaでシングルログアウト機能を有効にしたい場合は、サインオン (Sign On) タブに移動して、編集 (Edit) をクリックします。 「シングルログアウトを有効化(Enable Single Logout)」チェックボックスをクリックし、Keeper管理コンソールに表示されたSP証明書をアップロードします。

まずSP証明書をダウンロードするために、KeeperでSSO設定を表示し、SP証明書をエクスポート (Export SP Cert) ボタンをクリックします。

KeeperからSP証明書をエクスポート

SP証明書ファイルをアップロードし、[保存] (Save) を必ずクリックして、サインオン設定をOktaに保存してください。

証明書をアップロード

シングルログアウト設定を変更した場合は、最新のOktaメタデータファイルをダウンロードし直し、SSOの編集画面で新しいmetadata.xmlファイルをKeeperにアップロードする必要があります。

[Actions]メニューから、[View IdP metadata]を選択します。

IdPメタデータを表示

表示されたXMLファイルをコンピュータに保存します。Chrome、Edge、Firefoxで、ファイル (File) > 名前を付けてページを保存... (Save Page As...) を選択して、metadata.xmlファイルを保存します。

Keeper管理コンソール側でSSO設定を編集してから、新しいmetadata.xmlファイルを参照するか、セットアップ画面にドラッグアンドドロップして、Keeper SSO Connectインターフェースにアップロードします。

シングルログアウトコンフィグレーション設定を使用して新しいメタデータファイルをアップロード

Okta SCIMのプロビジョニング

Okta SCIMのユーザーおよびグループのプロビジョニングを有効にするには、こちらのエンタープライズガイドに記載されている手順に従ってください。

ユーザーの割り当て

Oktaから、割当 (Assignments) ページでユーザーまたはグループを追加できるようになりました。 こちらの手順に従ってSCIMプロビジョニングを有効化すると、ユーザーは即座にKeeperにプロビジョニングされます。

ユーザーおよびグループの割り当て

既存のユーザー/初期管理者をSSO認証に移行

ルートノード (最上位) で作成されたユーザーは、SSOが設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスする際にマスターパスワードの入力を求められます。

管理者は、SSOが有効になっているノードに自分自身を移動できません。この操作を行うには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、最初に[法人SSOログイン]のプルダウンからSSO統合で設定した法人ドメインを入力し、Keeperボルトにログインする必要があります。また、マスターパスワード入力による確認を求められる場合があります。

最初に「法人SSOログイン」を選択

SSOで認証されると、それ以降はメールアドレスだけでSSO認証を開始できます。

法人ドメインを入力する必要はありません。メールアドレスを入力して[次へ]をクリックしても目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。 ルーティングとドメイン予約の詳細については、こちらをご覧ください。

OneLogin

KeeperクラウドSSOコネクトをOneLoginと連携させて、スムーズで安全なSAML 2.0認証とSCIMプロビジョニングを実現

最初に管理コンソールの設定の手順を完了してください。

設定

  1. OneLoginポータルにログインします。

OneLoginにログイン
  1. 管理 (Administration) を選択して、管理者セクションに移動します。

  1. oneloginメニューから、アプリケーション (Applications)、アプリを追加 (Add App) の順に選択します。

検索フィールドでKeeperパスワードマネージャー (Keeper Password Manager) を検索し、検索結果から選択します。

Keeperパスワードマネージャを追加
  1. Keeperパスワードマネージャーを追加 (Add Keeper Password Manager) 画面で、保存 (Save) をクリックします。

  1. 次の手順で、OneLoginからSAMLメタデータをダウンロードします。その他のアクション (MORE ACTIONS) ボタンの下矢印を選択して、SAMLメタデータ (SAML Metadata) を選択します。

SAMLメタデータを保存

Keeper管理コンソールのクラウドSSOコネクトを使用したシングルサインオン (Single Sign-On with SSO Connect™ Cloud) セクションのSAMLメタデータ (SAML Metadata) セクションに、この保存したファイルをドラッグアンドドロップするか、または参照して入力します。

メタデータをアップロード
  1. Keeper管理コンソールで、ACSエンドポイント (Assertion Consumer Service (ACS) Endpoint) フィールドをコピーします。

  1. OneLoginの設定 (Configuration) タブに戻り、Keeper SSO ConnectのACSエンドポイント (Assertion Consumer Service (ACS) Endpoint) フィールドに貼り付け、[保存] (Save) をクリックします。

アサーションコンシューマーサービスエンドポイントを貼り付け
  1. SCIMを使用したい場合は、Keeperのプロビジョニング (Provisioning) タブに戻り、[メソッドを追加] (Add Method) をクリックして、SCIMを選択します。 使用しない場合は、省略して手順12に進みます。

SCIMメソッドを追加
  1. 生成 (Generate) をクリックし、URLとトークンをコピーします。

生成をクリック
  1. 「URL」をSCIMベースURL (SCIM Base URL) に、「トークン (Token)」をSCIMベアラートークン (SCIM Bearer Token) に貼り付けます。

  2. Keeper管理コンソールで、SCIMトークンを必ず保存してください。

SCIMの詳細な設定については、こちらのエンタープライズガイドのユーザーとチームのプロビジョニングセクションをご覧ください。

  1. 保存 (Save) をクリックして、連携を完了します。

既存のユーザー/初期管理者をSSO認証に移行

ルートノード (最上位) で作成されたユーザーは、SSOが設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスする際にマスターパスワードの入力を求められます。

管理者は、SSOが有効になっているノードに自分自身を移動できません。この操作を行うには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、最初に[法人SSOログイン]のプルダウンからSSO統合で設定した法人ドメインを入力し、Keeperボルトにログインする必要があります。また、マスターパスワード入力による確認を求められる場合があります。

まず[法人SSOログイン]を選択

SSOで認証されると、それ以降はメールアドレスだけでSSO認証を開始できます。

法人ドメインを入力する必要はありません。メールアドレスを入力して[次へ]をクリックしても目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。 ルーティングとドメイン予約の詳細については、こちらをご覧ください。

Ping Identity

KeeperクラウドSSOコネクトをPing Identityと連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。

Ping Identityの設定

Ping Identityポータルにログインします。

Ping Identityのメニューから、アプリケーション (Applications) を選択します。

次に、アプリケーションを追加 (Add Application) を選択し、新規SAMLアプリケーション (New SAML Application) を選択します。

アプリケーションの詳細 (Application Details) ページで、以下のデータを追加します。

  • アプリケーション名 (Application Name): Keeperパスワードマネージャー (Keeper Password Manager) アプリケーションの詳細 (Application Detail): パスワードマネージャー&デジタルボルト (Password Manager and Digital Vault) カテゴリ (Category): コンプライアンス (Compliance)(またはその他) 画像 (Graphic): Keeperの画像をアップロード[こちら]

続いて、次の手順に進む (Continue to Next Step) を選択します。

次の手順で、Ping IdentityからSAMLメタデータをダウンロードします。SAMLメタデータ (SAML Metadata) の隣のダウンロード (Download) リンクを選択します。

saml2-metadata-idp.xmlファイルがローカルコンピュータにダウンロードされます。 KeeperクラウドSSOコネクトのプロビジョニング編集 (Edit) 画面で、IDPタイプに汎用 (Generic) を選択し、saml2-metadata-idp.xmlファイルを参照するか、または設定画面にドラッグアンドドロップして、Keeper SSO Connectインターフェースにアップロードします。

設定画面

次に、Keeperのメタデータファイルをダウンロードし、Pingアプリケーションの設定にアップロードします。 KeeperクラウドSSOコネクトのプロビジョニングの表示画面に移動します。

表示画面を開く

「メタデータをエクスポート (Export Metadata)」ボタンをクリックして、config.xmlファイルをダウンロードします。

Keeperメタデータをエクスポート

Ping Identityアプリケーションの設定に戻って、ファイルを選択 (Select File) ボタンを選択し、上記の手順でダウンロードしたconfig.xmlを選択します。

Keeperメタデータをアップロード

次の手順に進む (Continue to Next Step) を選択します。

次の手順で、属性をマッピングします。新規属性を追加 (Add new attribute) ボタンを選択します。

  • 属性1では、アプリケーション属性 (Application Attribute) 列に「名 (First)」と入力し、IDブリッジ属性またはリテラル値 (Identity Bridge Attribute or Literal Value) 列でファーストネーム (First Name) を選択して、必須 (Required) ボタンをチェックします。新規属性を追加 (Add new attribute) ボタンを選択します。

  • 属性2では、アプリケーション属性 (Application Attribute) 列に「姓 (Last)」と入力し、IDブリッジ属性またはリテラル値 (Identity Bridge Attribute or Literal Value) 列でラストネーム (Last Name) を選択して、必須 (Required) ボタンをチェックします。新規属性を追加 (Add new attribute) ボタンを選択します。\

  • 属性3では、アプリケーション属性 (Application Attribute) 列に「メール (Email)」と入力し、IDブリッジ属性またはリテラル値 (Identity Bridge Attribute or Literal Value) 列でメール (Email) を選択して、必須 (Required) ボタンをチェックします。 アプリケーション属性: 名、姓、メールは大文字で始まる必要があります。

Keeperアプリケーションへのアクセスが必要なグループを選択します。 完了したら、「次の手順に進む (Continue to Next Step)」をクリックします。 設定内容を確認してから、完了 (Finish) ボタンを選択します。

Ping Identity設定のアプリケーションの設定 (Application Configuration) セクションで、「署名 (Signing)」セクションの「署名レスポンス (Sign Response)」の署名アルゴリズムとして、「RSA_SHA 256」が選択されていることをご確認ください。

Keeperアプリケーションが追加されて、有効になっているはずです。

Ping IdentityのKeeperアプリケーション

これでKeeper SSO Connectの設定は完了です。

既存のユーザー/初期管理者をSSO認証に移行

ルートノード (最上位) で作成されたユーザーは、SSOが設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスする際にマスターパスワードの入力を求められます。

管理者は、SSOが有効になっているノードに自分自身を移動できません。この操作を行うには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、最初に[法人SSOログイン]のプルダウンからSSO統合で設定した法人ドメインを入力し、Keeperボルトにログインする必要があります。また、マスターパスワード入力による確認を求められる場合があります。

まず[法人SSOログイン]を選択

SSOで認証されると、それ以降はメールアドレスだけでSSO認証を開始できます。

法人ドメインを入力する必要はありません。メールアドレスを入力して[次へ]をクリックしても目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。 ルーティングとドメイン予約の詳細については、こちらをご覧ください。

PingOne

KeeperクラウドSSOコネクトをPingOneと連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。PingOneを使用していない従来のPing Identityユーザーは、Ping Identityのドキュメントをご参照ください。

PingOne

PingOneポータル (https://admin.pingone.com/) にログインします。

PingOneにログイン

PingOneのコンソールメニューから、接続 (Connections) > アプリケーションカタログ (Application Catalog) を選択します。

「Keeper」を検索し、+をクリックして、Keeperパスワードマネージャー (Keeper Password Manager) アプリケーションを追加します。

PingOneにKeeperパスワードマネージャを追加

Keeper管理コンソールから、PingOne SSO Connect Cloudのエントリーを表示し、以下のスクリーンショットに示したKeeper SecurityドメインとKeeper Security識別子をメモします。

Keeper Securityのドメインと識別子を確認

前の手順のKeeper Securityドメイン (Keeper Security Domain) とKeeper Security識別子 (Keeper Security Identifier) を入力し、次へ (Next) をクリックします。

デフォルトのマッピングを承諾して、次へ (Next) をクリックします。

マッピングを設定

PingOneユーザーグループをアプリケーションに追加することもできます。 追加したいグループ (複数可) の隣の+をクリックし、保存 (Save) をクリックして、アプリケーションのセットアップウィザードを完了します。

PingOneユーザーは、デフォルトでKeeperパスワードマネージャにアクセスできるようになります。 Keeperパスワードマネージャにグループを割り当てることで、アクセスをそれらのグループだけに制限します。

必要に応じてPingOneユーザーグループを追加

メタデータをダウンロード (Download Metadata) をクリックします

PingOneからメタデータをダウンロード

Keeper SSO Connect Cloud™のプロビジョニングの編集 (Edit) 画面で、IDPタイプとして汎用 (Generic) を選択します。

前の手順でダウンロードしたSAMLメタデータファイルを参照するか、またはSAMLメタデータ (SAML Metadata) セクションにドラッグアンドドロップして、Keeper SSO Connectインターフェースにアップロードしてください。

PingOneのメタデータをKeeperにアップロード

これでPingOneのKeeper SSO Connect Cloud™エントリーの表示が有効 (Active) になります。

有効と表示されたKeeper SSO Connectエントリー

PingOne Keeper SSO Connect Cloud™の設定が完了しました。

既存のユーザー/初期管理者をSSO認証に移行

ルートノード (最上位) で作成されたユーザーは、SSOが設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスする際にマスターパスワードの入力を求められます。

管理者は、SSOが有効になっているノードに自分自身を移動できません。この操作を行うには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、最初に[法人SSOログイン]のプルダウンからSSO統合で設定した法人ドメインを入力し、Keeperボルトにログインする必要があります。また、マスターパスワード入力による確認を求められる場合があります。

まず[法人SSOログイン]を選択

SSOで認証されると、それ以降はメールアドレスだけでSSO認証を開始できます。

法人ドメインを入力する必要はありません。メールアドレスを入力して[次へ]をクリックしても目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。 ルーティングとドメイン予約の詳細については、こちらをご覧ください。

Rippling

KeeperクラウドSSOコネクトをRipplingとさせて、スムーズで安全なSAML 2.0認証とSCIMプロビジョニングを実現

最初に管理コンソールの設定の手順を完了してください。

Setup:

  1. Rippling管理コンソールにログインします。

  1. ログイン後、[Home] (ホーム)にカーソルを合わせて左下の[App Shop] (アプリショップ) をクリックします。

  1. App Shopの左上の検索バーでKeeperを検索し、検索結果からKeeperを選択します。

  1. Keeperをクリックして選択した後、[Connect Account] (アカウントを接続) をクリックししてSSO設定を始めます。

  1. Rippling側のSSOセットアップガイドを進んでセットアップを行います。

SAMLメタデータを保存
  1. 以下のページまで進むと、SSOセットアップは完了となりますが、任意でSCIMプロビジョニングをセットアップできます。SCIMプロビジョニングをセットアップする場合は[Continue with API] (APIを続ける) を選択してガイドを進みます。SCIMプロビジョニングをセットアップしない場合は、[Skip for now, visit app] (スキップしてアプリを開く) をクリックします。

ここでユーザーを割り当てて、Ripling環境でどのユーザーがKeeperにアクセスできるかを指定できます。

SCIM設定の詳細についてはエンタープライズガイドのユーザーとチームのプロビジョニングページをご参照ください。

既存のユーザー/初期管理者をSSO認証に移行

ルートノード (最上位) で作成されたユーザーは、SSOが設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスする際にマスターパスワードの入力を求められます。

管理者は、SSOが有効になっているノードに自分自身を移動できません。この操作を行うには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、最初に[法人SSOログイン]のプルダウンからSSO統合で設定した法人ドメインを入力し、Keeperボルトにログインする必要があります。また、マスターパスワード入力による確認を求められる場合があります。

まず[法人SSOログイン]を選択

SSOで認証されると、それ以降はメールアドレスだけでSSO認証を開始できます。

法人ドメインを入力する必要はありません。メールアドレスを入力して[次へ]をクリックしても目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。 ルーティングとドメイン予約の詳細については、こちらをご覧ください。

RSA SecurID Access

KeeperクラウドSSOコネクトをRSA SecurID Accessと連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。

Keeper SecurityはRSA SecurID Accessに認定されています。

RSA SecurID Accessには、RSA認証マネージャとそのクラウド認証サービスが統合されています。この設定によって、クラウド認証サービスをIDプロバイダとして使用し、Keeper SSOコネクトと組み合わせることができます。詳細については、以下のRSAのウェブサイトをご参照ください。

RSA SecurID Accessの概要

https://www.rsa.com/en-us/products/rsa-securid-suite/rsa-securid-access/identity-packagingwww.rsa.com
RSA SecurID Accessの概要

Keeperパスワードマネージャー連携ガイド

LogoAuthentication Agent Configuration - Keeper Password Manager 14.4 - RSA Ready SecurID Access Implementation GuideRSA Link
LogoRSA Community
SAML 2.0連携ガイド

SecureAuth

KeeperクラウドSSOコネクトをSecureAuthと連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。

SecureAuthは、その他のSAML 2.0プロバイダセクションと同じ手順で設定できます。SecureAuth環境を設定するには、そのガイドに従ってください。

参考までに、こちらのSecureAuthガイドをご使用ください。

LogoSAML application integration
SecureAuth SAMLアプリケーション連携

SecureAuthに関して注意すべきその他の重要事項:

  • 接続の種類 (Connection Type) セクションで、「POST方式 (By Post)」が選択されていることを確認します。

接続の種類
  • 「SAMLアサーションに署名 (Sign SAML Assertion)」と「SAMLメッセージに署名 (Sign SAML Message)」を必ず選択します。

  • IdPメタデータのエンティティIDがSecureAuthのSAMLレスポンスと一致することを確認します。

既存のユーザー/初期管理者をSSO認証に移行

ルートノード (最上位) で作成されたユーザーは、SSOが設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスする際にマスターパスワードの入力を求められます。

管理者は、SSOが有効になっているノードに自分自身を移動できません。この操作を行うには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、最初に[法人SSOログイン]のプルダウンからSSO統合で設定した法人ドメインを入力し、Keeperボルトにログインする必要があります。また、マスターパスワード入力による確認を求められる場合があります。

まず[法人SSOログイン]を選択

SSOで認証されると、それ以降はメールアドレスだけでSSO認証を開始できます。

法人ドメインを入力する必要はありません。メールアドレスを入力して[次へ]をクリックしても目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。 ルーティングとドメイン予約の詳細については、こちらをご覧ください。

Shibboleth

KeeperクラウドSSOコネクトとShibbolethでスムーズで安全なSAML 2.0認証とSCIMプロビジョニングを設定

最初に管理コンソールの設定の手順を完了してください。

手順 1. Keeperメタデータファイルをエクスポートして保存

Keeper管理コンソール内のSSO Connect Cloudプロビジョニングメソッドで[表示]を選択します。そこから、Keeperメタデータファイルをダウンロードして保存することができます。

Keeperメタデータファイルをエクスポート

手順 2. KeeperメタデータをShibbolethに追加

Shibbolethは、リライングパーティとしてのKeeperに関する基本情報を有している必要があります。その情報はSAMLメタデータで定義されていますので、Keeperメタデータファイルを IDP_HOME/metadata/ ディレクトリに追加します。

手順 3. 新規リライングパーティトラストをShibbolethに追加

IDP_HOME/conf/relying-party.xmlで新しいRelyingParty要素を定義することで、Keeperと通信する際にどのように動作するかをShibbolethに指示します。以下のコードをDefaultRelyingParty要素の直後に追加します。プロバイダ属性を法人IDに置き換えます (DefaultRelyingPartyで設定されているプロバイダを使用します)。

<RelyingParty id="keepersecurity.com"
        provider="https://keepersecurity.com/api/rest/sso/saml/264325172298110"
        defaultSigningCredentialRef="IdPCredential">
    <ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never" />
</RelyingParty>

引き続きIDP_HOME/conf/relying-party.xmlファイルで、手順2で追加したKeeperメタデータファイルを使用する設定を行います。既存の設定済みプロバイダの隣に以下のMetadataProvider要素を追加します (ID値が「FSMD」であるはずです)。IDP_HOMEは実際のインストールパスに置き換えてください。

<!-- Keeper Metadata -->
<MetadataProvider id="KeeperMD" xsi:type="FilesystemMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
    metadataFile="IDP_HOME/metadata/keeper-metadata.xml" maintainExpiredMetadata="true" />

手順 4. 属性リゾルバーの設定

Keeperでは、認証中に特定のユーザー属性のマッピングが送信される必要があります。以下の表に見られるように、デフォルトのKeeper SSO Connect Cloudユーザー属性は、Email (メールアドレス)、First (名)、Last (姓)となります。IDP_HOME/conf/attribute-resolver.xmlを変更することで、Shibbolethの属性リゾルバーを設定してこのデータを利用できるようにします。

IdPのユーザー属性
Keeperのユーザー属性

<Email Address>

Email

<First Name>

First

<Last Name>

Last

Shibboleth Identity Provider SAML属性を設定する際に、KeeperはNameIDFormatがemailAddressの形式で提供されることを想定しています。推奨されたNameIDFormatを使用するか、Keeperにユーザー名ログイン識別子としてユーザーのメールアドレスを与えるような環境に適した値を入力します。

手順 5. 属性フィルタの設定

最後に、principal属性 (NameIDとしてエンコード) をGoogleに解放するようにShibboleth属性フィルタリングエンジンを設定します。以下のコードを既存のポリシー要素とともに IDP_HOME/conf/attribute-filter.xmlに追加します。

<AttributeFilterPolicy>
    <PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="keepersecurity.com" />

    <AttributeRule attributeID="principal">
        <PermitValueRule xsi:type="basic:ANY" />
    </AttributeRule>
</AttributeFilterPolicy>

手順 6. ShibbolethからメタデータXMLファイルを取得

  1. http://shibboleth.example.com/idp/shibbolethまたは <install_folder>/shibboleth-idp/metadataのShibbolethファイルシステムにあるShibbolethメタデータを見つけます。

  2. Shibbolethメタデータを手動で変更し、すべてのユーザーエンドポイントのコメントが解除されていることを確かにします (例: SingleLogout)。

  3. XMLファイルを保存します。

手順 7. IdPメタデータをKeeperにアップロード

Shibbolethメタデータ ファイルの準備ができると、Keeper管理コンソールに戻り、SSO Connectクラウドプロビジョニングメソッドで[編集]を選択します。

[アイデンティティプロバイダ]まで下にスクロールし、[IDP タイプ]を [GENERIC] に設定し、[ファイルの参照]を選択して Shibbolethメタデータファイルを選択します。

Keeper 管理コンソール内で編集ビューを終了し、SSO Connect Cloudプロビジョニングメソッドで[表示]を選択します。 [アイデンティティプロバイダ]セクション内に、現在設定されている法人ID、シングルサインオンサービス、シングルログアウトサービス エンドポイントのメタデータ値が表示されます。

SSOアプリケーションのメタデータ

グラフィックアセット

ShibbolethインスタンスでKeeperのアイコンやロゴファイルが必要な場合は、グラフィックアセットページをご参照ください。

KeeperクラウドSSOコネクトのセットアップはこれで完了です。SSOを使用してKeeperにログインしてみてください。

SSOが機能していない場合は、Shibbolethの設定、メタデータファイル、ユーザー属性にエラーがないか確認してください。

確認が完了後に手順4を繰り返します。

サポートが必要な場合は、enterprise.support@keepersecurity.comまでメールでお問い合わせください。

既存のユーザー/初期管理者をSSO認証に移行

ルートノード (最上位) で作成されたユーザーは、SSOが設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスする際にマスターパスワードの入力を求められます。

管理者は、SSOが有効になっているノードに自分自身を移動できません。この操作を行うには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、最初に[法人SSOログイン]のプルダウンからSSO統合で設定した法人ドメインを入力し、Keeperボルトにログインする必要があります。また、マスターパスワード入力による確認を求められる場合があります。

まず[法人SSOログイン]を選択

SSOで認証されると、それ以降はメールアドレスだけでSSO認証を開始できます。

法人ドメインを入力する必要はありません。メールアドレスを入力して[次へ]をクリックしても目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。 ルーティングとドメイン予約の詳細については、こちらをご覧ください。

その他のSAML 2.0プロバイダ

KeeperクラウドSSOコネクトをSSO IDプロバイダと連携させて、スムーズで安全なSAML 2.0認証を実現

最初に管理コンソールの設定の手順を完了してください。

Keeperは、すべてのSAML 2.0 SSO IDプロバイダ (IdP) と互換性があります。ご利用のIDプロバイダがリストにない場合は、このガイドの手順に従って設定を完了してください。この設定において、Keeperはサービスプロバイダ (SP) です。

手順1. IDプロバイダを設定

KeeperクラウドSSOコネクトについて、以下のような情報をIDプロバイダのアプリケーションに提供する必要があります。

  • エンティティID

  • IdPが起点となるログインエンドポイント

  • ACS (Assertion Consumer Service) エンドポイント

  • シングルログアウト (SLO) サービスエンドポイント

  • SPメタデータファイルまたはKeeper SP証明書ファイル

この情報を取得するには、Keeper管理コンソール内でSSO Connect Cloudプロビジョニングメソッドを見つけて、表示 (View) を選択します。 そこから、Keeperメタデータファイル、サービスプロバイダ (SP) 証明書ファイル、およびダイレクトURLと設定情報をダウンロードできます (IDプロバイダアプリケーションがメタデータファイルのアップロードをサポートしていない場合)。

KeeperクラウドSSOコネクトのプロビジョニングメソッドを表示
KeeperクラウドSSOコネクトの設定情報

サービスプロバイダのメタデータをアップロードする方法、または必要なSAMLレスポンス設定フィールドに手動で入力する方法については、IDプロバイダのアプリケーション設定ガイドをご参照ください。

手順2. IdPメタデータを取得

IdPメタデータをKeeperにインポートするには、正しく書式設定されたメタデータファイルが必要です。 ご利用のSSO IDプロバイダのアプリケーションがメタデータファイルをエクスポートできる場合、これがKeeperクラウドSSOコネクトプロビジョニングメソッドにメタデータをインポートするための最も便利でお勧めの方法でしょう。

ご利用のIDプロバイダからメタデータファイルをエクスポート/ダウンロードできない場合は、正しく書式設定されたメタデータファイルを作成してください。 手順については、SSOアプリケーションの設定ガイドをご参照ください。

KeeperクラウドSSOコネクトに対応したIDプロバイダのシンプルなmetadata.xmlファイルの書式のサンプル/テンプレートを以下に示します。 このサンプル/テンプレートを使用して作成を開始する場合は、お好みの.xmlや.txt用のエディターで、ご利用のIdPの情報に従って、その他のフィールドをコピー、貼り付け、修正、追加してください。

この例に含まれているフィールドは、SSOアプリケーションをKeeperに接続するために最低限必要なものなので、どのフィールドも削除「しない」でください。

<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor entityID="MySSOApp" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
    <md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="true">
        <md:KeyDescriptor use="signing">
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:X509Data>
                    <ds:X509Certificate>MIIDpDCCAoygAwIBAgIGAW2r5jDoMA0GCSqGSIb3DQEBCwUAMIGSMQswCQYDVQQGEwJVUzETMBEG
                        A1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5jaXNjbzENMAsGA1UECgwET2t0YTEU
                        MBIGA1UECwwLU1NPUHJvdmlkZXIxEzARBgNVBAMMCmRldi0zODk2MDgxHDAaBgkqhkiG9w0BCQEW
                        DWluZm9Ab2t0YS5jb20wHhcNMTkxMDA4MTUwMzEyWhcNMjkxMDA4MTUwNDEyWjCBkjELMAkGA1UE
                        BhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDVNhbiqGcmFuY2lzY28xDTALBgNV
                        BAoMBE9rdGExFDASBgNVBAsMC1NTT1Byb3ZpZGVyMRMwEQYDVQQDDApkZXYtMzg5NjA4MRwwGgYJ
                        KoZIhvcNAQkBFg1pbmZvQG9rdGEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
                        hr4wSYmTB2MNFuXmbJkUy4wH3vs8b8MyDwPF0vCcjGLl57etUBA16oNnDUyHpsY+qrS7ekI5aVtv
                        a9BbUTeGv/G+AHyDdg2kNjZ8ThDjVQcqnJ/aQAI+TB1t8bTMfROj7sEbLRM6SRsB0XkV72Ijp3/s
                        laMDlY1TIruOK7+kHz3Zs+luIlbxYHcwooLrM8abN+utEYSY5fz/CXIVqYKAb5ZK9TuDWie8YNnt
                        7SxjDSL9/CPcj+5/kNWSeG7is8sxiJjXiU+vWhVdBhzkWo83M9n1/NRNTEeuMIAjuSHi5hsKag5t
                        TswbBrjIqV6H3eT0Sgtfi5qtP6zpMI6rxWna0QIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQBr4tMc
                        hJIFN2wn21oTiGiJfaxaSZq1/KLu2j4Utla9zLwXK5SR4049LMKOv9vibEtSo3dAZFAgd2+UgD3L
                        C4+oud/ljpsM66ZQtILUlKWmRJSTJ7lN61Fjghu9Hp+atVofhcGwQ/Tbr//rWkC35V3aoQRS6ed/
                        QKmy5Dnx8lc++cL+goLjFVr85PbDEt5bznfhnIqgoPpdGO1gpABs4p9PXgCHhvkZSJWo5LobYGMV
                        TMJ6/sHPkjZ+T4ex0njzwqqZphiD9jlVcMR39HPGZF+Y4TMbH1wsTxkAKOAvXt/Kp77jdj+slgGF
                        gRfaY7OsPTLYCyZpEOoVtAyd5i6x4z0c</ds:X509Certificate>
		             </ds:X509Data>
            </ds:KeyInfo>
	      </md:KeyDescriptor>
	      <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
        <md:SingleSignOnService Location="https://sso.mycompany.com/saml2/keepersecurity"
	            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
        <md:SingleSignOnService Location="https://sso.mycompany.com/saml2/keepersecurity"
	            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
    </md:IDPSSODescriptor>
</md:EntityDescriptor>
名前
説明

EntityDescriptor

これはエンティティIDで、発行者 (Issuer) と表記される場合もあり、IdPアプリケーションに固有の名前です。

X509Certificate

これはX509証明書で、IDプロバイダから送信されたSAMLレスポンスの署名を検証するためにKeeperが使用します。

NameIDFormat

Keeperにログインするときに使用する名前識別子の形式を定義します。 Keeperは以下の種類の識別子をサポートしています。

urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

または

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

SingleSignOnService "POST"

これは、Keeper からのリクエストに対するレスポンスとして使用されるIDプロバイダの「POST」バインディングです。

SingleSignOnService "Redirect"

これは、Keeper からのリクエストに対するレスポンスとして使用されるIDプロバイダの「Redirect」バインディングです。

手順3. ユーザー属性をマッピング

Keeperでは、認証中に送信される特定のユーザー属性をマッピングする必要があります。 KeeperクラウドSSOコネクトのデフォルトのユーザー属性は、以下の表に示したEmail、First、Lastです。 IDプロバイダのユーザー属性がKeeperの属性と一致するようにしてください。 手順については、ご利用のIDプロバイダの設定ガイドをご参照ください。

IdPのユーザー属性
Keeperのユーザー属性

<Email Address>

Email

<First Name>

First

<Last Name>

Last

手順4. IdPメタデータをKeeperにアップロード

IDプロバイダのメタデータファイルの作成、またはIDプロバイダのメタデータファイルのダウンロードが完了したら、Keeper管理コンソールに戻り、SSO Connect Cloudプロビジョニングメソッドを見つけて、編集 (Edit) を選択します。

SSOプロビジョニングメソッドを編集

IDプロバイダ (Identity Provider) セクションまで下にスクロールし、IDPタイプ (IDP Type) を汎用 (GENERIC) に設定して、ファイルを参照 (Browse Files) を選択し、作成したメタデータファイルを選択します。

メタデータファイルをアップロード

引き続き、Keeper管理コンソール内のSSO Connect Cloudプロビジョニングメソッドで、編集 (Edit) ビューを終了して、表示 (View) を選択します。 IDプロバイダ (Identity Provider) セクション内のエンティティID (Entity ID)、シングルサインオンサービス (Single Sign On Service)、シングルログアウトサービスエンドポイント (Single Logout Service Endpoint) のメタデータ値が入力されたことを確認できます。

SSOアプリケーションのメタデータ

グラフィックアセット

IDプロバイダがアプリケーションのアイコンやロゴファイルを必要とする場合は、グラフィックアセットページをご参照ください。

成功です。 これでKeeper Security SSO Cloudの設定が完了しました。 これで、SSOを使用してKeeperへのログインを試すことができます。

アプリケーションが機能していない場合は、IDプロバイダのアプリケーション設定を見直し、メタデータファイルとユーザー属性にエラーがないか確認してください。

確認が済んだら、手順4を繰り返します。

サポートが必要な場合は、enterprise.support@keepersecurity.comまでメールでご相談ください。

既存のユーザー/初期管理者をSSO認証に移動

ルートノード (最上位) で作成されたユーザーは、SSOが設定されたサブノードに移行する必要があります。ユーザーがルートノードに残っている場合、ボルトや管理コンソールにアクセスする際にマスターパスワードの入力を求められます。

管理者は、SSOが有効になっているノードに自分自身を移動できません。この操作を行うには別の管理者が必要となります。

ユーザーがSSO対応ノードに移動した後、最初に[法人SSOログイン]のプルダウンからSSO統合で設定した法人ドメインを入力し、Keeperボルトにログインする必要があります。また、マスターパスワード入力による確認を求められる場合があります。

まず[法人SSOログイン]を選択

SSOで認証されると、それ以降はメールアドレスだけでSSO認証を開始できます

法人ドメインを入力する必要はありません。メールアドレスを入力して[次へ]をクリックしても目的のSSOにルーティングされない場合は、Keeper SSO設定でジャストインタイムプロビジョニングが有効になっていることと、メールドメインがKeeperによって予約されていることを確かにします。 ルーティングとドメイン予約の詳細については、こちらをご覧ください。