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