テスト環境をセットアップする

本番環境をアップグレードする前に、Identity Engineのアップグレードを検証するテスト環境を作成します。Preview org、無料トライアルまたは自動化ツールを使用します。

本番環境のorgをClassic EngineからIdentity Engineにアップグレードする前に、アップグレードを安全に試行できるテスト環境をセットアップします。これにより、問題の特定、構成の検証を行い、ユーザーフローが正しく動作することを本番環境にリスクを与えることなく確認できます。

テスト環境が必要な理由

  • アップグレード後に、現在のポリシー、サインインフロー、MFA、アプリ統合が機能することを検証します。
  • カスタムコード、埋め込みSign-In Widget、またはAPIの使用を妨げる変更を特定します。
  • 修復手順を本番環境に適用する前にテストします。
  • エンドユーザーエクスペリエンスが期待を満たしていることを確認します。
  • 本番環境のアップグレードをスケジュールする前に、信頼を築きます。

テスト環境のアプローチ

アプローチ 最適な対象 制限事項
Preview org(推奨) アップグレードプロセスの完全なリハーサル 既存のPreview orgまたはOrgの購入が必要です。本番環境の構成をミラーする必要があります。
無料トライアルまたはIntegrator無料プランorg アプリおよび開発者テスト(Sign-In Widget、SDK、APIフロー) 本当の移行リハーサルではありません。アップグレードプロセス自体はテストしません。
Terraformまたは自動化ベースのコピー 繰り返し可能な、大規模なorg複製 Terraformの専門知識が必要です。Oktaは、このプロセスを完全にドキュメント化していません。
orgの手動作成 簡単な構成と小規模なorg 時間がかかります。本番環境との同期を保つことは困難です。
Preview org(推奨)

Preview orgは、本番環境のアップグレードのリハーサルに最も近いものです。同じセルフサービスアップグレードプロセスを使用して、最初にPreview orgをアップグレードし、結果を検証します。

  • Preview orgは、本番環境の構成とできるだけ一致させる必要があります。
  • プレビューですべてのSAMLアプリを複製する代わりに、ブックマークアプリを利用できます。
  • Preview orgをお持ちでない場合は、Oktaに連絡して購入してください。

セルフサービスアップグレードのテスト計画」を参照してください。

無料トライアルまたはIntegrator無料プランorg

これは、Identity Engine環境に対してアプリコード、Sign-In Widgetの動作、およびSDKフローをテストするためのセカンダリサンドボックスとして使用します。これは開発者のテストには有用ですが、アップグレードプロセスは複製されません。

Terraformまたは自動化ベースのアプローチ
  1. Okta Terraformプロバイダーを使用して、本番orgの構成をエクスポートします。
  2. 新しいClassic Engine orgにインポートします。
  3. アップグレード準備の変更を適用します。
  4. テストorgをアップグレードします。
  5. 検証します。
  6. 必要に応じて繰り返します。

テスト環境に取り込むもの

カテゴリ 複製するもの ノート(Notes)
ポリシー グローバルセッションポリシー、MFA登録ポリシー、アプリのサインオンポリシー ポリシーパスごとにテストユーザーを1人以上作成します。
Sign-In Widget カスタムブランディング、CSS、JavaScriptのカスタマイズ 埋め込みウィジェットを使用する場合に重大です。
カスタムドメイン カスタムURL、信頼済みオリジン、CORS設定 カスタムサインインページのテストに必要です。
アプリ 高リスクアプリ(SAML、OIDC、SCIM、埋め込み認証) 低リスクのSAMLアプリには、ブックマークアプリを使用します。
認証コード 埋め込みSign-In Widget、AuthJS、サーバー側の認証コード 信頼済みオリジンとSystem Logで、/api/v1/authn/api/v1/sessions、および/api/v1/factorsを検索します。
Device Trust Okta Verify、管理対象証明書、IWAルーティングルール アップグレードする前に、IWAルーティングルールを削除します。
サードパーティツール AWS CLI、Jamf Connect、Snowflakeまたはその他の統合 Classicの認証方法を使用するレガシーツールは、壊れる可能性があります。

セットアップとテストの手順

  1. 本番orgのインベントリ

    Admin ConsoleでIdentity Engineアップグレードハブを使用して、アクションアイテム、カスタマイズ、テストのニーズを特定します。

  2. テストユーザーを作成する

    ポリシーパスごとにテストユーザーを1人以上作成します。Classic Engineで次がどのように動作するかを記録します。

    • Oktaのサインオンポリシー
    • MFA登録ポリシー
    • アプリサインインポリシー
    • パスワード復旧フロー

    検証テスト」を参照してください。

  3. 高リスク構成をテスト環境にミラーする

    • グローバルセッションポリシー
    • MFAと登録ポリシー
    • アプリサインインポリシー
    • カスタムドメインとブランディング
    • 埋め込みSign-In Widgetアプリ
    • Device Trustの構成
    • SCIMアプリ
    • Okta APIまたはSDKを使用したアプリ
  4. カスタムまたは埋め込みの認証コードを見つける

    信頼できるオリジン/CORSとSystem Logで以下を検索します。

    • /api/v1/authn
    • /api/v1/sessions
    • /api/v1/factors

    カスタムサインインページのアップグレードガイダンス」を参照してください。

  5. テスト環境をアップグレードする

    Preview orgで、セルフサービスアップグレードを実行します。

    1. アップグレードハブ内のすべてのアクションアイテムを完了します。
    2. 修復ガイドに従います。
    3. アップグレードをスケジュールします。
    4. アップグレードされたorgをテストします。

    ほとんどの場合、アップグレードは数分で完了します。

    セルフサービスアップグレードプロセス」を参照してください。

  6. アップグレード後にテストを実行する

    • グローバルセッションポリシーの動作
    • Authenticator登録
    • アプリサインインポリシー
    • パスワード復旧
    • Device TrustとOkta FastPass
    • セルフサービス登録とプロファイル登録
    • SDKとサードパーティツール
    • エンドユーザーのサインインエクスペリエンス

    アップグレードをテストする」を参照してください。

  7. Identity Engineサンドボックスでアプリコードをテストする

    この手順は、埋め込みSign-In WidgetやSDKのユースケースでは特に重要です。埋め込みデプロイメントには、Identity EngineのInteraction Code flowが必要です。Sign-In Widget v7以降では、Identity Engineがデフォルトで有効になります。

    Okta Sign-In WidgetをIdentity Engineにアップグレードする」を参照してください。

繰り返し可能なテストの慣例

  • テスト環境で行った構成変更をすべてドキュメント化します。
  • Terraformまたはスクリプトを使用して、orgのプロビジョニングを可能な限り自動化します。
  • アップグレードの前後に実行するテストシナリオのチェックリストを保持します。
  • テスト実行全体で、テストユーザーとポリシーパスの一貫性を保ちます。
  • 結果を保存して、反復処理全体で比較できるようにします。

テストする高リスク領域

Identity Engineが認証動作を変更する領域に焦点を当てます。

領域(Area) 重要な理由
Sign-In Widget Identity EngineによりSign-In Widgetの構成が変更され、一部のClassicオプションが削除されます。
カスタムドメイン/カスタムログインページ アップグレードすると、カスタムサインインページが機能しなくなる場合があります。
埋め込みauth / AuthJS / /authn API Classic Engine /authn APIは、Identity Engineとは機能しません。
Device Trust Identity Engineは、Okta Verifyおよび管理対象証明書を使用します。IWAルーティングルールを削除する
サードパーティツール(AWS CLI、Jamf Connect) Classic Engine認証方法を使用する古いツールは、壊れる可能性があります。
エンドユーザーのサインインフロー Identity Engineは、識別子優先フローと異なる復旧動作を導入する場合があります。

アップグレード後

本番環境のアップグレード後、特定の機能を検証し、少なくとも1週間は無関係の設定変更を避けます。「アップグレード後のチェックリスト」を参照してください。