Classic Engineエクスペリエンスを記録する
組織がIdentity EngineでClassic Engineと同様に動作することを確認できるように、アップグレードする前にClassic Engineの動作をすべて正確に記録します。
ポリシーを文書化する
まず、Classic Engineポリシーを文書化します。ポリシーごとにテストユーザーを1人以上作成します。
-
Oktaサインオンポリシーの設定を記録します。
-
テストユーザーアカウントを使ってOkta組織にサインインし、Oktaサインオンポリシーがサインインフローを正しく評価することを検証します。
-
MFA登録ポリシーの設定を記録します。
-
テストユーザーアカウントを使ってMFA要素を登録し、ポリシーが選択内容を正しく評価することを検証します。
-
アプリサインオンポリシーの設定を記録します。
-
テストユーザーアカウントを使ってアプリにサインインし、アクセスがポリシーによって正しく制御されることを確認します。
-
セルフサービスパスワード復旧ポリシーの設定を記録します。
-
テストユーザーアカウントを使ってパスワードの復旧を試行し、フローがポリシーによって制御されることを確認します。
デバイスを準備する
すでにOktaデバイスの信頼をアクティブに使用しているときは、次の手順に従います。
-
Classic Engine orgで、モバイルデバイス向けOkta デバイスの信頼をオフにします。
-
Classic Engine orgで、デスクトップ向けのデバイスの信頼をセットアップします。
-
MDMベンダーを再統合する方法のRunbookを作成します。
-
アプリサインポリシーの作成、テストを行い、テストユーザーがデスクトップ向けのデバイスの信頼を使用してサインインできることを確認します。
現在、モバイルまたはデスクトップ向けのDevice Trustを使用していない場合は、Classic Engineで何も構成する必要はありません。
サインインウィジェットのカスタマイズを記録する
アップグレード後に再現できるように、サインインウィジェットのカスタマイズを記録します。これは、Classic Engineでセルフサービス登録（SSR）を有効化している場合に有用です。
カスタムドメインなしのOktaホスト型サインインウィジェット
これは、最も一般的なサインインエクスペリエンスモデルです。記録すべきカスタマイズは何もありません。
カスタムドメインありのOktaホスト型サインインウィジェット
カスタムドメインでOktaがホストするSign-In Widgetを使用する場合、サインインページはカスケードスタイルとJavaScriptでカスタマイズされる場合があります。影響を受ける可能性のある非推奨の機能については、JavaScriptを確認してください。「Sign-In Widgetをアップグレードする」を参照してください。
-
アップグレードのRunbookを作成します。すべてのスタイル変更を文書化します。
-
コアブランディングオプションを超える並べ替えや視覚的な変更
-
Sign-In WidgetのJavaScriptラップ/拡張機能（アプリコンテキスト、ビュー検出）。
-
デフォルトのフロー変更の上書き
-
-
任意。プレビュー環境がない場合は、テナントプロビジョニングを使用してIdentity Engineサンドボックスを作成します（［Developer Sign-Up（開発者サインアップ）］ページからこれを行うこともできます）。Oktaがホストするサインインウィジェットをサンドボックスにコピーします。
埋め込みサインインウィジェット
登録機能が有効なアプリケーションに Sign-In Widgetが埋め込まれている場合、これを使用してIdentity Engineにアップグレードすることはできません。Sign-In Widgetのバージョン5.11.0にアップグレードし、インタラクション・コードを付与タイプとして有効にします。
Sign-In Widgetがどこに埋め込まれているかわからない場合は、CORSフィルターを使用して検索できます。
-
Admin Consoleで、に移動します。
-
［Trusted Origins（信頼済みオリジン）］タブで、［CORS］フィルターを選択します。
-
［Origin URLs（オリジンURL）］列を確認し、サインインウィジェットがホストされている場所を特定します（複数のインスタンスが存在する可能性があります）。