アプリサインオンポリシーの移行

Identity Engineのアプリサインインポリシーには、Classic Engineのアプリサインインポリシーと同様のパラメーターがありますが、いくつかの重要な違いがあります。次の表で、Classic EngineIdentity Engineの構成タスクについて説明します。

タスク

Classic Engine

Identity Engine

ルールに名前を付ける ルール名 ルール名
このルールを適用するユーザーを指定する
  • このアプリに割り当てられているすべてのユーザー(デフォルト)
  • グループを選択
  • ユーザーを選択
  • グループを除外
  • ユーザーを除外
  • このアプリに割り当てられている任意のユーザータイプ(デフォルト)
  • グループを選択
  • ユーザータイプを選択
ユーザーがアプリにアクセスするのに必要な場所を指定する ユーザーが次の場所にいる場合:
  • すべての場所(任意のIP)
  • ゾーン内(特定)
  • ゾーン外
ユーザーのIP:
  • 任意のIP
  • Oktaで定義された任意のネットワークゾーン
  • 次のいずれかのゾーン(ゾーンを指定)
クライアントまたはデバイスを構成する クライアントアクセスポリシー(CAP)に従って、特定のプラットフォームにルールを適用します。

信頼できるデバイスと信頼できないデバイスにルールを適用します。

CAPは移行されますが、デバイスを信頼するルールと信頼しないルールは移行されません。登録済みデバイスおよび未登録のデバイスに対して新しいルールを作成する必要があります。
許容可能なリスクスコアを示す Classic Engineのアプリサインオンポリシーでは使用できません。 このルールは、特定のリスクスコアを持つアプリサインオンイベントにのみ適用します。
カスタム式 Classic Engineのアプリサインオンポリシーでは使用できません。 このルールは、カスタム式がtrueの場合にのみ適用します。

アクセス

すべての条件が満たされた場合のアクセスは次のとおりです。
  • 許可
  • 拒否済み
すべての条件が満たされた場合のアクセスは次のとおりです。
  • 拒否済み
  • 認証の成功後に許可
認証要件
  • パスワードの再認証を求める(期間)
  • 要素の入力を求める(頻度)
アプリにアクセスするためのアシュアランス要件を適用します。
  • ユーザーに再認証を求めるタイミングを指定する
  • パスワードの選択では、パスワードの再認証とパスワード以外の再認証の期間を指定します。

Identity Engineポリシーに対する最も重要な追加機能はアシュアランス要件です。アプリサインインポリシーのすべての条件を満たすユーザーは、適切なアシュアランス要件のみでアプリに対する認証を行います。Identity Engineのその他の機能強化には、リスクスコアリングとカスタム式が含まれ、ユーザーがアクセスを許可される前に、カスタマイズされたセキュリティレベルを確実に満たすようにします。

Classic EngineからIdentity Engineへの移行シナリオ

Classic Engineでアプリサインオンポリシーをセットアップすると、デフォルトですべてのクライアントオプションが選択されます。ユーザーが誰であるか、どのグループに属しているか、デバイスのクライアントとプラットフォーム、およびユーザーがネットワークに接続しているかどうかに基づいて、ルールを追加します。

Identity Engineにアップグレードすると、Classic Engineのアプリサインオンポリシーは、いくつかの条件付きで移行されます。

ポリシー名

Identity Engineでは、移行されたポリシーには、適用されたアプリの名前が付けられます(<appname> policy)。Classic Engineで複数のアプリに同一のポリシーがあった場合、それらのポリシーは1つの共有ポリシーに統合されます。この統合されたポリシーでは、「Merged」というプレフィックスが付いた同じ名前構造が使用されます([Merged] <appname1>、<appname2>、<appname3>ポリシー)。

デフォルトポリシー

デフォルトのアプリサインオンポリシーを使用していたClassic Engineのアプリは、デフォルトのキャッチオールルールが有効になっているOkta Identity Engineのアプリサインインポリシーに移行します。キャッチオールルールのみを使用するアプリでは、(グローバルセッションポリシーで必要とされる以上の)追加の認証なしで、アプリに割り当てられているすべてのユーザーへのアクセスが許可されます。

  • ユーザーのタイプ(IF[User's type is)](IF User's type is)任意(:[Any)]
  • ANDユーザーのグループメンバーシップ(AND User's group membership is):任意
  • ANDデバイスID(AND Device identity is):任意
  • ANDユーザーのIP(AND User's IP is):任意のゾーン
  • ANDリスク(AND Risk):任意
  • AND次のカスタム式をtrueとする(AND The following custom expression is true):N/A
  • THENアクセスの可否(THEN Access is):許可
  • ANDユーザーが使用する認証方法(AND User must authenticate with):任意の1要素タイプ
  • AND所有要素の制約(AND Possession factor constraints are):N/A
  • Okta Verifyユーザーインタラクション( user interaction):常に必須
  • 認証のためのプロンプト(Prompt for authentication):Oktaグローバルセッションが存在しない場合

Identity Engineのすべてのアプリのポリシーには、キャッチオールルールがあります。キャッチオールルールは編集できますが、アクセスをさらにカスタマイズするために、さらにルールを追加して優先順位を付けることができます。

再認証+要素の検証

再認証と要素の検証が有効になっているClassic Engineのアプリサインオンポリシーは、パスワードと追加要素が有効になっているOkta Identity Engineのアプリサインインポリシーに移行します。再認証の頻度は、Classic Engineポリシーの期間によって決まります。たとえば、2時間ごとにパスワードの再認証を要求し、毎回要素を求めるClassic Engineポリシーは、次のIdentity Engineポリシールールに移行されます。

  • ユーザーのタイプ(IF[User's type is)](IF User's type is)任意(:[Any)]
  • ANDユーザーのグループメンバーシップ(AND User's group membership is):任意
  • ANDデバイスID(AND Device identity is):任意
  • ANDユーザーのIP(AND User's IP is):任意のゾーン
  • ANDリスク(AND Risk):N/A
  • AND次のカスタム式をtrueとする(AND The following custom expression is true):N/A
  • THENアクセスの可否(THEN Access is):許可
  • ANDユーザーが使用する認証方法(AND User must authenticate with):パスワード+別の要素
  • AND所有要素の制約(AND Possession factor constraints are):N/A
  • Okta Verifyユーザーインタラクション( user interaction):常に必須
  • パスワード認証のためのプロンプト(Prompt for password authentication):2時間
  • 認証のその他すべての要素のためのプロンプト(Prompt for all other factors of authentication):ユーザーがリソースにサインインするたび

再認証なしの多要素

再認証なしで毎回多要素を必要とするClassic Engineのアプリサインオンポリシーは、Classic Engineの設定と同等の再認証間隔で、認証に所有要素を必要とするOkta Identity Engineのアプリポリシーに移行します。

  • ユーザーのタイプ(IF[User's type is)](IF User's type is)任意(:[Any)]
  • ANDユーザーのグループメンバーシップ(AND User's group membership is):任意
  • ANDデバイスID(AND Device identity is):任意
  • ANDユーザーのIP(AND User's IP is):任意のゾーン
  • ANDリスク(AND Risk):N/A
  • AND次のカスタム式をtrueとする(AND The following custom expression is true):N/A
  • THENアクセスの可否(THEN Access is):許可
  • ANDユーザーが使用する認証方法(AND User must authenticate with):所有要素
  • AND所有要素の制約(AND Possession factor constraints are):N/A
  • Okta Verifyユーザーインタラクション( user interaction):常に必須
  • 認証のその他すべての要素のためのプロンプト(Prompt for all other factors of authentication):ユーザーがリソースにサインインするたび

関連項目

アプリのサインオンポリシー