Okta FastPassを構成する

Okta FastPassでは、エンド・ユーザーにパスワードなしのサインイン・エクスペリエンスを提供します。Identity EngineでDevice Trustを設定することでOkta FastPassを構成し、管理対象デバイスにOkta Verifyを配信した後、パスワードなしの認証をサポートするアプリのサインオン・ポリシーとOktaサインオン・ポリシーを作成します。

開始する前に

以下の手順を完了させます：

• 多要素認証
• デバイスの登録
• Oktaのサインオン・ポリシー
• Identity EngineのDevice Trust

トピック

タスク1：管理対象デバイスからパスワードなしでアプリへのアクセスを可能にするアプリのサインオン・ポリシーの作成

タスク2：パスワードなしの認証をサポートするOktaサインオン・ポリシーの作成

タスク1：管理対象デバイスからパスワードなしでアプリへのアクセスを可能にするアプリのサインオン・ポリシーの作成

このタスクでは、アプリへのパスワードなしのアクセスを許可するアプリのサインオン・ポリシーを構成する方法の例を示します。3つのルールの例をガイドとして活用してください。

このポリシーでは、アプリにアクセスしようとするすべてのユーザーに対して、デバイスにOkta Verifyがインストールおよび登録されていることを要求します（デバイスの登録を参照）。未登録のデバイスのユーザーは、アプリへのアクセスを拒否されます。

1. 管理コンソールで、[アプリケーション] > に移動します。 [アプリケーション]。

2. サインオン・ポリシー・ルールを作成するアプリを選択します。

3. アプリケーションのメイン・ページで、[サインオン]タブをクリックします。

4. [サインオン・ポリシー]セクションまでスクロールしてから、[ルールを追加]をクリックします。

5. ポリシーを作成します。
   最も制限の厳しいルール（ルール1）が一番上にあり、最も制限が緩やかなルール（ルール3）が一番下にあることに注意してください。次のルールの例を、ルールを設定する際のガイドとして活用してください：
   • ルールの例1：安全なハードウェアを備えた管理対象の登録済みデバイスのユーザーを、アプリにシームレスにアクセスできるようにします。ユーザーは、最後に認証してから1時間以上経過している場合にのみ再認証を求められます。
   • ルールの例2：登録済みの管理対象外デバイスのユーザーに対して、パスワードとそのほかの要素（電話または電子メールを除く）が提供された後に、アプリへのアクセスを許可します。
   • ルールの例3：キャッチオール・ルール、リソースに対するすべてのアクセスを拒否します。

ルールの例1

安全なハードウェアを備えた管理対象の登録済みデバイスのユーザーが、アプリにシームレスにアクセスできるようにします。ユーザーは、最後に認証してから1時間以上経過している場合にのみ再認証を求められます。

このルールに一致するユーザーは、任意の2つの要素タイプを使用してアプリにアクセスできます。ユーザーがパスワードを入力せずにアプリにアクセスするには、Okta Verifyで生体認証を有効にする必要があります。Okta Verifyで生体認証を有効にしてある場合でも、パスワード（知識要素）の入力を求められます。

1. IF条件を構成して、どのような場合にルールを適用するのかを指定します。

IF	説明
IF ユーザーのユーザー・タイプ	わかりやすくするために、[すべてのユーザー・タイプ]を選択します。アプリを割り当てられたユーザーのみが、アプリにアクセスできます。
AND ユーザーのグループ・メンバーシップ	わかりやすくするために、[すべてのグループ]を選択します。アプリを割り当てられたグループのみが、アプリにアクセスできます。
AND ユーザーのIP	わかりやすくするために、[すべてのIP]を選択します。
ANDデバイスの状態	[登録済み]を選択します。
AND デバイスの管理	[管理対象]を選択します。
AND デバイス・プラットフォーム	デフォルトでは、ルールは [すべてのプラットフォーム]に適用されます。デフォルトを受け入れるか、特定のプラットフォームを選択してください。
AND リスク・レベル	わかりやすくするために、[すべて]を選択します。「リスク・スコアリング」を参照してください。
AND 次のカスタム式をtrueとする	任意：式言語（EL）を使用して追加の条件を指定します。デバイスのカスタム式についてを参照してください。

2. THEN 条件を構成して、認証の適用方法を指定します。

THEN	説明
THEN アクセスの可否	[認証の成功後に許可]を選択します。
AND ユーザーが認証に使用する要素	[任意の2つの要素タイプ]を選択します。
AND 所有要素の制限	[ユーザーが認証に使用する要素]でパスワードのみが選択されている場合、これらのオプションは使用できません。これらの設定を使用して、所有要素の特性を指定します。 耐フィッシング性：選択しないでください。 ハードウェア保護：ハードウェア格納型のキーストア（TPM、セキュア・エンクレーブ）にキーを保管することを求める場合に選択します。 デバイス・バウンド（電話とメールを除く）：要素キーをデバイスで安全に保管することを求める場合に選択します。
AND Okta FastPass を使用したアクセスを許可	Okta FastPassを使用して認証する際に、エンド・ユーザーが物理的に存在していることの証明を要求するには、以下を選択します： ユーザーがOkta Verifyでプロンプトを承認するか、生体認証を提供する（NIST AAL2要件を満たす）場合 この設定の詳細については、Oktaサインオン・ポリシー・ルールを追加するを参照してください。
再認証の頻度	再認証を求めるまでの時間：1時間。

3. [保存]をクリックします。

ルールの例2

登録済みの管理対象外デバイスのユーザーに対して、パスワードとそのほかの要素（電話または電子メールを除く）が提供された後に、アプリへのアクセスを許可します。

このルールに一致するユーザーは、パスワードの提供に加えて、登録されている任意のオーセンティケーター（電話とメールを除く）を選択できます。このルールでオプション[Okta Verifyユーザー・インタラクション]を選択する場合、Okta Verifyを登録済みのオーセンティケーターとして選択したユーザーは、ユーザー検証（生体認証）を提供するように求められます。

1. IF条件を構成して、どのような場合にルールを適用するのかを指定します。

IF	説明
IF ユーザーのユーザー・タイプ	わかりやすくするために、[すべて]を選択します。アプリを割り当てられたユーザーのみが、アプリにアクセスできます。
AND ユーザーのグループ・メンバーシップ	わかりやすくするために、[すべて]を選択します。アプリを割り当てられたグループのみが、アプリにアクセスできます。
AND ユーザーのIP	わかりやすくするために、[すべてのIP]を選択します。
ANDデバイスの状態	[登録済み]を選択します。
AND デバイスの管理	[非管理対象]を選択します。
AND デバイス・プラットフォーム	デフォルトでは、ルールはどのプラットフォームにも適用されます。デフォルトを受け入れるか、特定のプラットフォームを選択してください。
AND リスク・レベル	わかりやすくするために、[すべて]を選択します。「リスク・スコアリング」を参照してください。
AND 次のカスタム式をtrueとする	任意：式言語（EL）を使用して追加の条件を指定します。デバイスのカスタム式についてを参照してください。

2. THEN 条件を構成して、認証の適用方法を指定します。

THEN	説明
THEN アクセスの可否	[認証の成功後に許可]を選択します。>
AND ユーザーが認証に使用する要素	[パスワード+別の要素]を選択します。
AND 所有要素の制限	これらの設定を使用して、所有要素の特性を指定します。 耐フィッシング性：選択しないでください ハードウェア保護：選択しないでください デバイス・バウンド（電話とメールを除く）：要素キーをデバイスで安全に保管することを求める場合に選択します。
AND Okta Verifyユーザー・インタラクション	[常に必須]を選択します。
再認証の頻度	[パスワード+ 別の要素]を選択すると、2つの再認証設定が表示されます。これらで、パスワードによる再認証の間隔と、そのほかの要素による再認証の間隔を指定できます。この例では、ユーザーが最後にパスワードを入力してから4時間以上経過している場合はパスワードで再認証を行い、最後に所有要素で認証してから15分以上経過している場合は所有要素で再認証するように要求しています： パスワードの再認証の頻度：この例では、[再認証を求めるまでの時間]を4時間に設定します。 ほかのあらゆる要素での再認証の頻度： この例では、[再認証を求めるまでの時間]を15分に設定します。

3. [保存]をクリックします。

ルールの例3

キャッチオール・ルール、リソースへのすべてのアクセスを拒否します。

1. IF条件を構成して、どのような場合にルールを適用するのかを指定します。

IF	説明
IF ユーザーのユーザー・タイプ	[すべて]を選択します。
AND ユーザーのグループ・メンバーシップ	[すべて]を選択します。
AND ユーザーのIP	[すべてのIP]を選択します。
ANDデバイスの状態	[すべて]を選択します。
[すべて]を選択します。	[すべてのプラットフォーム]を選択します。
AND リスク・レベル	[すべて]を選択します。
AND 次のカスタム式をtrueとする	空白のままにします。

2. THEN 条件を構成して、認証の適用方法を指定します。

THEN	説明
THEN アクセスの可否	[拒否]を選択します。

3. [保存]をクリックします。
   

   ルールを作成すると、ポリシー・ルールの概要は次のようになります（優先順位に注意してください）：

   
   
   

ポリシーの例1：デバイスによるアクセスを拒否する

このポリシーでは、デバイスがユーザー・グループBに含まれていて、次に合致する場合にデバイスからのアクセスを拒否します：

• デバイスのサイレント・プローブが正常に機能しない（これは、Okta Verifyサービスがバックグラウンドで実行されていない場合、ネイティブのメール・アプリなどのWindowsユニバーサル・アプリにサインインしようとしている場合、または管理対象外のiOS デバイスを使用している場合に発生する可能性があります）

または

• Okta Verifyがインストールされていない（デバイスが登録されていない）
  

アクセスが拒否されるのは、ルール4のみがtrueであるためです。

ルール	ユーザー・グループ	IF	THEN
1	A	登録済みのデバイス、管理対象デバイスが必要	1つのFAで許可
2	A	すべてのデバイスの状態	2つのFAで許可
3	B	登録済みのデバイスが必要	1つのFAで許可
4	キャッチ・オール	すべて	拒否

この状況では、次の場合にのみアクセス権がデバイスに付与されます：

• 管理者がユーザー・グループBを許可する新しいルールをポリシーに追加し、IF 条件で[すべてのデバイスの状態]、THEN 条件で[2つのFAで許可]を選択する。

または

• サインインする際に、ユーザー名を入力せず、Okta Verifyの[Okta Verifyを使用してサインインする]ボタンを使用する。

ポリシーの例2：デバイスによるアクセスを許可する

このポリシーでは、例1が変更されています。ユーザー・グループBにルールが1つ追加されて、どの状態のデバイスにもアクセス権が付与されるようになりました。ルール4はこのデバイスに対してtrueであるため、アクセスが許可されます。

ルール	ユーザー・グループ	IF	THEN
1	A	登録済みのデバイス、管理対象デバイスが必要	1つのFAで許可
2	A	すべてのデバイスの状態	2つのFAで許可
3	B	登録済みのデバイスが必要	1つのFAで許可
4	B	すべてのデバイスの状態	2つのFAで許可
5	キャッチ・オール	すべて	拒否

タスク2：パスワードなしの認証をサポートするOktaサインオン・ポリシーの作成

1. Oktaサインオン・ポリシーを作成する
2. Oktaサインオン・ポリシー・ルールを追加するに従って、Oktaサインオン・ポリシーのルールを作成します。
3. 手順6で、以下を実行します。
   1. [プライマリ要素]の設定に移動し、デフォルトを[アプリのサインオン・ルールで許可されているパスワード/IDP/任意の要素]に変更します。
   

   重要：デフォルト設定を変更すると、保護されているすべてのアプリに影響します。[アプリのサインオン・ルールで許可されているパスワード/IDP/任意の要素]オプションを有効にすると、Oktaサインオン・ポリシーからグローバル・パスワードの要件が削除され、認証基準の定義と適用の責任が各アプリのサインオン・ポリシーに移ります。このオプションを有効化する前に、すべてのアプリに対して 強力な アプリ・サインオン・ポリシーを作成してください。これをすべてのアプリで行わずにデフォルトのアプリ・サインオン・ポリシーを使い続けると、ユーザーが単一の登録済み要素でアプリにアクセスできる可能性があります。

   2. [予備の要素]の設定に移動し、選択されていないことを確認します。

関連項目

• パスワードなしの認証を構成する
• モバイル用のアプリのサインオン・ポリシー・ルールを追加する
• アプリのサインオン・ポリシー・ルールの追加