Identity as a Service:Conditional access policies

Introduction

A conditional access policy lets you enforce different decisions for different access scenarios, such as requiring different two-factor authentication methods for different applications.

Custom policies require a separate purchase (Conditional Access Billing). Default policies are free to use.

Key concepts

Term	Description
Custom policy	Lets you define custom conditions, such as visitors, accessible objects, and restrictions. This feature requires the conditional access module.
Default policy	A system policy pre-configured in your IDaaS EIAM instance. You can adjust its two-factor authentication settings but cannot customize other conditions.
Access condition	The system makes an access decision only when the access context matches all conditions in the policy. Otherwise, the system evaluates policies with a lower priority.
Access decision	The action to take when all access conditions are met. The available actions are to allow access, deny access, or require two-factor authentication.

Add a custom conditional access policy

To add a custom conditional access policy, click Login > Conditional Access Policy > Add Policy. You can add up to 10 custom policies.

The default policy section of the page contains a pre-configured default policy. Its access decision is to allow access and require two-factor authentication. This policy applies to all accounts, organizations, and groups, has a priority of 1001, and is enabled by default.

Step 1: Basic information

• Policy name: Enter a name for the policy. This name is displayed only in the console and is not visible to end users.

• Priority: Each access request triggers only one conditional access policy. You can set the priority to implement flexible access control. Enter a value from 1 to 100. A smaller value indicates a higher priority.

Step 2: Accessible object

The accessible object is the application protected by the policy. You can select All Applications or Specific Application.

• All Applications: This condition is met when any application is accessed.

• Specific Application: This condition is met only when a specified application is accessed. You can select the IDaaS Application Portal or other applications you have created in the instance.

Step 3: Visitor

The visitor is the account initiating the access request. You can select All Accounts, All Groups, or Specific Account.

• All Accounts: Any account meets this condition.

• All Groups: This condition is met if the account belongs to any group.

• Specific Account: Only specified accounts meet this condition. You can select accounts directly or by organization or group.

You can also use Exclude Visitors to specify accounts that will not meet this condition, preventing them from triggering this policy.

Click the Set link to configure exclusion rules. You can exclude accounts directly or by organization or group. Excluding an organization prevents all its accounts from triggering the policy, even if they are individually specified in the visitor scope.

Step 4: Conditions

A network scope is an entity that you can define independently, allowing you to dynamically adjust IP addresses without modifying other configurations. You can manage them in the Network Scope settings. For this condition, you can select No network scope restrictions or Specific network scope.

• No network scope restrictions: The visitor meets this condition regardless of their network location (IP address).

• Specific network scope: This condition is met only when the access request originates from a specified network scope (IP address).

Step 5: Access decision

When an access request meets all policy conditions, the policy is triggered, and IDaaS enforces the specified access decision: allow access, deny access, or require two-factor authentication.

• Allow access: Allows the access request when the policy is triggered. You can configure additional settings to enhance security or convenience:

  • Select two-factor authentication mode: Control whether two-factor authentication is required.

    • Do Not Require Two-Factor Authentication: The account can access the application directly without completing two-factor authentication.

    • Custom Two-Factor Authentication: The account must complete two-factor authentication using one of the specified methods. For example, you can require a stricter authentication method for highly sensitive applications.

  • Select two-factor authentication methods: Select one or more authentication methods that the account is allowed to use. The account must pass authentication using one of the selected methods.

  • Automatic MFA pass-through: If an account is already logged in and the current session meets the policy conditions, the account can bypass two-factor authentication. For example, if Applications A and B are both protected by the same conditional access policy that requires an SMS verification code, an account that has accessed Application A can access Application B without authenticating again.

  • Automatic MFA pass-through validity period: Set a validity period for this feature to prevent misuse and ensure access security.

• Deny access: Denies the access request when the policy is triggered.

Delete a custom conditional access policy

You can manually delete a custom conditional access policy. Before deleting, you must disable the policy. To avoid disrupting user access, monitor access after disabling the policy to ensure there are no issues. Deletions are permanent.

Default conditional access policy

The default conditional access policy acts as the lowest-priority policy. It is permanently in effect for all accounts and applications, and its scope and conditions cannot be adjusted. To enable or disable two-factor authentication, or to change authentication methods, go to the Two-Factor Authentication page.

Use cases

Scenario	Policy	Configuration	Description
Allow sign-in to IDaaS (or a specific application) only from office IPs	Policy 1	Priority: 1 Application scope: All Visitor scope: All Client network scope: Your office IP Access decision: Allow access	This high-priority policy allows access if the IP condition is met.
	Policy 2	Priority: 2 Application scope: All Visitor scope: All Client network scope: No restrictions Access decision: Deny access	This lower-priority policy denies access if Policy 1 is not triggered.
Require WebAuthn logon for two-factor authentication for a specific application	Policy 3	Priority: 1 Application scope: Specify the application to protect Visitor scope: All Client network scope: No restrictions Access decision: Allow access Select two-factor authentication mode: Custom Two-Factor Authentication, select WebAuthn Automatic MFA pass-through: Any	When accessing the specified application, the user must complete two-factor authentication using WebAuthn (such as a local fingerprint or face recognition).
Require two-factor authentication for every access to a highly sensitive application	Policy 4	Priority: 1 Application scope: Specify the application to protect Visitor scope: All Client network scope: No restrictions Access decision: Allow access Select Two-Factor Authentication Mode: Custom Two-Factor Authentication Automatic MFA Pass-through: Disabled	Each single sign-on (SSO) to the application requires two-factor authentication.
Different access requirements for accounts in Group A and Group B	Policy 5	Priority: 1 Application scope: All Visitor scope: Group A Client network scope: No restrictions Access decision: Allow access	This is the conditional access policy for Group A.
	Policy 6	Priority: 1 Application scope: All Visitor scope: Group B Client network scope: No restrictions Access decision: Allow access Select Two-Factor Authentication Mode: Custom Two-Factor Authentication	This is the conditional access policy for Group B.