デスクトップ用のアプリのサインオン・ポリシー・ルールを追加する

アプリ・サインオン・ポリシーは、アプリのアクセス要件を定義して適用します。組織のすべてのアプリには、デフォルトのサインオン・ポリシーがすでに用意されています。ルールの中でも特に、誰が、どの場所から、どのタイプのデバイスにアクセスできるか、どの認証方法を使用するかを規制するルールを作成することで、ポリシーをカスタマイズできます。

たとえば、アプリにアクセスする際にOktaユーザー全員にパスワードの提供をデフォルトで要求する一方で、指定したグループのOktaユーザーには同じアプリへのアクセスでもパスワードとOkta Verifyの両方を提供するよう求めることができます。その場合、デフォルト・ユーザーにパスワードの提供を要求するルールと、指定したグループのメンバー全員にOkta Verifyの提供を要求するルールを作成します。

ルールには番号が付けられます。Oktaは、アプリ・サインオン・ポリシーのページに表示されるのと同じ順序でルールを評価します。ルールの番号の下に表示される縦の点線の「ハンドル」をクリックしてドラッグすると、追加したルールの順序を並べ替えることができます。

アプリ・サインオン・ポリシーは、ユーザーがアプリにアクセスするたびに評価されます。その時点でユーザーに有効なOktaセッションがない場合、Oktaサインオン・ポリシーも評価されます(Oktaのサインオン・ポリシーを参照)。

たとえば、アクティブなOktaセッションを持たないユーザーがアプリにアクセスしようとしたとします。Oktaサインオン・ポリシーによってパスワード/IdPが求められ、アプリ・サインオン・ポリシーによって1要素認証の所有要素が求められる場合、ユーザーはパスワード(または外部IdPとのフェデレーション)および所有要素を提供する必要があります。

ポリシーを特定のユーザーに適用するかどうかを評価するとき、Oktaはポリシーの条件とそのルールの条件を組み合わせます。ポリシーに複数のルールが含まれ、ユーザーがアプリにアクセスしようとしたときに最初のルールの条件が満たされない場合、Oktaはこのルールをスキップし、次のルールに対してユーザーを評価します。

 

Note

Okta Verifyを使用してパスワードなしの認証を構成するには、Okta FastPassを構成する を参照してください。

開始する前に

この手順を開始する

  1. 管理コンソールで、[アプリケーション]>[アプリケーション]に移動します。
  2. サインオン・ポリシー・ルールを作成するアプリを選択します。
  3. アプリケーションのメイン・ページで、[サインオン]タブをクリックします。
  4. [サインオン・ポリシー]セクションまでスクロールしてから、[ルールを追加]をクリックします。
  5. [ルール名]を入力します。
  1. IF条件を構成します。これらの条件では、どのような場合にルールを適用するのかを指定します。
    IF説明
    IFユーザーのユーザー・タイプデフォルトでは、ルールはアプリに割り当てられたすべてのユーザー・タイプに適用されます。デフォルトを受け入れるか、範囲に含めるおよび除外するユーザー・タイプを指定します。
    ANDユーザーのグループ・メンバーシップデフォルトでは、ルールはアプリに割り当てられたすべてのグループに適用されます。デフォルトを受け入れるか、範囲に含めるおよび除外するユーザー・グループを指定します。
    ANDユーザー:デフォルトでは、ルールはアプリに割り当てられたすべてのユーザーに適用されます。デフォルトを受け入れるか、範囲に含めるユーザーと除外するユーザーを指定します。

    ANDユーザーのIP:デフォルトでは、ルールはすべてのIPに適用されます。デフォルトを受け入れるか、ネットワーク・ゾーンを選択します。Oktaで定義済みのゾーンや未定義のゾーンで並べ替えたり、特定のゾーンを構成したりすることが可能です。
    ANDデバイスの状態デフォルトでは、ルールはどの状態のデバイスにも適用されます。デフォルトを受け入れるか、[登録済み]を選択して、Okta Verifyに登録されているデバイスにのみこのルールを適用します。デバイスの登録を参照してください。
    ANDデバイス管理[登録済み]デバイスの状態を選択した場合、サード・パーティーのデバイス管理ソリューションによって管理されるデバイスにのみルールが適用されるかどうかを示します。
    ANDデバイス・プラットフォーム:デフォルトでは、ルールはすべてのプラットフォームに適用されます。デフォルトを受け入れるか、特定のプラットフォームを選択してください。
    ANDリスクは次のとおりです:デフォルトでは、このルールはあらゆるリスク・レベルの認証試行に適用されます。ルールを選択すると、指定したリスク・レベルのみにルールが制限されます。 リスク・スコアリングを参照してください。
    AND次のカスタム式をtrueとするオプションです。式言語(EL)を使用して追加の条件を指定します。挙動とサインオン・ポリシーについて「Okta式言語」
  2. を参照してください。
  1. THEN条件を構成します。これらの条件では、認証を適用する方法を指定します。
    THEN説明
    THENアクセスは次のとおりです:ユーザーのアクセスを拒否するか、認証が成功した後に許可します。アクセスを拒否する場合、最後の手順までスキップしてルールを保存してください。
    ANDユーザーが次で認証する必要があります:アプリへのアクセスに適用する認証要件を選択します。要素タイプの説明については、オーセンティケーターの構成を参照してください。
    1要素タイプ:
    1要素認証を有効化するには、次から選択します。
    • パスワードでは、ルールで再認証が必要になるたびにユーザーがパスワードを入力する必要があります。
    • 所有要素では、アプリにアクセスするために、ユーザーがOkta Verifyやメールなどの所有要素を提供する必要があります。
    • 任意の1要素タイプを使用すると、ユーザーは任意の単一要素を指定してアプリにアクセスできます。
    • パスワードなしの1要素認証オプションについては、パスワードなしの認証を構成するを参照してください。
    2要素タイプ:ユーザーに2つの異なる要素タイプの提供を要求する場合に選択します。次から選択します。
    • パスワード+別の要素
    • 任意の2つの要素タイプ
    • パスワードなしの2要素認証オプションについては、Okta FastPassを構成する を参照してください。
    AND所有要素の制限[ユーザーが次で認証する必要があります:][パスワード]のみが選択されている場合、これらのオプションは使用できません。これらの設定を使用して、所有要素の特性を指定します。
    • フィッシング耐性:ログイン・サーバー(オリジン)を暗号で検証する所有要素の提供をユーザーに要求します。現在、FIDO2(WebAuthn)のみがこの要件を満たしています。フィッシング耐性はデバイス・バウンドを意味するため、[フィッシング耐性]を選択すると、その制約が自動的に選択されます。
    • ハードウェアで保護:認証に使用されるキーがデバイスのセキュア・ハードウェア(TPM、安全なエンクレーブ)に保存されている必要があります。現在、Okta Verifyのみがこの制約を満たしています。ハードウェアで保護はデバイス・バウンドを意味するため、[ハードウェアで保護]を選択すると、その制約が自動的に選択されます。
    • デバイス・バウンド(電話とメールを除く):要素のキーをデバイスに安全に保管するよう求め、要素を再登録せずに別のデバイスに転送できないようにします。デバイス・バウンドでない所有要素は、メールとSMSだけです。ほかの制約のいずれかが選択されている場合、この制約は自動的に選択されます。
    ANDOkta FastPassを使用したアクセスを許可これらのオプションでは、Okta FastPassを使用して認証する際に、エンド・ユーザーが物理的に存在していることの証明を要求するかどうかを選択できます。
    • ユーザーがOkta Verifyでプロンプトを承認するか、生体認証(NIST AAL2の要件を満たす)を提供する場合、
    このオプションでは、ユーザーが物理的に存在することを証明する必要があります。
    • ユーザーがOkta Verifyでプロンプトを承認したり生体認証を提供したりしない場合
    このオプションが選択されていて、アプリ・サインオン・ポリシーで所有要素が必要であれば、Okta Verifyで証明書ベースの認証を実行できます。これにより、ユーザーが物理的に存在することを証明せずにリソースにアクセスできるようになります。このオプションはNIST AAL2の要件を満たしていません。さらに、このオプションを選択した場合、セキュリティー上の質問を追加の要素として使用することはできません。
    再認証の頻度この設定では、エンド・ユーザーが再認証する必要がある頻度を指定できます。
    • サインイン試行の都度: ユーザーはアプリにアクセスするたびに再認証する必要があります。
    • デバイスごとに1回:ユーザーがデバイスから認証されると、セッションのライフタイムに達するか、Oktaからサインアウトするまで、再認証のプロンプトは表示されません。
    • 再認証を求めるまでの時間:エンド・ユーザーが再認証する必要がある頻度を指定します。ユーザーがアプリへのアクセスを試行し、指定した時間間隔内に再認証されておらず、セッションの有効期限が切れていない場合にのみ再認証を求められます。
    :ユーザーがパスワードで認証した後、10秒間の猶予期間が適用されます。[サインイン試行の都度]が選択されている場合は、この猶予期間中に再度パスワードの入力を求められることはありません。
    パスワードの再認証の頻度これら2つのオプションは、[パスワード+別の要素]が選択されている場合にのみ表示されます。パスワードやそのほかの要素に対して、異なる再認証間隔を指定できます。たとえば、最後に認証されてから8時間以上経過している場合はパスワードを使用し、アプリにアクセスするたびに所有要素を使用して再認証するようにユーザーに要求できます。
    ほかのあらゆる要素での再認証の頻度
  2. [保存]をクリックします。

次の手順