Configurer votre environnement de test

Créez un environnement de test pour valider votre mise à niveau Identity Engine avant de procéder à la mise à niveau de la production. Utilisez une Preview Org, une version d'essai gratuite ou des outils d'automatisation.

Avant de mettre à niveau votre organisation de production de Classic Engine vers Identity Engine, configurez un environnement de test où vous pouvez répéter la mise à niveau en toute sécurité. Cela vous permet d'identifier les problèmes, de valider les configurations et de confirmer que les flux utilisateur fonctionnent correctement sans risque pour la production.

Pourquoi vous avez besoin d'un environnement de test

  • Vérifiez que vos politiques, flux de connexion, MFA et intégrations d'application actuels fonctionnent après la mise à niveau.
  • Identifiez les modifications majeures apportées au code personnalisé, au Sign-In Widget intégré ou à l'utilisation des API.
  • Testez les étapes de remédiation avant de les appliquer à la production.
  • Confirmez que l'expérience de l'utilisateur final répond aux attentes.
  • Renforcez la confiance avant de planifier la mise à niveau de la production.

Tester les approches de l'environnement

Approche Idéal pour Limitations
Prévisualiser l'organisation (recommandé) Répétition complète du processus de mise à niveau Nécessite une Preview Org existante ou l'achat d'une organisation. Elle doit refléter la configuration de production.
Essai gratuit ou organisation avec plan d'intégration gratuit Tests des applications et des développeurs (Sign-In Widget, SDK, flux d'API ) Il ne s'agit pas d'une véritable répétition de la migration. Cela ne teste pas le processus de mise à niveau lui-même.
Copie basée sur la transformation (Terraform) ou l'automatisation Réplication d'organisation à grande échelle répétable Nécessite des compétences Terraform. Okta ne documente pas entièrement ce processus.
Création manuelle d'organisation Configurations simples et petites organisations Prend du temps. Difficile à maintenir en synchronisation avec la production.
Prévisualiser l'organisation (recommandé)

Une Preview Org est la correspondance la plus proche d'une répétition de mise à niveau de la production. Mettez d'abord à niveau la Preview Org, en utilisant le même processus de mise à niveau en libre-service, puis validez les résultats.

  • La Preview Org doit correspondre le plus précisément possible à votre configuration de production.
  • Vous pouvez utiliser des applications de signet au lieu de répliquer vos applications SAML dans l'aperçu.
  • Si vous n'avez pas de Preview Org, contactez Okta pour en racheter une.

Consultez Plan de test pour la mise à niveau en libre-service.

Essai gratuit ou organisation avec plan d'intégration gratuit

Utilisez-le comme bac à sable secondaire pour tester le code de l'application, le comportement du Sign-In Widget et les flux SDK dans un environnement Identity Engine. Cette option est utile pour les développeurs, mais ne reproduit pas le processus de mise à niveau.

Approche basée sur la transformation (Terraform) ou l'automatisation
  1. Exportez votre configuration d'organisation de production à l'aide du fournisseur Okta Terraform.
  2. Importez-le dans une nouvelle organisation Classic Engine.
  3. Appliquez les modifications relatives à la préparation de la mise à niveau.
  4. Mettez à niveau l'organisation test.
  5. Validez.
  6. Répétez l'opération autant de fois que nécessaire.

Éléments à intégrer dans votre environnement de test

Catégorie Éléments à répliquer Remarques
Politiques Politiques de session globale, politiques enrôlement MFA, politiques d'authentification à l'application Créez au moins un utilisateur test pour chaque politique.
Sign-In Widget Image de marque personnalisée, personnalisation CSS et JavaScript Critique en cas d'utilisation d'un widget intégré
Domaines personnalisés URL personnalisées, origines approuvées, paramètres CORS Nécessaire pour le test des pages de connexion personnalisées
Applications Applications à haut risque (SAML, OIDC, SCIM, authentification intégrée) Utilisez les applications de signet pour les applications SAML à faible risque.
Code d'authentification Sign-In Widget intégré, AuthJS, code d'authentification côté serveur Recherchez les origines approuvées et le journal système pour /api/v1/authn, /api/v1/sessions et /api/v1/factors.
Device Trust Okta Verify, certificats gérés, règles de routage IWA Supprimez les règles de routage IWA avant la mise à niveau.
Outils tiers AWS CLI, Jamf Connect, Snowflake ou autres intégrations Les outils hérités qui utilisent des méthodes d'authentification classiques peuvent cesser de fonctionner.

Étapes de la configuration et des tests

  1. Faire l'inventaire de votre organisation de production

    Utilisez le centre de mise à niveau d'Identity Engine dans l'Admin Console pour identifier les éléments d'action, les personnalisations et les besoins de test.

  2. Créer des utilisateurs de test

    Créez au moins un utilisateur test pour chaque politique. Enregistrez le comportement suivant dans Classic Engine :

    • Politiques d'authentification d'Okta
    • Politiques d'inscription MFA
    • Politiques de connexion aux applications
    • Flux de récupération de mot de passe

    Consulter Tests de validation de mise à niveau.

  3. Reflète la configuration à haut risque dans votre environnement de test

    • Politiques de session globale
    • MFA et politiques d'inscription
    • Politiques de connexion aux applications
    • Domaines personnalisés et image de marque
    • Applications avec Sign-In Widget intégré
    • Configuration Device Trust
    • Applications SCIM
    • Applications utilisant des API ou des SDK Okta

  4. Trouver le code d'authentification personnalisé ou intégré

    Rechercher des origines approuvées/CORS et du journal système pour :

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

    Consultez Aide à la mise à niveau de la page de connexion personnalisée.

  5. Mettre à niveau l'environnement de test

    Dans votre Preview Org, exécutez la mise à niveau en libre-service :

    1. Terminez tous les éléments d'action dans le centre de mise à niveau.
    2. Suivez les guides de remédiation.
    3. Planifier la mise à niveau
    4. Tester l'organisation mise à niveau

    La plupart des mises à niveau ne prennent que quelques minutes.

    Consultez Processus de mise à niveau en libre-service.

  6. Exécuter vos tests après la mise à niveau

    • Comportement de la politique de session globale
    • Inscription des Authenticators
    • Politiques de connexion aux applications
    • Récupération de mot de passe
    • Device Trust et Okta FastPass
    • Enregistrement en libre-service et enrôlement de profil
    • SDK Okta et outils tiers
    • Expérience de connexion de l'utilisateur final

    Consultez Tester votre mise à niveau.

  7. Tester le code de l'application dans un environnement Sandbox Identity Engine

    Cette étape est particulièrement importante pour les cas d'utilisation impliquant le Sign-In Widget intégré et le SDK. Les déploiements intégrés nécessitent le flux du code d'interaction dans Identity Engine. Le Sign-In Widget version 7+ active Identity Engine par défaut.

    Consultez Effectuer une mise à niveau vers Okta Identity Engine.

Pratiques de test répétables

  • Documentez chaque modification de configuration effectuée dans l'environnement de test.
  • Dans la mesure du possible, utilisez Terraform ou des scripts pour automatiser l'approvisionnement de l'organisation .
  • Maintenez une liste de contrôle des scénarios de test que vous exécutez avant et après la mise à niveau.
  • Veillez à la cohérence des utilisateurs de test et des chemins de statégies entre les exécutions de tests.
  • Stockez les résultats pour pouvoir les comparer entre les répétitions.

Zones à haut risque à tester

Focus sur les domaines où Identity Engine modifie le comportement de l'authentification :

Zone Pourquoi c'est important
Sign-In Widget Identity Engine modifie la configuration du Sign-In Widget et supprime certaines options classiques.
Domaine personnalisé/page de connexion personnalisée Les pages de connexion classiques personnalisées peuvent ne pas fonctionner après la mise à niveau.
API d'authentification /AuthJS/ /authn intégrée L'API Classic Engine /authn ne fonctionne pas avec Identity Engine.
Device Trust Identity Engine utilise Okta Verify et des certificats gérés. Supprimez les règles de routage IWA.
Outils tiers (AWS CLI, Jamf Connect) Les outils plus anciens utilisant les méthodes d'authentification de Classic Engine peuvent cesser de fonctionner.
flux de connexion de l'utilisateur final Identity Engine peut introduire des flux identificateur en premier et un comportement de récupération différent.

Après la mise à niveau

Après la mise à niveau de production, validez les fonctionnalités spécifiques et évitez les modifications de paramètres non reliés pendant au moins une semaine. Consultez Liste de contrôle après mise à niveau.