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

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

タスク

Classic Engine

Identity Engine

ルールに名前を付けるルール名ルール名
このルールを適用するユーザーを指定する
  • このアプリに割り当てられているすべてのユーザー(デフォルト)
  • グループを選択
  • ユーザーを選択
  • グループを除外
  • ユーザーを除外
  • このアプリに割り当てられている任意のユーザー・タイプ(デフォルト)
  • グループを選択
  • ユーザー・タイプを選択

ユーザーの選択とユーザー/グループの除外の両方が移行されますが、新しく作成するルールでは構成可能な条件として表示されません。

ユーザーがアプリにアクセスするのに必要な場所を指定する ユーザーが次の場所にいる場合:
  • すべての場所(任意のIP)
  • ゾーン内(特定)
  • ゾーン外
ユーザーのIP:
  • 任意のIP
  • Oktaで定義された任意のネットワーク・ゾーン
  • 次のいずれかのゾーン(ゾーンを指定)

ゾーン外の除外は、Classic Engineから移行されますが、新しく作成するルールでは構成可能な条件として表示されません。

クライアントまたはデバイスを構成する クライアント・アクセス・ポリシー(CAP)に従って、特定のプラットフォームにルールを適用します。

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

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

アクセス

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

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

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

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

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

デフォルト・ポリシー

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

  • IFユーザーのタイプ:任意
  • ANDユーザーのグループ・メンバーシップ:任意
  • ANDデバイスID:任意
  • ANDユーザーのIP:任意のゾーン
  • ANDリスク:任意
  • AND次のカスタム式をtrueとする:N/A
  • THENアクセスの可否:許可
  • ANDユーザーが使用する認証方法:任意の1要素タイプ
  • AND所有要素の制約:N/A
  • Okta Verifyユーザー・インタラクション:常に必須
  • パスワードの再認証の頻度:デバイスごとに1回

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

再認証+要素の検証

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

  • IFユーザーのタイプ:任意
  • ANDユーザーのグループ・メンバーシップ:任意
  • ANDデバイスID:任意
  • ANDユーザーのIP:任意のゾーン
  • ANDリスク:N/A
  • AND次のカスタム式をtrueとする:N/A
  • THENアクセスの可否:許可
  • ANDユーザーが使用する認証方法:パスワード+別の要素
  • AND所有要素の制約:N/A
  • Okta Verifyユーザー・インタラクション:常に必須
  • パスワードの再認証の頻度:2時間
  • ほかのあらゆる要素での再認証の頻度:すべてのサインイン試行

再認証なしの多要素

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

  • IFユーザーのタイプ:任意
  • ANDユーザーのグループ・メンバーシップ:任意
  • ANDデバイスID:任意
  • ANDユーザーのIP:任意のゾーン
  • ANDリスク:N/A
  • AND次のカスタム式をtrueとする:N/A
  • THENアクセスの可否:許可
  • ANDユーザーが使用する認証方法:所有要素
  • AND所有要素の制約:N/A
  • Okta Verifyユーザー・インタラクション:常に必須
  • ほかのあらゆる要素での再認証の頻度:すべてのサインイン試行

関連項目

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

アプリのサインオン・ポリシー・ルールの追加