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

Les politiques de connexion à l'app définissent la manière dont un utilisateur doit s'authentifier pour accéder à une app (appelée également « app »). Elles vérifient que l'utilisateur répond aux exigences spécifiques d'une app, comme l'appartenance à un groupe, la zone d'IP depuis laquelle il se connecte, le niveau de risque, etc. Si l'utilisateur répond aux exigences de la politique de connexion d'une app, l'accès à l'app lui est accordé.

Vous pouvez créer une politique unique pour chaque app de votre org ou créer quelques politiques et les partager entre plusieurs apps. Vous pouvez également utiliser des politique prédéfinies d'Okta pour les apps ayant des exigences de connexion standard.

Toutes les nouvelles apps, à l'exception des apps de services API, démarrent avec la politique par défaut partagée. Cette politique comporte une règle d'alias collecteur unique qui autorise l'accès d'un utilisateur avec deux facteurs. Vous pouvez ajouter autant de règles à la politique par défaut que nécessaire. Cependant, n'oubliez pas que les modifications sont appliquées aux apps nouvelles et existantes qui sont affectées à la politique partagée par défaut.

Les règles sont numérotées. Okta évalue les règles dans l'ordre dans lequel elles apparaissent sur la page des politiques de connexion à l'application. Vous pouvez réorganiser les règles ajoutées en cliquant et en faisant glisser la « poignée » verticale en pointillés qui apparaît sous le numéro d'une règle.

Okta évalue la politique d'authentification à l'app chaque fois qu'un utilisateur accède à une app. Si l'utilisateur n'a pas de session Okta, Okta évalue également la Politique de sessions globales. Consultez Politiques de session globale.

Lorsqu'Okta évalue s'il faut appliquer la politique à un utilisateur particulier, les conditions d'une politique et celles de ses règles sont combinées. Okta évalue les règles suivant l'ordre dans lequel elles apparaissent dans la liste. Si un utilisateur ne remplit pas les conditions de la première règle, Okta évalue la deuxième règle.

Si vous avez migré depuis Device Trust sur Classic Engine vers Identity Engine, cette erreur apparaît dans le journal sytème si vous avez une politique d'authentification à l'app qui exige des appareils enregistrés :

Authentification via certificat Device Trust - échec : NO_CERTIFICATE)

Il s'agit d'un comportement attendu qui est résolu lorsque de la migration vers Okta FastPass. Il se produit parce que le serveur tente une vérification Device Trust avec un appareil qui n'a pas de certificat client. L'utilisateur peut toujours se connecter, mais l'appareil est considéré comme non fiable. Consultez Configurer Okta FastPass.

Avant de commencer

Lancer la procédure

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

  2. Cliquez sur Connexion à l'application.
  3. Sélectionnez la politique d'authentification à l'application à laquelle vous souhaitez ajouter une règle.
  4. Cliquez sur Ajouter une règle.
  5. Saisissez le Nom de la règle afin de la décrire.

  6. Configurez les conditions IF appropriées pour déterminer quand la règle doit s'appliquer.

    Certaines conditions servent à l'audit et au filtrage des événements et ne doivent pas être utilisées comme base pour définir votre posture de sécurité. Par exemple, un acteur malveillant pourrait facilement usurper la plateforme d'un appareil. N'utilisez pas la plateforme de l'appareil comme composant clé d'une règle de politique d'authentification à l'app.

  7. Configurez les conditions THEN appropriées pour déterminer comment l'authentification est appliquée.
  8. Configurez la fréquence de réauthentification, si nécessaire.
  9. Cliquez sur Enregistrer.

Étapes suivantes