アップグレードのロールアウトを計画する

org全体でのIdentity Engineのアップグレード順、ユーザーセグメントへのロールアウト、機能の置き換えを準備する方法を計画します。

Classic EngineからIdentity Engineへの本番orgのアップグレードをスケジュールする前に、org全体でのアップグレード順、ユーザーセグメントへの変更のロールアウト、Identity Engineで廃止された機能を置き換える方法を計画します。すべてを一度にアップグレードするよりも、段階的に、反復的なアプローチを取ることをお勧めします。

Orgのアップグレードシーケンス

複数のOkta orgがある場合は、アップグレードの順番を計画します。

  1. Preview org。アップグレードを予行演習し、構成の変更を検証して、テストマトリックスを実行します。
  2. 非本番またはサンドボックスorg。実際のIdentity Engine環境でアプリ固有のフローと統合を検証します。
  3. 運用org。Preview orgおよびサンドボックスorgの検証が合格した後にのみ適用します。
  • 各orgは、Identity Engineアップグレードハブのセルフサービスアップグレードを使用して、個別にアップグレードされます。「セルフサービスアップグレードプロセス」を参照してください。
  • スケジュールする前に、各orgですべてのIdentity Engineアップグレードハブのアクションアイテムを完了します。「Identity Engineアップグレードハブのアクションアイテムを完了する」を参照してください。
  • Preview orgをアップグレードした後、少なくとも1週間待ってから、本番orgをアップグレードしてください。
  • アップグレードはorgあたり数分で完了し、ダウンタイムはありません。

ユーザーセグメントのロールアウト

orgのアップグレード後、ユーザーを一度にではなく、段階的にIdentity Engineフローに移行できます。これは、埋め込みSign-In WidgetやSDKベースのアプリを利用しているorgでは、特に重要です。

表 1. ユーザーセグメントのロールアウト戦略
戦略 仕組み 最適な対象
コードベースのルーティング 条件付きロジックを実装し、フラグ、グループ、または属性に基づいて、ユーザーをClassic EngineまたはIdentity Engineフローに誘導します。 埋め込みSign-In WidgetまたはSDKアプリ
ネットワーク負荷分散 Classic EngineおよびIdentity Engineのコードパスを実行する個々のアプリインスタンス間で、トラフィックをルーティングします。 複数のサーバーを使用する大規模なアプリ
増分スケーリング Identity Engineフローでユーザーの割合を段階的に増やします。 本番環境での制御されたリスク軽減

アップグレードをユーザーセグメントにロールアウトするには、次の手順を実行します。

  1. 小規模なグループの内部ユーザーまたはテストユーザーから始めます。
  2. サインイン、登録、MFA登録、パスワード復旧フローを検証します。
  3. System Logとユーザーレポートを使用して問題を監視します。
  4. ユーザーの割合を段階的に増やします。
  5. 完全な検証が完了したら、レガシーのClassic Engineフローコードを削除します。

アップグレード前に置き換える機能

Device Trust

Classic Engine Device Trustは、Identity Engineではサポートされていません。アップグレード前後に置き換える方法を計画します。「Device Trustのアップグレードに関する考慮事項」を参照してください。

Okta Mobile

Okta Mobileは廃止され、Identity Engineのアップグレード後は利用できなくなります。アップグレードする前に、ユーザーをOkta Verifyに移行します。「Okta Mobileユーザーのアップグレードを準備する」を参照してください。

統合Windows認証（IWA）

Identity Engineのアップグレード前にIWAルーティングルールを削除します。アップグレードする前に、置き換え用の認証方法を計画します。

  • org内のすべてのIWAルーティングルールを特定します。
  • アップグレードをスケジュールする前に、IWAルーティングルールを削除します。
  • 置き換えを計画します（Okta FastPassまたは証明書ベースの認証を使用するデスクトップSSO）。
  • アップグレードおよびOkta FastPassの移行後に、IWAエージェントとサーバーの使用を停止します。

「統合Windows認証ルーティングルールを削除する」を参照してください。

アップグレード後のAuthenticatorの変更

アップグレード後、Identity EngineはClassic EngineのMFA要素を置き換えるAuthenticatorモデルを使用します。一部のポリシーはすぐに変更する必要がありますが、その他のポリシーは1週間の検証期間の経過を待ってから対応できます。

表 2. アップグレード後のAuthenticator変更のタイミング
タイミング アクション 詳細
アップグレード直後 グローバルセッションポリシーの設定を検証する 認証ポリシーの要件を満たすために使用される任意の要素（Any factor used to meet the Authentication Policy requirements）が選択され、予備の要素を必須にする（Require secondary factor）がオフの場合、Okta APIを呼び出すアプリは、強制適用されなくなった予備の要素を想定する可能性があります。
アップグレード直後 MFAが機能することを検証する メール、電話、その他のAuthenticatorが想定どおりに機能することを確認します。
1週間の検証期間後 Authenticatorを追加または削除する 必要に応じて、新しいIdentity Engine Authenticatorを構成します。
1週間の検証期間後 Authenticator登録ポリシーを変更する 新しいAuthenticatorモデルの登録ルールを更新します。
1週間の検証期間後 新しいIdentity Engine機能を有効にする 検証で安定性が確認された後にのみ有効にします。
表 3. Classic EngineからIdentity Engineへのポリシーマッピング
Classic Engineのコンセプト Identity Engineの置き換え アクションが必要です
MFA登録ポリシー Authenticator登録ポリシー Authenticatorの設定を確認して再構成します。
サインオンポリシーの要素 認証ポリシーに関するAuthenticatorの制約 Classic Engine要素をOkta Identity Engine Authenticatorにマッピングします。
要素シーケンス Authenticatorの所有と検証 新しいAuthenticatorモデルのポリシールールを更新します。

「アップグレード後のチェックリスト」を参照してください。

ロールアウトタイムラインのチェックリスト

アップグレードをスケジュールする前に、このチェックリストを使用してロールアウト計画が完全であることを確認してください。

アップグレード前

  • アップグレードが必要なすべてのorgを特定し、その順番を定義します。
  • 埋め込みアプリを使用している場合は、ユーザーセグメントのロールアウト戦略を計画します。
  • Device Trustの使用を特定し、置き換えパスを計画します。
  • アップグレードするすべてのorgから、IWAルーティングルールを削除します。
  • 影響を受けるユーザーにOkta Mobileの廃止を伝え、Okta Verifyをデプロイします。
  • 各orgで、すべてのIdentity Engineアップグレードハブのアクションアイテムを完了します。

アップグレード後

  • グローバルセッションポリシーの設定を直ちに確認します。
  • テストユーザー向けのMFAおよびAuthenticator登録を検証します。
  • 少なくとも1週間は、他の設定を変更しないでください。
  • 1週間後に、Authenticator登録ポリシーを更新します。
  • 1週間後に、Identity Engineの新しい機能を必要に応じて有効にします。
  • ユーザーを完全に移行した後、埋め込みアプリからレガシーのClassic Engineフローコードを削除します。