Conditional access policies control who can access which applications and under what conditions. Each policy is an if-then rule: if an access request matches all conditions, then IDaaS enforces the configured access decision (allow or deny, with optional two-factor authentication).
Two types of policies are available:
| Type | What it does | Cost |
|---|---|---|
| Default access control policy | System-provided policy that applies to all accounts and applications at the lowest priority. Controls two-factor authentication (MFA) behavior. | Free |
| Custom access control policy | Lets you define specific conditions—application scope, visitor, and network—with a custom access decision. | Requires Enterprise Edition IDaaS EIAM 2.0 + conditional access add-on. See Conditional access billing. |
Key concepts
| Term | Description |
|---|---|
| Access condition | The set of criteria an access request must meet: accessible object (application), visitor (account), and limits (network scope). A policy is hit only if the request meets all conditions. |
| Access decision | The action enforced when a policy is hit: allow access, deny access, or allow with two-factor authentication. |
| Priority | Determines evaluation order when multiple policies exist. Valid values: 1–100. Lower value = higher priority. Only one policy is hit per access request. If no custom policy is hit, the default policy applies. |
Prerequisites
Before you create a custom access control policy, make sure you have:
An IDaaS EIAM instance (Enterprise Edition 2.0)
The conditional access add-on purchased for the instance
Create a custom access control policy
Log on to the IDaaS console. On the EIAM page, click the IDaaS EIAM instance that you want to manage. In the left-side navigation pane, click Sign-In. On the Policy tab, click Add Policy.
You can create up to 10 custom access control policies.
Step 1: Enter basic information
| Field | Description |
|---|---|
| Policy Name | Display name shown in the IDaaS console only. |
| Priority | Evaluation order relative to other policies. Valid values: 1–100. Lower value = higher priority. |
Step 2: Specify an accessible object
An accessible object is the application this policy protects.
| Application range | When this condition is met |
|---|---|
| All Applications | Any application access triggers this condition. |
| Specific Application | Only access to a selected application triggers this condition. Select the IDaaS Application Portal or an application created in the instance. |
Step 3: Specify a visitor
A visitor is the account initiating the access request.
| Visitor range | When this condition is met |
|---|---|
| All Accounts | Any account triggers this condition. |
| All Groups | If the account is the name of a group, this condition is met. |
| Specific Account | Only a selected account triggers this condition. Select directly by account, group, or organization. |
To exclude specific accounts from matching this policy, use Exclude Visitors. Excluded accounts do not hit this policy regardless of other conditions.
Step 4: Specify limits
Set the network scope that visitors must access from.
| Client CIDR block | When this condition is met |
|---|---|
| All IP Addresses | Any network location triggers this condition. |
| Specific CIDR Block | Only access from a CIDR block or IP address defined in your network scope triggers this condition. Use network scope to manage IP addresses dynamically without modifying the policy. |
Step 5: Specify an access decision
When an access request meets all conditions, IDaaS enforces the access decision.
| Access decision | Behavior |
|---|---|
| Allow Access | Grants access. Optionally configure two-factor authentication (MFA) requirements (see below). |
| Deny Access | Blocks access. If this policy targets the IDaaS Application Portal, users cannot log on to the portal. Configure with caution. |
Two-factor authentication options under Allow Access:
| Option | Description |
|---|---|
| Select Two-factor Authentication Mode: Do Not Require Two-factor Authentication | MFA is skipped; the account accesses the application directly. |
| Select Two-factor Authentication Mode: Custom Two-factor Authentication | MFA is required. Select one or more methods in Select Two-factor Authentication Method; the account must pass at least one. |
| MFA Automatic Pass | If enabled, once the account completes MFA within the same session, subsequent applications covered by the same policy skip MFA. For example, after passing SMS verification to access Application A, accessing Application B with the same policy requires no additional MFA. |
| Validity Period of MFA Automatic Pass | How long MFA Automatic Pass remains valid. After this period, MFA is required again. |
If you set Access Policy to Deny Access for the IDaaS Application Portal, users cannot log on to the portal. Proceed with caution.
A new or modified policy takes effect 3 minutes after the change is saved.
Step 6: Enable the policy
Custom policies are automatically disabled after creation to prevent accidental access disruption. After verifying your configuration, manually enable the policy on the Policy tab.
Delete a custom access control policy
Before deleting a policy, disable it first. After disabling, monitor user access to confirm no issues arise, then delete the policy. Deleted policies cannot be restored.
Default access control policy
The default access control policy applies permanently to all accounts and applications at the lowest priority. If no custom policy is hit, this policy takes effect—so every account and application is always covered.
Its scope and limits cannot be modified. To adjust two-factor authentication behavior, go to the Two-Factor Authentication page. For details, see Two-factor authentication.
Use cases
The following examples show how to combine policies for common access control scenarios.
Scenario: Allow access only from the office network
Configure two policies. Higher-priority Policy 1 allows access from your office CIDR block. Lower-priority Policy 2 denies access from any IP. Requests from outside the office miss Policy 1 and are denied by Policy 2.
| Policy 1 | Policy 2 | |
|---|---|---|
| Priority | 1 | 2 |
| Application range | All Applications | All Applications |
| Visitor range | All Accounts | All Accounts |
| Client CIDR block | Your office CIDR block | All IP Addresses |
| Access decision | Allow Access | Deny Access |
| Result | Requests from office IPs are allowed. | All other requests are denied. |
Scenario: Require WebAuthn for a specific application
| Policy 3 | |
|---|---|
| Priority | 1 |
| Application range | Specific Application |
| Visitor range | All Accounts |
| Client CIDR block | All IP Addresses |
| Access decision | Allow Access |
| Two-factor Authentication Mode | Custom Two-factor Authentication → WebAuthn |
| Result | Users must authenticate with WebAuthn (fingerprint or facial recognition) to access this application. |
For setup, see WebAuthn logon.
Scenario: Require MFA on every SSO for a sensitive application
| Policy 4 | |
|---|---|
| Priority | 1 |
| Application range | Specific Application |
| Visitor range | All Accounts |
| Client CIDR block | All IP Addresses |
| Access decision | Allow Access |
| Two-factor Authentication Mode | Custom Two-factor Authentication |
| MFA Automatic Pass | Cleared (disabled) |
| Result | MFA is required for every single sign-on (SSO) operation. MFA Automatic Pass is off, so each access requires a new MFA challenge. |
Scenario: Different access rules for different groups
| Policy 5 (Group A) | Policy 6 (Group B) | |
|---|---|---|
| Priority | 1 | 1 |
| Application range | All Applications | All Applications |
| Visitor range | Group A | Group B |
| Client CIDR block | All IP Addresses | All IP Addresses |
| Access decision | Allow Access | Allow Access |
| Two-factor Authentication Mode | — | Custom Two-factor Authentication |
| Result | Group A accesses without MFA. | Group B must complete MFA. |