Ajouter une règle de politique d'authentification à l'app

Les politiques d'authentification à l'application reposent sur des règles. Lorsque vous créez une politique d'authentification à l'app, elle commence par une seule règle fourre-tout qui autorise l'accès à toutes les demandes avec des types à deux facteurs quelconques. Configurez vos exigences en matière d'Authenticator en ajoutant des règles et en leur donnant la priorité sur la règle fourre-tout.

Par exemple, vous pouvez ajouter une règle qui demande à tous les utilisateurs de saisir un mot de passe. Vous pouvez ensuite ajouter une deuxième règle qui demande aux utilisateurs d'un groupe spécifique des Authenticators E-mail et Mot de passe.

Avant de commencer

Configurer les Authenticators

Créer une politique d'authentification à l'app

Ajouter une règle à une politique

1. Dans l'Admin Console, accédez à SécuritéPolitiques d'authentification.

2. Cliquez sur Authentification à l'application.
3. Sélectionnez la politique à laquelle vous souhaitez ajouter une règle.
4. Dans l'onglet Règles, cliquez sur Ajouter une règle.
5. Dans le champ Nom de la règle, saisissez un nom de règle.
6. Configurez les conditions IF. Ces conditions précisent quand la règle est appliquée.

   IF	Description
   IF Le type d'utilisateur de l'utilisateur est	Acceptez la valeur par défaut ou spécifiez les types d'utilisateur à inclure et à exclure.
   ET L'appartenance de l'utilisateur à un groupe inclut	Acceptez la valeur par défaut ou spécifiez les groupes utilisateur à inclure et à exclure.
   ET L'utilisateur est	Acceptez la valeur par défaut ou spécifiez les utilisateurs à inclure et à exclure.
   ET Le statut de l'appareil est	Acceptez la valeur par défaut ou sélectionnez Enregistré pour appliquer cette règle uniquement aux appareils enregistrés dans Okta Verify. Consultez Enregistrement d'appareil.
   ET La gestion des appareils est	Si vous avez sélectionné un statut d'appareil Enregistré, indiquez si la règle s'applique uniquement aux appareils gérés par une solution de gestion des appareils tierce. Si vous utilisez des règles de collecte de signaux d'appareil, ajoutez-en une pour cette sélection. Consultez Créer des règles de collecte de signaux d'appareil.
   ET Ajouter une politique d'assurance d'appareil	Si vous avez sélectionné un statut d'appareil Enregistré, vous pouvez spécifier les politiques de garantie des appareils à satisfaire. Consultez la section Ajouter une politique de garantie des appareils. Si vous utilisez des règles de collecte de signaux d'appareil, ajoutez-en une pour cette sélection. Consultez Créer des règles de collecte de signaux d'appareil.
   ET La plateforme de l'appareil est	Acceptez la valeur par défaut ou sélectionnez des plateformes spécifiques.
   ET L'adresse IP de l'utilisateur est	Acceptez la valeur par défaut ou spécifiez les zones du réseau que vous souhaitez inclure ou exclure. Vous pouvez trier par zones définies ou non définies dans Okta ou par zones dynamiques. Si vous spécifiez une zone, n'oubliez pas que les adresses IP sont dynamiques et que leur géolocalisation n'est pas garantie. Ne créez pas de politique qui repose uniquement sur l'emplacement pour refuser l'accès.
   ET Le niveau de risque est	Par défaut, cette règle s'applique aux tentatives d'authentification, quel que soit le niveau de risque. Sélectionner un niveau limite la règle au seul niveau de risque spécifié. Consultez Évaluation des risques.
   ET L'expression personnalisée suivante est vraie	Facultatif. Précisez des conditions supplémentaires avec le langage d'expression (EL). Consultez À propos des politiques de comportement et d'ouverture de session et Okta Expression Language.

7. Configurez les conditions THEN. Ces conditions précisent comment l'authentification est appliquée.

   THEN	Description
   THEN L'accès est	Refuser l'accès de l'utilisateur ou l'autoriser après une authentification réussie. Si vous refusez l'accès, passez à la dernière étape pour enregistrer votre règle. Refusé : si l'utilisateur satisfait aux conditions que vous avez configurées, refusez accès. Si vous choisissez de refuser l'accès, passez à la dernière étape pour enregistrer votre règle. Autorisé après une authentification réussie : si l'utilisateur satisfait aux conditions que vous avez configurées, autorisez l'accès.
   ET L'utilisateur doit fournir	Cet élément affiche les paramètres de la règle dans le code JSON. Il apparaît lorsque vous avez sélectionné ces options : Autorisé après une authentification réussie pour THEN L'accès est 1 type de facteur quel qu'il soit ou 1 type de facteur/IdP quel qu'il soit soit pour ET L'utilisateur doit s'authentifier avec Toutes contraintes de facteur de possession quelles qu'elles soient ET Les restrictions de facteurs de possession sont
   ET L'utilisateur doit s'authentifier avec	Choisissez les exigences d'authentification que vous souhaitez appliquer pour l'accès à l'application. Pour une description des types de facteur, consultez Authentification multifacteur. Si l'option IdP apparaît à côté de ces options d'authentification, votre Politique de session globale a spécifié un fournisseur d'identité (IdP) qui peut satisfaire l'exigence de mot de passe. Les utilisateurs qui s'authentifient via l'IdP spécifié n'ont pas besoin de fournir également un mot de passe. Version d'accès anticipé. Consultez Activer les fonctionnalités en libre-service. Vous pouvez autoriser une instance d'Authenticator spécifique dans la politique lorsqu'il existe plusieurs instances du même Authenticator dans votre org. Cette instance d'Authenticator est présentée à l'utilisateur lorsqu'il se connecte. Par exemple, si vous avez deux instances de Duo Security configurées, vous pouvez choisir quelle instance est présentée à l'utilisateur. Si l'utilisateur ne s'est pas enrôlé à cette instance d'Authenticator, il est invité à le faire lors de sa prochaine tentative d'authentification. De même, vous pouvez interdire une instance d'Authenticator spécifique dans la politique. Cette instance devient indisponible pour l'utilisateur lors de sa prochaine connexion. Le fait d'autoriser ou d'interdire une instance de l'Authenticator dans la règle de politique n'affecte pas les autres instances de l'Authenticator. Cependant, si vous autorisez ou interdisez l'Authenticator d'IdP générique, cela autorise ou interdit toutes les instances d'Authenticator IdP. 1 type de facteur quel qu'il soit : pour activer l'authentification à un facteur, choisissez une des ces options. Mot de passe ou Mot de passe/IdP exige que les utilisateurs saisissent leur mot de passe chaque fois que la règle exige une réauthentification. Si vous sélectionnez cette option, les options Les restrictions de facteurs sont ne sont pas disponibles. Facteur de possession exige que les utilisateurs fournissent un facteur de possession tel que Okta Verify ou l'e-mail pour accéder à l'application. Les options 1 type de facteur quel qu'il soit et 1 type de facteur/IdP quel qu'il soit permettent aux utilisateurs de fournir n'importe quel facteur unique pour accéder à l'application. Si vous ne sélectionnez cette option, les options Restrictions de facteurs ne seront pas disponibles. Pour les options d'authentification sans mot de passe à un facteur, consultez Configurer l'expérience d'ouverture de session sans mot de passe. 2 types de facteur : sélectionnez un de ces options pour demander aux utilisateurs de fournir deux types de facteur distincts. Mot de passe + autre facteur ou Mot de passe/IdP + autre facteur 2 types de facteur quels qu'ils soient Pour les options d'authentification sans mot de passe à deux facteurs, consultez Authentification sans mot de passe. Séquence d'authentification : exige que les utilisateurs vérifient avec plusieurs méthodes d'authentification dans une séquence spécifiée. Consultez Séquence d'authentification.
   ET Les contraintes de facteur de possession sont	Ces options ne sont pas disponibles si vous avez sélectionné Mot de passe, 1 type de facteur quel qu'il soitou 1 type de facteur/IdP quel qu'il soit. Utilisez ces paramètres pour spécifier les caractéristiques du facteur de possession. Résistant à l'hameçonnage : exige que les utilisateurs fournissent des facteurs de possession qui vérifient de manière cryptographique le serveur d'authentification (l'origine). Les clés d'accès (FIDO2 WebAuthn) et l'option Okta FastPass dans Okta Verify répondent à cette exigence. Pour plus de détails, consultez Authentification multifacteur. Protégé de façon matérielle : exige que les clés utilisées pour s'authentifier soient stockées dans du matériel sécurisé sur l'appareil. Sur les appareils Windows et Android, il utilise le TPM. Sur les appareils macOS et iOS, il utilise Secure Enclave. L'emplacement de stockage des clés détermine si Okta Verify répond aux exigences de protection matérielle. Si Okta Verify peut stocker les clés dans du matériel sécurisé, alors il répond à l'exigence de protection matérielle. Si aucun matériel sécurisé n'existe sur l'appareil, Okta Verify utilise un stockage logiciel. Dans ce cas, il ne répond pas à l'exigence de protection matérielle. Pour identifier la façon dont les clés Okta Verify sont stockées sur un appareil, consultez l'attribut d'appareil secureHardwarePresent dans l'Admin Console. Vous pouvez également utiliser une expression Okta Expression Language (EL) pour déterminer la valeur de device.profile.secureHardwarePresentview. Si cette valeur est vraie, un matériel sécurisé est utilisé. Consultez Attributs de langage d'expression pour les appareils. Certains Authenticators WebAuthn sont protégés de façon matérielle. Okta utilise le service de métadonnées FIDO Horizon (MDS) pour déterminer si un Authenticator WebAuthn est protégé de façon matérielle. Un Authenticator est considéré comme protégé de façon matérielle lorsque l'une de ses valeurs keyProtection est Matérielle. Les Authenticators WebAuthn protégés de façon matérielle présentent certaines limitations : Les enrôlements effectués avant le 30 novembre 2022 ne sont pas pris en charge. Les enrôlements utilisant FIDO U2F ne sont pas pris en charge. Les enrôlements sur Firefox ne sont pas pris en charge actuellement. Les enrôlements sur Chrome ne sont pas pris en charge actuellement si la Vérification d'utilisateur est définie sur Déconseillée et qu'un code PIN est défini sur la clé de sécurité. Si le système les y invite lors de l'enrôlement, les utilisateurs doivent autoriser Okta à voir la marque et le modèle de la clé de sécurité. Exiger une interaction de l'utilisateur : cette option vous permet de choisir si vous voulez demander aux utilisateurs finaux de prouver qu'ils sont physiquement présents pour s'authentifier. Si vous ne sélectionnez pas cette option et que la politique d'authentification à l'app requiert un facteur de possession, Okta Verify effectuera une authentification basée sur un certificat. Cela permet aux utilisateurs d'accéder à la ressource sans prouver qu'ils sont physiquement présents. En outre, si vous sélectionnez cette option, vous ne pouvez pas utiliser une question de sécurité comme facteur supplémentaire. Exiger un code PIN ou une vérification biométrique de l'utilisateur : cette option apparaît lorsque vous cliquez sur Exiger une interaction de l'utilisateur. Exigez que les utilisateurs saisissent un code PIN ou utilisez la biométrie pour vérifier leur identité. Lorsque vous sélectionnez cette option, les utilisateurs doivent vérifier leur identité avec un authentificateur qui prouve la présence de utilisateur : Okta Verify avec la notification Push, Clés d'accès (FIDO2 WebAuthn), Okta FastPass, authentificateur personnalisé ou carte à puce (avec code PIN). Configurez chacun de ces Authenticators de présence utilisateur pour exiger une vérification de l'utilisateur. Cela permet d'éviter que les utilisateurs ne soient bloqués et garantit que les nouveaux enrôlements à ces Authenticators répondent à l'exigence de vérification de l'utilisateur. Configurez les Authenticators pour exiger la vérification de l'utilisateur : Accédez à SécuritéAuthenticators. Cliquez sur l'onglet Configuration. Cliquez sur ActionsModifier pour l'Authenticator que vous souhaitez configurer. Pour Okta Verify avec notification push, les clés d'accès (FIDO2 WebAuthn), l'authentificateur personnalisé et Okta FastPass, sélectionnez Obligatoire dans le menu déroulant de la section Vérification de l'utilisateur. Pour la carte intelligente, sélectionnez PIN. Exiger l'enrôlement d'utilisateur aux Authenticators qui satisfont la vérification de l'utilisateur. Consultez Créer une politique d'enrôlement des Authenticators. Dans la section Authenticators, définissez chacun de vos Authenticators de présence utilisateur sur Obligatoire. Les utilisateurs ne peuvent pas s'authentifier s'ils n'activent pas une option de vérification de l'utilisateur dans un Authenticator auquel ils sont enrôlés. Les utilisateurs doivent réinitialiser ces enrôlements et les remplacer par de nouvelles, ou activer les notifications Push et la vérification biométrique dans Okta Verify.
   ET Méthodes d'authentification	Ces options ne sont pas disponibles si vous sélectionnez Mot de passe comme méthode d'authentification. Autoriser toute méthode pouvant être utilisée pour répondre à l'exigence : les utilisateurs peuvent être authentifiés à l'aide de n'importe laquelle des méthodes disponibles qui répondent à l'exigence. Ne pas autoriser les méthodes d'authentification spécifiques : sélectionnez les méthodes à exclure de l'authentification. Lorsque cette option est sélectionnée, toutes les méthodes disponibles sont autorisées, sauf celles ajoutées à la liste des exclusions. Autoriser les méthodes d'authentification spécifiques: sélectionnez des méthodes pour autoriser leur utilisation dans authentification. Lorsque cette option est sélectionnée, toutes les méthodes disponibles sont interdites, sauf si elles sont ajoutées à la liste d'autorisation.
   Option pour maintenir la connexion ouverte	Ce paramètre vous permet d'afficher l'invite Resté connecté aux utilisateurs après leur authentification avec cette app. Cette sélection contrôle l'affichage de l'invite, mais elle ne limite pas la fonctionnalité de cette app. Resté connecté est un paramètre global qui s'applique à toutes les apps. Voir Rester connecté.
   Voir si non présentée précédemment sur l'appareil actuel de l'utilisateur	Si vous sélectionnez Option pour maintenir la connexion ouverte, indiquez la durée avant que l'invite Maintenir la connexion ne s'affiche à nouveau. Ce paramètre concerne uniquement l'invite et est indépendant de la durée de vie configurée pour la MFA.
   Demande d'authentification	Cette option apparaît si vous exigez les options 1 type de facteur quel qu'il soit ou 2 types de facteur quels qu'ils soient pour l'authentification. Indiquez la fréquence à laquelle un utilisateur doit s'authentifier. Chaque fois que l'utilisateur se connecte à une ressource : les utilisateurs doivent s'authentifier chaque fois qu'ils essaient d'accès à l'app. Il s'agit de l'option la plus sécurisée. Lorsqu'une durée spécifiée s'est écoulée depuis la dernière connexion de l'utilisateur à une ressource protégée par la session globale Okta active : les utilisateurs sont invités à s'authentifier lorsqu'ils dépassent l'intervalle de temps que vous avez défini. Lorsqu'une session globale Okta n'existe pas : les utilisateurs sont invités à s'authentifier s'ils n'ont jamais établi de session globale Okta active. Une période de grâce de 10 secondes s'applique après qu'un utilisateur se soit authentifié. Pendant cette période de grâce, les utilisateurs ne sont pas invités à s'authentifier de nouveau si vous avez sélectionné À chaque connexion de l'utilisateur à la ressource.
   Demander l'authentification par mot de passe et Demande d'authentification pour tous les autres facteurs d'authentification	Ces options apparaissent si vous exigez Mot de passe + autre facteur ou Mot de passe/IdP + autre facteur pour l'authentification. Sélectionnez des intervalles de fréquence pour le mot de passe et les autres facteurs.

8. Cliquez sur Enregistrer.
9. Pour utiliser les signaux d'appareil dans le cadre de votre politique d'authentification à l'app, consultez Créer des règles de collecte de signaux d'appareil.

L'étape suivante, après avoir ajouté des règles à une politique, consiste à appliquer cette politique à une ou plusieurs apps. Il n'y a pas de limite au nombre d'apps qui peuvent partager une politique.

Questions de sécurité dans une politique d'authentification à l'app

L'Authenticator de question de sécurité invite les utilisateurs finaux à saisir une réponse correcte à une question qu'ils ont sélectionnée dans une liste de questions possibles.

• Les questions de sécurité de l'Authenticator prennent en charge les scénarios d'authentification (MFA/SSO) et de récupération du mot de passe. En cas de désactivation pour la MFA/SSO, il n'est pas inclus dans l'évaluation de la politique d'authentification à l'app ou de la politique de session globale.
• Vous pouvez utiliser l'Authenticator Question de sécurité comme vérification progressive ou supplémentaire lorsque le facteur principal dans la politique de session globale de l'utilisateur est Un mot de passe. N'utilisez pas de questions de sécurité dans un flux d'authentification.

Vous pouvez configurer Okta pour qu'il utilise cet Authenticator uniquement pour le recouvrement de compte, ou à la fois pour l'authentification et le recouvrement de compte. Si vous choisissez uniquement l'option de récupération, Okta ne demande pas d'authentification pendant l'évaluation de votre Politique de session globale.

Pour permettre à vos utilisateurs d'accéder à Okta FastPass sans prouver qu'ils sont physiquement présents, vous ne pouvez pas utiliser une question de sécurité comme facteur supplémentaire. Si vous voulez que les utilisateurs utilisent des questions de sécurité, vous devez utiliser l'option Un mot de passe dans la Politique de session globale.

Limitations

• Les règles de politique d'authentification à l'application ne reconnaissent pas ChromeBook comme une plateforme ChromeOS si les utilisateurs accèdent à leurs ressources via un navigateur Firefox ou Opera.

• Comme Okta Verify n'est pas disponible pour ChromeOS, Okta FastPass n'est pas pris en charge par ce système d'exploitation. La condition L'accès avec Okta FastPass est accordé n'a aucun effet dans les règles qui vérifient pour ChromeOS.

• Si des utilisateurs se connectent à partir d'un appareil ChromeOS, aucun enregistrement d'appareil n'est créé.

• Vous ne pouvez pas utiliser ChromeOS dans les expressions personnalisées.

Étapes suivantes

Créer des règles de collecte de signaux d'appareil

Affecter des apps à une politique d'authentification à l'app

Mettre à jour une politique de connexion à l'app