IDプロバイダーでアプリのサインオン・ポリシー・ルールを追加する
アプリのサインオン・ポリシーは、エンド・ユーザーがアプリにサインインしようとするときに認証要件を適用します。組織の各アプリにはすでにサインオン・ポリシーが設定されており、そのポリシーにルールを追加してアクセスのレベルをカスタマイズすることができます。
たとえば、デフォルトのすべてのOktaユーザーにはパスワードの提供を要求し、指定されたグループのすべてのOktaユーザーにはオーセンティケーターとしてパスワードとメールの両方の提供を要求することができます。 その場合は、デフォルト・ユーザーにパスワードのみの提供を要求する1つのルールを作成してから、指定されたグループのすべてのメンバーにパスワードとメールのオーセンティケーターの提供を要求する2つ目のルールを作成します。
ルールが評価される順序は、ポリシー・ページのルールの順序と一致します。ルールを追加しない場合、アプリはデフォルトのキャッチオール・ルールに対して認証されます。
ユーザーがIDプロバイダーを使用してOktaにサインインする場合は、このページの手順に従ってアプリのサインオン・ポリシー・ルールを追加してください。
ユーザーがIDプロバイダーを使用してOktaにサインインしない場合は、アプリのサインオン・ポリシー・ルールの追加を参照してください。
アプリのサインオン・ポリシーを追加する
- 管理コンソールで、[アプリケーション]>[アプリケーション]に移動します。
- サインオン・ポリシー・ルールを作成するアプリを選択します。
- アプリケーションのメイン・ページで、[サインオン]タブをクリックします。
- [サインオン・ポリシー]セクションまでスクロールしてから、[ルールを追加]をクリックします。
- [ルール名]を入力します。
- IF条件を構成します。これらの条件では、どのような場合にルールを適用するのかを指定します。
IF 説明 IF ユーザーのユーザー・タイプ デフォルトでは、ルールはアプリに割り当てられたすべてのユーザー・タイプに適用されます。デフォルトを受け入れるか、範囲に含めるおよび除外するユーザー・タイプを指定します。 AND ユーザーのグループ・メンバーシップ デフォルトでは、ルールはアプリに割り当てられたすべてのグループに適用されます。デフォルトを受け入れるか、範囲に含めるおよび除外するユーザー・グループを指定します。 AND ユーザーのIP デフォルトでは、ルールはどのIPにも適用されます。デフォルトを受け入れるか、ネットワーク・ゾーンを選択します。Oktaで定義済みのゾーンや未定義のゾーンで並べ替えたり、特定のゾーンを構成したりすることが可能です。 AND デバイスの状態 デフォルトでは、ルールはどの状態のデバイスにも適用されます。デフォルトを受け入れるか、[登録済み]を選択して、Okta Verifyに登録されているデバイスにのみこのルールを適用します。デバイスの登録を参照してください。 AND デバイス・プラットフォーム デフォルトでは、ルールはどのプラットフォームにも適用されます。デフォルトを受け入れるか、特定のプラットフォームを選択してください。 AND リスク・レベル デフォルトでは、このルールはどのリスク・レベルの認証試行にも適用されます。ルールを選択すると、指定したリスク・レベルのみにルールが制限されます。 リスク・スコアリングを参照してください。 AND 次のカスタム式をtrueとする 任意：式言語（EL）を使用して追加の条件を指定します。挙動とサインオン・ポリシーについてと「Okta式言語」を参照してください。
- THEN条件を構成します。 これらの条件では、認証を適用する方法を指定します。
THEN 説明 THEN アクセスの可否 ユーザーのアクセスを拒否するか、認証が成功した後に許可します。アクセスを拒否する場合、最後の手順までスキップしてルールを保存してください。 AND ユーザーが認証に使用する要素 アプリへのアクセスに適用する認証要件を選択します。要素タイプの説明については、オーセンティケーターの構成を参照してください。
1要素タイプ：1要素認証を有効化するには、次から選択します。- パスワード/IdP：ユーザーがこのオプションを選択した場合、信頼できるIDプロバイダーを介して認証すれば、パスワードの要件を満たします。
- 所有要素：アプリにアクセスするために、ユーザーが、利用可能な所有要素のいずれかを提供する必要があります。
- 任意の1要素タイプ/IdP：アプリにアクセスするために、ユーザーが、利用可能な要素のいずれかを提供できるようにします。ユーザーがパスワード/IDP要素を選択した場合、信頼できるIDプロバイダーを介して認証すれば、パスワードの要件を満たします。
- パスワードなしの1要素認証オプションについては、パスワードなしの認証を構成するを参照してください。
- パスワード/IdP+別の要素：ユーザーがこのオプションを選択した場合、信頼できるIDプロバイダーを介して認証すれば、パスワードの要件を満たします。また、アプリにアクセスするには、利用可能な所有要素のいずれかを提供する必要があります。
- 任意の2要素タイプ：ユーザーは、利用可能な知識/生体認証要素のいずれか1つと、利用可能な所有要素のいずれか1つを提供できます。
- パスワードなしの2要素認証オプションについては、Okta FastPassを構成する を参照してください。
AND 所有要素の制限 [ユーザーが認証に使用する要素]でパスワードのみが選択されている場合、これらのオプションは使用できません。これらの設定を使用して、所有要素の特性を指定します。 - フィッシング耐性：ログイン・サーバー（オリジン）を暗号で検証する所有要素の提供をユーザーに要求します。現在、FIDO2（WebAuthn）のみがこの要件を満たしています。フィッシング耐性はデバイス・バウンドを意味するため、[フィッシング耐性]を選択すると、その制約が自動的に選択されます。
- ハードウェアで保護：認証に使用されるキーがデバイスのセキュア・ハードウェア（TPM、安全なエンクレーブ）に保存されている必要があります。現在、Okta Verifyのみがこの制約を満たしています。ハードウェアで保護はデバイス・バウンドを意味するため、[ハードウェアで保護]を選択すると、その制約が自動的に選択されます。
- デバイス・バウンド（電話とメールを除く）：要素のキーをデバイスに安全に保管するよう求め、要素を再登録せずに別のデバイスに転送できないようにします。デバイス・バウンドでない所有要素は、メールとSMSだけです。ほかの制約のいずれかが選択されている場合、この制約は自動的に選択されます。
ANDOkta FastPassを使用したアクセスを許可[ユーザーが認証に使用する要素]でパスワードのみが選択されている場合、これらのオプションは使用できません。これらのオプションでは、Okta FastPassを使用して認証する際に、エンド・ユーザーが物理的に存在していることの証明を要求するかどうかを選択できます。 - ユーザーがOkta Verifyでプロンプトを承認するか、生体認証を提供する（NIST AAL2要件を満たす）場合
このオプションでは、ユーザーが物理的に存在することを証明する必要があります。
- ユーザーがOkta Verifyでプロンプトを承認したり、生体認証を提供したりしない場合
このオプションが選択されていて、アプリのサインオン・ポリシーに所有要素が必要な場合、Okta Verifyで証明書ベースの認証を実行できます。これにより、ユーザーが物理的に存在することを証明せずにリソースにアクセスできるようになります。このオプションはNIST AAL2の要件を満たしていません。さらに、このオプションを選択した場合、セキュリティー上の質問を追加の要素として使用することはできません。
再認証の頻度 この設定では、エンド・ユーザーが再認証する必要がある頻度を指定できます。 
注：
フェデレーションまたはソーシャル認証プロバイダーを持つユーザーは、パスワードの再認証をバイパスします。
ほかのすべてのユーザーは、信頼できるIDプロバイダーを介して認証されている場合でも、再認証時にパスワードの入力を求められます。
- サインイン試行の都度：ユーザーはアプリにアクセスするたびに再認証する必要があります。
- デバイスごとに1回：ユーザーがデバイスから認証されると、セッションのライフタイムに達するか、Oktaからサインアウトするまで、再認証のプロンプトは表示されません。
- 再認証を求めるまでの時間：エンド・ユーザーが再認証する必要がある頻度を指定します。ユーザーがアプリへのアクセスを試行し、指定した時間間隔内に再認証されておらず、セッションの有効期限が切れていない場合にのみ再認証を求められます。
パスワードの再認証の頻度 これら2つのオプションは、[パスワード+別の要素]が選択されている場合にのみ表示されます。パスワードやそのほかの要素に対して、異なる再認証間隔を指定できます。たとえば、最後に認証されてから8時間以上経過している場合はパスワードを使用し、アプリにアクセスするたびに所有要素を使用して再認証するようにユーザーに要求できます。 ほかのあらゆる要素での再認証の頻度 - [保存]をクリックします。
アプリのサインオン・ポリシーを更新する
- 管理コンソールで、[アプリケーション] > に移動します。 [アプリケーション]。
- サインオン・ポリシー・ルールを管理するアプリを選択します。
- アプリケーションのメイン・ページで、[サインオン]タブをクリックします。
- [サインオン・ポリシー]セクションでは、次のことができます。
- [そのほかのオプション]メニューをクリックし[編集]を選択して、ルールの条件を変更します。
- [そのほかのオプション]メニューをクリックし、[非アクティブ化]を選択して、ルールを非アクティブ化します。
- [そのほかのオプション]メニューをクリックし、[非アクティブ化]を選択してから、[削除]を選択して、ルールを削除します。
- ルールをドラッグ・アンド・ドロップして、優先度を並べ替えます。
アプリのサインオン・ポリシー・ルールを定義して保存すると、そのポリシー用に構成されたアクティブなルールのプレビューが表示されます。含まれているすべてのユーザーまたはグループが削除された場合、ルールは自動的に非アクティブ化されることに注意してください。
アプリのサインオン・ポリシーのセキュリティー上の質問
セキュリティー上の質問によるオーセンティケーターでは、エンド・ユーザーに対して、提示される質問のリストから選択した質問に対する正しい回答を入力するように求めます。
セキュリティー上の質問によるオーセンティケーター：
- 認証（MFA/SSO）とユーザーのパスワード復旧シナリオをサポートしています。MFA/SSOに対して無効になっている場合、サインオン・ポリシーの評価に含まれることはありません。
- パスワードがプライマリ要素として使用される場合、特にユーザーのOktaサインオン・ポリシーのプライマリ要素がパスワード/IDPの場合、ステップアップ認証または追加の検証として使用できます。Oktaでは、どの認証フローでもセキュリティー上の質問を使用しないことを推奨しています。
このオーセンティケーターは、アカウント復旧にのみ使用するか、認証とアカウント復旧の両方に使用するように構成できます。復旧オプションを選択した場合、サインオン・ポリシーの評価中に認証が要求されることはありません。
たとえば、ユーザーに対してOkta FastPassを有効化する、つまり、 ユーザーが物理的に存在することを証明せずにリソースにアクセスできるようにする場合、セキュリティー上の質問を追加の要素として使用することはできません。詳しくは、 アプリのサインオン・ポリシー・ルールの追加. 管理者がエンド・ユーザーにセキュリティー上の質問を使用してもらいたい場合は、Oktaサインオン・ポリシーの[パスワード/ IdP]オプションを使用する必要があります。