Migration de la politique d'authentification à l'app

Les politiques d'authentification à l'app dans Identity Engine présentent des paramètres similaires aux politiques d'authentification aux apps dans Classic Engine, bien qu'il y ait quelques différences importantes. Ce tableau décrit les tâches de configuration dans Classic Engine et Identity Engine.

Tâche

Classic Engine

Identity Engine

Nommer une règle Nom de la règle Nom de la règle
Indiquer les utilisateurs auxquels appliquer cette règle
  • Tous les utilisateurs affectés à cette app (par défaut)
  • Sélectionner des groupes
  • Sélectionner des utilisateurs
  • Exclure des groupes
  • Exclure des utilisateurs
  • Tout type d'utilisateur affecté à cette app (par défaut)
  • Sélectionner des groupes
  • Sélectionner des types d'utilisateur
Spécifier où un utilisateur doit se trouver pour accéder à l'application Si l'utilisateur est localisé :
  • N'importe où (N'importe quelle adresse IP)
  • Dans la zone (Spécifique)
  • Pas dans la zone
L'adresse IP de l'utilisateur est :
  • N'importe quelle adresse IP
  • N'importe quelle zone du réseau définie dans Okta
  • Dans l'une des zones suivantes (préciser les zones)
Configurer le client ou l'appareil Appliquer la règle à des plateformes spécifiques en fonction de vos politiques d'accès client (CAP).

Appliquer des règles aux appareils de confiance et non de confiance.

Les CAP migrent, mais les règles pour les appareils de confiance et non de confiance ne migrent pas. Vous devez créer de nouvelles règles pour les appareils enregistrés et non enregistrés.
Indiquer le score de risque acceptable Ceci n'est pas disponible dans les politiques d'authentification à l'app Classic Engine. Appliquer la règle uniquement à l'événement d'authentification à l'app avec une notation du risque spécifique.
Expressions personnalisées Ceci n'est pas disponible dans les politiques d'authentification à l'app Classic Engine. Appliquer la règle uniquement lorsqu'une expression personnalisée est vraie.

Accès

Lorsque toutes les conditions sont remplies, l'accès est autorisé :
  • Autorisé
  • Refusé
Lorsque toutes les conditions sont remplies, l'accès est autorisé :
  • Refusé
  • Autorisé après une authentification réussie
Exigences d'authentification
  • Demander la réauthentification par mot de passe (durée)
  • Demander le facteur (fréquence)
Appliquer les exigences d'assurance pour accéder à l'application.
  • Spécifier quand un utilisateur est invité à se ré-authentifier.
  • Pour la sélection du mot de passe, spécifiez les durées de réauthentification par mot de passe et de réauthentification sans mot de passe.

L'ajout le plus important aux politiques d'Identity Engine est l'exigence d'assurance : les utilisateurs qui remplissent toutes les conditions d'une politique de connexion s'authentifient auprès de l'app uniquement avec les exigences d'assurance appropriées. Parmi les autres améliorations apportées à Identity Engine, citons l'évaluation des risques et les expressions personnalisées, qui garantissent que les utilisateurs répondent aux critères de niveaux de sécurité personnalisés avant d'être autorisés à accéder à l'application.

Scénarios de migration de Classic Engine vers Identity Engine

Lorsque vous configurez une politique d'authentification à l'app dans Classic Engine, toutes les options du client sont sélectionnées par défaut. Vous pouvez ajouter des règles en fonction de l'identité des utilisateurs, des groupes auxquels ils appartiennent, du client et de la plateforme de leur appareil, et du fait qu'ils se trouvent ou non sur le réseau.

Lorsque vous effectuez une mise à niveau vers Identity Engine, vos politiques d'authentification à l'app Classic Engine migrent à quelques conditions près.

Noms des politiques

Dans Identity Engine, les politiques migrées portent le nom de l'app à laquelle elles s'appliquent (politique <nomdel'app>). Si plusieurs apps avaient des politiques identiques dans Classic Engine, ces politiques sont rassemblées en une seule politique partagée. Les politiques consolidées utilisent la même structure de nom, avec le préfixe « Merged » ([Merged]politique <nomdel'application1>,<nomdel'application2>,<nomdel'application3>).

Politiques par défaut

Les apps dans Classic Engine qui utilisaient la politique d'authentification à l'app par défaut migrent vers une politique d'authentification à l'app Okta Identity Engine avec la règle collectrice par défaut activée. Les apps qui utilisent uniquement la règle collectrice permettent l'accès à n'importe quel utilisateur affecté à l'app, sans authentification supplémentaire (au-delà de ce qui est requis dans la politique de session globale).

  • IF Le type d'utilisateur de l'utilisateur est : N'importe lequel
  • ET L'appartenance de l'utilisateur à un groupe : N'importe lequel
  • ET Le fournisseur d'identité de l'appareil est : N'importe lequel
  • ET L'adresse IP de l'utilisateur est : N'importe quelle zone
  • ET Le niveau de risque est : N'importe lequel
  • ET L'expression personnalisée suivante est vraie : N/A
  • THEN L'accès est : Autorisé
  • ET L'utilisateur doit s'authentifier avec : 1 type de facteur quel qu'il soit
  • ET Les contraintes de facteur de possession sont : N/A
  • Okta Verify L'interaction de l'utilisateur est : Toujours requis(e)
  • Demande d'authentification : Lorsqu'une session globale Okta n'existe pas

La politique de chaque app dans Okta Identity Engine contient la règle collectrice. La règle collectrice (catch-all) peut être modifiée, mais pour un accès plus personnalisé, vous pouvez ajouter d'autres règles et les classer par ordre de priorité.

Réauthentification + vérification des facteurs

Les politiques d'authentification à l'app Classic Engine avec la réauthentification et la vérification des facteurs activées migrent vers une politique d'authentification Okta Identity Engine avec le facteur de mot de passe et tout facteur supplémentaire activé. La fréquence de réauthentification est déterminée par la durée spécifiée dans la politique Classic Engine. Par exemple, une politique Classic Engine qui exige une ré-authentification par mot de passe toutes les deux heures et une demande de facteur à chaque fois migre vers une règle de politique Identity Engine de :

  • IF Le type d'utilisateur de l'utilisateur est : N'importe lequel
  • ET L'appartenance de l'utilisateur à un groupe : N'importe lequel
  • ET Le fournisseur d'identité de l'appareil est : N'importe lequel
  • ET L'adresse IP de l'utilisateur est : N'importe quelle zone
  • ET Le niveau de risque est : N/A
  • ET L'expression personnalisée suivante est vraie : N/A
  • THEN L'accès est : Autorisé
  • ET L'utilisateur doit s'authentifier avec : Mot de passe + autre facteur
  • ET Les contraintes de facteur de possession sont : N/A
  • Okta Verify L'interaction de l'utilisateur est : Toujours requise
  • Demander l'authentification par mot de passe : 2 heures
  • Demande d'authentification pour tous les autres facteurs d'authentification : À chaque fois que l'utilisateur se connecte à la ressource

Multifacteur sans réauthentification

Les politiques d'authentification aux apps Classic Engine pour lesquelles l'authentification multifacteur est exigée à chaque fois sans réuthentification migrent vers une politique d'authentification à l'app Okta Identity Engine qui requiert un facteur de possession pour l'authentification avec un intervalle de réuthentification défini par les paramètres de Classic Engine.

  • IF Le type d'utilisateur de l'utilisateur est : N'importe lequel
  • ET L'appartenance de l'utilisateur à un groupe : N'importe lequel
  • ET Le fournisseur d'identité de l'appareil est : N'importe lequel
  • ET L'adresse IP de l'utilisateur est : N'importe quelle zone
  • ET Le niveau de risque est : N/A
  • ET L'expression personnalisée suivante est vraie : N/A
  • THEN L'accès est : Autorisé
  • ET L'utilisateur doit s'authentifier avec : Facteur de possession
  • ET Les contraintes de facteur de possession sont : N/A
  • Okta Verify L'interaction de l'utilisateur est : Toujours requis(e)
  • Demande d'authentification pour tous les autres facteurs d'authentification : À chaque fois que utilisateur se connecte à la ressource

Rubriques liées

Politiques d'authentification à l'app