アプリのサインオン・ポリシーの移行
Okta Identity Engineのアプリ・サインオン・ポリシーには、Okta Classicのポリシーと同様のパラメーターがありますが、いくつかの重要な違いがあります。 次の表で、Okta ClassicとOkta Identity Engineのアプリ・サインオン・ポリシー・ルールの構成タスクについて説明します。
タスク | Classic Engine | Identity Engine |
|---|---|---|
| ルールに名前を付ける | ルール名 | ルール名 |
| このルールを適用するユーザーを指定する |
|
ユーザーの選択とユーザー/グループの除外の両方が移行されますが、新しく作成するルールでは構成可能な条件として表示されません。 |
| ユーザーがアプリにアクセスするのに必要な場所を指定する | ユーザーが次の場所にいる場合：
| ユーザーのIP：
ゾーン外の除外は、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ユーザー・インタラクション：常に必須
- ほかのあらゆる要素での再認証の頻度：すべてのサインイン試行
