ºÚÁϺ£½Ç91Èë¿Ú

To implement Zero Trust security for your organization, create conditional access policies that secure access to resources based on conditions like a user's identity, their network, or the type of device they’re on. For example, lock down your environment with policies that deny access when users are on unmanaged devices or unapproved networks. Alternatively, relax access and let users log in to the User Portal without Multi-factor Authentication (MFA) when they’re using a VPN or managed device. 

Considerations:

• Desktop access policies using Device Trust Certificates are only supported on the following browsers:
  • Windows: Google Chrome, Microsoft Edge
  • macOS: Google Chrome, Safari
  • Linux: Google Chrome
• Mobile devices are supported using Mobile Device Trust. See Get Started: Mobile Device Trust to learn more.
• An access policy becomes a conditional access policy when you add a condition. Adding a condition for the User Portal or SSO Applications is a Premium feature and is part of our Platform Prime plan.

Conditional Access Policies List View 

To find the list view, log in to the and go to SECURITY MANAGEMENTÌý&²µ³Ù;ÌýConditional Policies.

From the list view you can: 

• See a list of the access policies that you’ve configured.
• Configure (or delete) new access policies for the User Portal, SSO Applications, or ºÚÁϺ£½Ç91Èë¿Ú LDAP.
  • See Configure a Conditional Access Policy
• Access the Conditional Policy Settings page, where you can enable Certificate Distribution and manage Default Access Policies. To make changes to these policies, click Edit in Settings under Default Access Policies.
  • See Set a Default Access Policy

Understanding Policy Precedence

Before you create several access policies, it’s important to understand policy precedence so that you don’t accidentally lock out your users. When you have several policies enabled, the policy precedence is the following:

• A policy set to deny access is first priority.
• A policy set to allow access with MFA is second priority.
• A policy set to allow access without MFA is third priority. 

This means if several policies with different actions apply to a single user, the policy that denies access takes effect over policies that allow access with or without MFA. 

For example: consider these two policies:

• One policy denies access to the User Portal if a user isn’t on an approved network (conditional). You include a specific user group with this policy.
• Another policy allows access to the user portal with MFA. You include all your users with this policy. 

Result: If a user is included in both policies and they try to log in to the User Portal from an unapproved network, they’re denied access. 

With that in mind, we recommend being very specific when you create a policy that denies access. If you’re not careful, you could prevent your users from being able to access resources. 

When no conditional access policies apply to a user, the Default Access Policy takes effect. For example, say you have:

• An access policy that allows access without MFA.
• A user who isn’t included in the policy.
• The Default Access Policy set to allow access with MFA.

In this case, the user is required to authenticate with MFA.

Supported Resources

You can create access policies for the User Portal, SSO applications, and LDAP applications. An access policy becomes a conditional access policy when you add a condition. Adding a condition for the User Portal or SSO Applications is a Premium feature and is part of our Platform Prime plan.

A policy can only have one resource type associated with it, so you can’t have one policy that applies to both the User Portal and SSO Applications. 

• User Portal: Configure a policy that relaxes, restricts, or denies access to the User Portal.
  • For example, use a device condition to let users log in to the User Portal without MFA when they’re on a ºÚÁϺ£½Ç91Èë¿Ú-managed device, or set a policy across all your users that requires MFA to access the User Portal. 

• SSO Applications: Use a policy to relax, restrict or deny access to SSO applications when users access them from the User Portal or through service provider-initiated authentication.
  • For example, enable a policy for your software engineer user groups that requires them to use MFA when they access AWS and GitHub applications.
• LDAP Applications: Use a policy to relax, restrict or deny access to LDAP applications when users access them from the User Portal.
  • For example, enable a policy for your users that requires them to use MFA when accessing the VPN.
  • Note that conditions are not applicable for LDAP access policies.

• When you create an access policy that requires MFA, users who are included in the policy but don’t have MFA set up will be required to enroll in MFA the next time they log in to the User Portal. 

Supported Conditions

Configure your access policies with conditions to control level of access to the User Portal and SSO Applications. Conditions are a premium feature and are part of the Platform Prime plan.

Examples of ways to leverage conditions to support your security posture include:

• Device Management
  • Block access to work applications from unmanaged devices.
  • Require users to use MFA when they access work applications on managed devices.
• Disk Encryption
  • Deny access to resources when the device does not have disk encryption enabled.
• Location
  • Block access to secure resources when the authentication request is coming from an unknown or untrusted country.
• IP Address
  • Relax MFA requirements if the request to authenticate is coming from inside the corporate network.
  • Require step-up authentication when the request to authenticate is coming from outside a trusted network.
• Operating System
  • Enable granular control and target specific device types by operating system in a policy. For example:
    • Configure a policy with the Device Management condition to block devices not managed by ºÚÁϺ£½Ç91Èë¿Ú, but add the Operating System condition for macOS, Windows, and Linux. This allows access for mobile devices, while preventing access from unmanaged desktop devices.
    • Or configure a policy with the Device Management condition and use the Operating System condition to target mobile devices specifically (iOS/iPad OS and Android).