In our previous discussion on syncing Active Directory with Okta, we synchronized two test accounts—Judith and Larue—from our on-premises environment. Now, we’ll explore the policies that control how users access Okta and other SaaS-based applications.
We’ll examine global and authentication policies, authenticators, and enrollment procedures. These components work together to provide granular, context-based authentication, ensuring secure and flexible access across different users, devices, and conditions. Let’s start with authenticators and enrollment policies first.
Authenticators allow users to verify their identity and offer varying levels of assurance that the person logging in is the legitimate account owner. They are used for both authentication and account recovery, and can include methods such as email, password, security questions, Okta Verify, YubiKey, and more, depending on the organization’s security requirements.
Authenticators fall into categories based on what they verify: something you know (passwords, security questions), something you have (phone apps, hardware tokens), something you are (biometrics), and phishing-resistant methods (YubiKey, FIDO2/WebAuthn) that use cryptographic keys tied to specific domains and devices.
Enrollment policies enforce the setup of authenticators and control who is enrolling and where they are enrolling from. These policies help ensure that the right users enroll in the right factors under the right conditions. Below are some images of available authenticators and an enrollment policy.
I’ve placed Judith into the Pilot group and sent her an activation email. She will need to set up a password and Okta Verify on her mobile device as long as she is in the United States. Judith receives the email, but happens to be out of the Country and gets a request denied response. Once back in the States, she can complete the enrollment process and log into her dashboard.
While authenticators work alongside authentication policies to grant access to Okta and connected applications, enrollment policies specify who is required to enroll in those authenticators. Enrollment policies themselves do not grant access—that responsibility lies with authentication policies.
Authentication policies control access to Okta and connected applications by defining who can access, from where, and using which authentication methods. These policies consider factors such as user roles, device trust status, network location, and risk level to enforce appropriate access requirements.
Judith was able to log in to her Okta dashboard after enrollment due to a default (catch-all) authentication policy. During enrollment, Judith created a password and set up Okta Verify, satisfying the required factors. Although the enrollment policy does not grant access itself, in this case, it ensured she registered the authenticators necessary to pass the authentication policy and access the dashboard.
When creating Authentication Policies, it’s important to consider both Enrollment and Global Session Policies to ensure proper functionality and a smooth user experience.
Authentication policies enable fine-grained, context-aware access control using conditional if-then rules. I have created a custom policy for the Pilot group that requires any member accessing the Okta dashboard from within the United States to authenticate using a phishing-resistant factor, such as Okta Verify FastPass or another hardware-backed method.
The policy requires users to verify their identity using either biometrics or a device passcode. I’ve created a Windows virtual machine with Windows Hello PIN to meet this requirement. Additionally, I adjusted the enrollment policy for the Pilot group to require only Okta Verify, removing the requirement for a password.
When Larue receives his activation email, he enrolls with Okta Verify on his PC. During the process, Larue chooses a Windows Hello PIN. When signing in to the Okta dashboard, he chooses Sign in with Okta FastPass and enters his PIN to authenticate and gain access.
In this scenario, Larue’s authentication to the Okta dashboard is tied to his enrolled device. For example, he cannot sign in from his mobile phone unless he first adds it as an additional trusted device through his user settings dashboard. I’ve used the dashboard for simplicity, but policies like this one can apply to any number of applications that require varying levels of authentication assurance.
Global session policies control how user sessions are established and maintained after authentication. They specify how long users stay signed in, re-authentication frequency, and which factors are required to establish or continue a session.
Global policies also use conditional if-then statements to provide fine-grained control over session behavior. I want to reiterate that it’s crucial to consider all related policies when creating a new one to avoid conflicts and ensure a seamless user experience. For example, in Larue’s case, he would have been required to set up a password if the global session policy hadn’t been configured to defer to the authentication policy.
There are many ways these policies can conflict with each other. Often, creating a new authentication policy requires corresponding enrollment and global session policies to ensure seamless functionality. That’s it for now on Okta policies. In the next post, we’ll look at integrating SaaS-based applications, assigning those apps to groups, and streamlining group enrollment using identity attributes.
Empowering individuals and businesses through cybersecurity knowledge, training, and insights.
© NAXS LABS All Rights Reserved
