Politiques et règles Okta
Okta utilise des politiques et des règles qui vous permettent de personnaliser les exigences de diverses actions. Okta inclut les politiques suivantes :
- Politique de session globale : les politiques de session globale fournissent le contexte de connexion nécessaire pour que l'utilisateur puisse passer à l'étape d'authentification suivante une fois qu'il a été identifié par Okta.
- Politique de connexion à l'app : exige l'authentification de l'utilisateur final dans le contexte de l'app demandée. L'emplacement et le profil de l'utilisateur (également identifiés par la politique de session globale) sont vérifiés par rapport à l'appartenance à un groupe et aux critères d'authentification de la politique de connexion.
- Politique Okta Account Management : cette politique définit les exigences d'authentification lorsque les utilisateurs s'inscrivent à des Authenticators, récupèrent leur mot de passe et déverrouillent leur compte.
- Politique de protection de session : cette politique vous permet de configurer des options pour la surveillance des sessions en cas de changements de contexte, qui pourraient indiquer que la session risque d'être piratée ou d'autres situations.
Vous pouvez également utiliser des politiques de session globale et de connexion à l'app à des fins spécifiques :
- Politiques de connexion à l'app de première partie : Okta dispose de plusieurs apps de première partie qui sont disponibles par défaut pour chaque instance Okta.
- Expériences sans mot de passe : utilisez une combinaison de politiques de connexion globales pour les sessions et les apps pour permettre aux utilisateurs de se connecter sans utiliser de mot de passe.
Toutes ces politiques renforcent le niveau de confiance dans le fait que l'utilisateur qui se connecte à une application est également la personne qui possède le compte. Ce niveau est mesuré par l'utilisation d'un ou plusieurs Authenticators et par les caractéristiques de ces Authenticators. Un utilisateur qui peut s'authentifier à la fois avec un facteur de connaissance et un facteur de possession a un niveau d'assurance plus élevé que celui qui ne peut s'authentifier qu'avec un seul facteur.
Identity Engine exige que les niveaux d'assurance spécifiés dans les politiques de session globale et les politiques d'authentification soient satisfaits avant d'autoriser l'utilisateur final à accéder à une app. C'est un changement par rapport au modèle traditionnel d'authentification, qui évalue une politique selon que l'utilisateur se connecte à l'org ou directement à l'app.
Pour déterminer si une politique est appliquée à un utilisateur particulier, Okta évalue les conditions de la politique et ses règles.
- Les politiques contiennent des groupes de ressources qui requièrent un traitement similaire, comme les apps avec les mêmes caractéristiques de sécurité ou les groupes d'utilisateurs avec les mêmes exigences de configuration de compte.
- Les règles décrivent les conditions du comportement de la politique, comme les demandes provenant d'un emplacement géographique ou le fait que l'utilisateur soit sur ou hors d'un réseau de confiance. Chaque politique doit comporter au moins une règle avant d'être appliquée.
La meilleure pratique consiste à placer les règles restrictives en haut de la liste Priorité. Vous pouvez également créer des combinaisons de conditions pour plusieurs scénarios. Il n'y a pas de limite au nombre de règles que vos politiques peuvent comporter.
Si la politique applicable à l'utilisateur requiert un certain Authenticator et que l'utilisateur ne l'a pas inscrit, il est invité à inscrire l'Authenticator lorsqu'il essaie d'accéder à l'org ou à une app. Lors de l'inscription du nouvel Authenticator, l'utilisateur doit d'abord s'identifier avec une authentification à deux facteurs (2FA) dans la mesure du possible. La condition 2FA s'applique, quelles que soient les politiques en vigueur.