Planifier votre déploiement de mise à niveau

Planifiez la séquence de mise à niveau vers Identity Engine dans les orgs, effectuez le déploiement pour des segments utilisateurs et préparez le remplacement des fonctionnalités.

Avant de planifier la mise à niveau de votre org de production de Classic Engine vers Identity Engine, planifiez la séquence de la mise à niveau dans les orgs, le déploiement des changements au niveau des segments d'utilisateurs et le remplacement les fonctionnalités obsolètes dans Identity Engine. Okta recommande d'opter pour une approche progressive et itérative plutôt que de tout mettre à niveau en une seule fois.

Séquence de mise à niveau d'orgs

Si vous avez plusieurs orgs Okta, planifiez l'ordre de mise à niveau.

  1. Preview org. Répétez la mise à niveau, validez les modifications de configuration et exécutez votre matrice de test.
  2. Orgs hors production ou sandbox. Validez les flux et les intégrations spécifiques aux applications dans un environnement Identity Engine réel.
  3. Org de production. Appliquez la mise à niveau uniquement après les passes de validation des orgs Preview et sandbox.
  • Chaque org est mise à niveau de manière indépendante à l'aide de la mise à niveau en libre-service dans le hub de mise à niveau Identity Engine. Consultez le Processus de mise à niveau en libre-service.
  • Terminez tous les éléments d'action du hub de mise à niveau Identity Engine dans chaque org avant la planification. Consultez Effectuer des éléments d'action dans le hub de mise à niveau Identity Engine.
  • Attendez au moins une semaine après la mise à niveau des Preview orgs avant de mettre à niveau les orgs de production.
  • La mise à niveau ne prend que quelques minutes par org et n'a aucun temps d'arrêt.

Déploiement par segment d'utilisateurs

Après la mise à niveau de votre org, vous pouvez migrer les utilisateurs vers les flux Identity Engine de manière progressive plutôt que tous à la fois. Ceci est particulièrement important pour les orgs ayant des applications intégrées avec un Sign-In Widget ou basées sur un SDK.

Tableau 1. Politiques de déploiement par segment d'utilisateurs
Stratégie Fonctionnement Idéal pour
Routage basé sur le code Implémentez une logique conditionnelle pour rediriger les utilisateurs vers des flux Classic Engine ou Identity Engine en fonction d'un indicateur, d'un groupe ou d'un attribut. Applications intégrées avec Sign-In Widget ou SDK
Équilibrage de charge réseau Acheminez le trafic entre des instances d'application distinctes exécutant des chemins de code Classic Engine et Identity Engine. Applications à grande échelle utilisant plusieurs serveurs
Évolution incrémentielle Augmentez progressivement le pourcentage d'utilisateurs sur les flux Identity Engine. Réduction contrôlée des risques en production

Pour déployer la mise à niveau vers les segments d'utilisateurs, procédez comme suit :

  1. Commencez avec des utilisateurs internes ou des utilisateurs de test dans un petit groupe.
  2. Validez les flux de connexion, d'enregistrement, d'enrôlement MFA et de récupération de mot de passe.
  3. Surveillez les problèmes à l'aide du journal système et des rapports utilisateur.
  4. Augmentez progressivement le pourcentage d'utilisateurs.
  5. Supprimez le code de flux Classic Engine hérité après la validation complète.

Fonctionnalités à remplacer avant la mise à niveau

Device Trust

Classic Engine Device Trust n'est pas pris en charge dans Identity Engine. Planifiez la manière de le remplacer avant ou après la mise à niveau. Consultez Considérations relatives à la mise à niveau de Device Trust.

Okta Mobile

Okta Mobile est obsolète et indisponible après la mise à niveau vers Identity Engine. Transférez les utilisateurs vers Okta Verify avant la mise à niveau. Consultez Préparer les utilisateurs Okta Mobile pour la mise à niveau.

Authentification Windows intégrée (IWA)

Supprimez les règles de routage IWA avant la mise à niveau Identity Engine. Planifiez votre méthode d'authentification de remplacement avant de procéder à la mise à niveau.

  • Identifiez toutes les règles de routage IWA dans votre org.
  • Supprimez les règles de routage IWA avant de planifier la mise à niveau.
  • Planifiez votre remplacement : SSO de bureau avec Okta  FastPass ou une authentification basée sur un certificat.
  • Mettez les serveurs et les agents IWA hors service après la mise à niveau et la migration Okta FastPass.

Consultez Supprimez les règles de routage de l'authentification Windows intégrée.

Modifications des authentificateurs après la mise à niveau

Après la mise à niveau, Identity Engine utilise un modèle d'authentificateur qui remplace les facteurs MFA de Classic Engine. Certains changements de politique sont nécessaires immédiatement, tandis que d'autres peuvent attendre après la période de validation d'une semaine.

Tableau 2. Délai pour les changements d'authentificateurs après la mise à niveau
Délai Action Détails
Immédiatement après la mise à niveau Vérifier les paramètres de la politique de session globale Si l'option Tout facteur utilisé pour répondre aux exigences de la politique d'authentification est sélectionnée, mais que l'option Exiger un deuxième facteur est désactivée, les applications qui appellent des API Okta peuvent attendre un deuxième facteur qui n'est plus appliqué.
Immédiatement après la mise à niveau Vérifier que la MFA fonctionne Vérifiez que les authentificateurs par e-mail, par téléphone et autres fonctionnent comme prévu.
Après une semaine de validation Ajouter ou supprimer des authentificateurs Configurez de nouveaux authentificateurs Identity Engine selon les besoins.
Après une semaine de validation Modifier la politique d'enrôlement des authentificateurs Mettez à jour les règles enrôlement pour le nouveau modèle d'authentificateur.
Après une semaine de validation Activer les nouvelles fonctionnalités Identity Engine Activez-les uniquement après que la validation a confirmé la stabilité.
Tableau 3. Mappage des politiques Classic Engine avec Identity Engine
Concept Classic Engine Remplacement Identity Engine Action requise
Politique d'inscription à la MFA Politiques d'inscription à Authenticator Vérifiez et reconfigurez les paramètres d'authentificateurs.
Facteurs de la politique d'authentification Contraintes d'authentificateurs de la politique d'authentification Mappez les facteurs Classic Engine avec les authentificateurs Identity Engine.
Séquencement de facteurs Possession et vérification des authentificateurs Mettez à jour les règles de politique pour le nouveau modèle d'authentificateur.

Consultez Liste de contrôle après mise à niveau.

Liste de contrôle du calendrier de déploiement

Utilisez cette liste de contrôle pour confirmer que votre plan de déploiement est complet avant de planifier la mise à niveau.

Avant la mise à niveau

  • Identifiez toutes les orgs qui doivent être mises à niveau et définissez leur ordre.
  • Planifiez votre politique de déploiement par segment d'utilisateurs si vous utilisez des applications intégrées.
  • Identifiez l'utilisation de Device Trust et planifiez le chemin de remplacement.
  • Supprimez les règles de routage IWA de toutes les orgs devant être mises à niveau.
  • Informez les utilisateurs concernés de l'obsolescence d'Okta Mobile et déployez Okta Verify.
  • Accomplissez tous les éléments d'action du hub de mise à niveau Identity Engine dans chaque org.

Après la mise à niveau

  • Vérifiez immédiatement les paramètres de la politique de session globale.
  • Validez la MFA et l'enrôlement des authentificateurs pour les utilisateurs de test.
  • Abstenez-vous de modifier d'autres paramètres pendant au moins une semaine.
  • Après une semaine, mettez à jour les politiques d'enrôlement des authentificateurs.
  • Après une semaine, activez les nouvelles fonctionnalités Identity Engine selon vos besoins.
  • Supprimez le code de flux Classic Engine hérité des applications intégrées après la migration complète des utilisateurs.