Create and manage resource rules
Resource rules provide conditional access for applications. They determine who can access an application, which request and risk conditions IDaaS evaluates during sign-in, which authentication flow is required for the evaluated risk level, and whether access is denied.
Use this section to understand what resource rules do before you configure them. To build a rule in the admin interface, see Create resource rules.
Simple and advanced resource rules
Every application that uses IDaaS authentication needs at least one enabled resource rule. If an application has no enabled resource rule that permits the user and request, users cannot authenticate to that application.
A simple resource rule can apply one authentication flow to all matching users. Use a more advanced rule when access must depend on the user, the request, the context of the sign-in, or the risk of the protected action. Advanced rules can step up authentication or deny access when signals such as network, country, time, machine, device certificate, location history, travel velocity, transaction details, or external risk indicate higher risk.
Common reasons to create targeted or risk-based resource rules include the following scenarios:
- Require stronger authentication for privileged applications or administrator groups.
- Use a different authentication flow for employees, contractors, partners, or other user groups.
- Respond to a requested authentication context from a SAML or OIDC client.
- Route users through domain-based Identity Provider behavior.
- Step up authentication when a request comes from an unfamiliar network, location, machine, or transaction pattern.
- Deny access when the request violates a hard policy boundary, such as a denied country, denied network, or high-risk transaction.
- Force fresh authentication for sensitive applications instead of reusing an existing SSO session.
How resource rules work
When a user attempts to authenticate to an application, IDaaS evaluates the enabled resource rules for that application. The rule evaluation separates three decisions: whether the rule applies to the request, which risk signals apply, and what authentication outcome is required.
Application sign-in request
|
v
Find enabled resource rules for the application
|
v
Check access filters
(group, ACR, and domain-based IdP)
|
v
Evaluate configured risk factors
(network, location, time, machine, device, history, transaction, or external risk engine)
|
v
Calculate the risk score and classify the request
as low, medium, or high risk
|
v
Use the authentication flow configured for that risk level,
or deny access
The sections that follow describe the main parts of that evaluation: what a rule controls, how access filters match requests, how risk factors affect risk evaluation, and how the final risk level selects an authentication flow or access result.
What a resource rule controls
A resource rule is more than an MFA setting. It combines audience targeting, request matching, adaptive risk evaluation, authentication flow selection, SSO behavior, and access denial for a protected application.
- Application-specific access policy. A resource rule belongs to a resource, which is typically an application. Different applications can require different authentication behavior for the same user.
- User targeting: A rule can apply to all users or only to users in selected groups. Use group filters to give employees, contractors, administrators, or other populations different authentication requirements.
- Request targeting. A rule can apply only when the request matches selected Authentication Context Reference (ACR) values or selected domain-based Identity Provider behavior. Use these filters when the request or the user's domain must select a specific authentication path.
- Risk factors. A rule evaluates only the risk factors you configure. If a risk factor is not part of the rule, IDaaS does not use that signal to increase risk for the rule.
- Authentication flows. A rule maps low, medium, and high risk outcomes to authentication flows. Authentication flows can include user login, IDP login, IDP plus second factor, passkey login, Smart Login, user certificate login, or access denied, depending on the application type and tenant configuration.
- SSO behavior. A rule can allow SSO reuse or force fresh authentication. Disable Single Sign-On when users must reauthenticate for a sensitive application or user population.
- Access denial. A rule can deny access because the request does not match the rule, because a risk factor blocks access, because the evaluated risk level maps to Deny Access, or because strict access makes a denial override another rule that would otherwise allow access.
Access filters and request matching
Access filters decide whether a resource rule is eligible for a sign-in request before risk factors are evaluated. Use access filters when a rule must apply only to a specific user population, requested authentication context, or domain-based Identity Provider behavior. To configure access filters in a resource rule graph, see Add Access Controls.
| Access filter | What it matches |
|---|---|
| Group | Users who are members of selected groups. If you do not add a group access filter, the rule can apply to all users who otherwise match the rule. |
| ACR | Requests that include selected Authentication Context Reference values, any ACR value, or no ACR value. ACRs are access-filter inputs, not authentication flow outcomes. IDaaS provides system ACRs, and you can create custom ACRs when an application needs a specific authentication context. See Add Authentication Context References. |
| Domain-based IdP | Users who match selected domain-based Identity Provider behavior, such as no domain-based IdP, any domain-based IdP, or a specific domain-based IdP. |
Risk factors and risk evaluation
Risk factors are optional policy signals. Add a risk factor when that signal is relevant to the application, reliable for the users who access it, and useful for deciding whether to allow access, require stronger authentication, or deny access. To configure these signals in a resource rule graph, see Add Risk Factors.
Risk factors add risk points when their configured condition fails. IDaaS combines those points, normalizes the result, classifies the request as low, medium, or high risk, and then uses the authentication flow configured for that risk level.
For example, if a rule includes two configured risk factors worth 80% and 20%, and only the 80% risk factor fails, the generated risk percentage is 80%. The rule then compares that percentage to the configured risk levels and uses the authentication flow assigned to the resulting risk level.
If a resource rule has no risk factors, every request that matches the rule's access filters is evaluated as low risk. The low-risk authentication flow then becomes the authentication behavior for all matching requests.
The default risk levels are defined in the risk-based authentication settings. See Manage risk-based authentication settings. You can also modify medium-risk and high-risk thresholds in the General Settings of the Resource Rules List page.
| Risk factor | What it detects or helps prevent |
|---|---|
| Date/Time | Access outside expected business dates or times, including after-hours access, weekend or off-shift access, temporary access windows, maintenance windows, or project-specific availability windows. |
| Device Verification | Requests from devices that do not present a trusted device certificate, including unmanaged devices, devices that cannot complete certificate authentication, or requests where device identity is not trusted. |
| External | Risk signals from an external or connector-based risk engine, such as fraud, behavior, device, transaction, identity mismatch, or service-status signals that IDaaS does not calculate directly. |
| Geolocation | Requests from unexpected, disallowed, or higher-risk countries based on the request IP address. |
| Source IP Address | Requests from networks that are not trusted for the application, such as traffic outside corporate networks, VPN ranges, branch office ranges, privileged access paths, or explicitly denied IP ranges. |
| Location History | Sign-ins from locations that are not already associated with the user, such as an unfamiliar city, region, country, or IP-derived location. |
| Machine Authentication | Sign-ins from a new or unrecognized machine, or from a machine whose remembered-machine signal differs from the signal stored from a previous successful authentication. |
| Transaction | Risk in the protected action, not only the sign-in, such as transaction amount, frequency, destination, account, action, or channel patterns. |
| Travel Velocity | Impossible or unlikely travel between sign-ins, such as the same user appearing to authenticate from distant locations too close together in time. |
A remembered machine is not necessarily a managed or compliant device. It means IDaaS recognizes machine information from a previous successful authentication. Use Device Verification when the policy depends on a trusted device certificate. Device Verification requires a configured trusted certificate authority. See Configure a Trusted CA. For information about Entrust PKI products that can support certificate issuance and management, see Entrust PKI.
Authentication flow outcomes
An authentication flow defines how a user must authenticate after a resource rule applies. It specifies the supported login path for the request and, where applicable, the IDaaS authenticators required for first-factor or second-factor authentication.
After risk evaluation classifies the request as low, medium, or high risk, the resource rule uses the authentication flow or access result configured for that risk level.
Authentication flow selection must align with the login options enabled for the application. The selected authentication flow must support the login method used to start authentication. For details about login options and application support, see Manage login options.
For details about creating or reviewing authentication flows, see Create authentication flows.
Multiple resource rules
An application can have multiple resource rules. IDaaS evaluates only the enabled rules for the application and requires at least one enabled rule to allow access.
| Rule result | Access outcome |
|---|---|
| All matching rules deny access | The user is denied access. |
| A matching rule denies access with Strict Access enabled | The user is denied access even if another resource rule allows access. For example, an application has one default resource rule that applies to all users and allows access. You then create a second resource rule for a trial group that restricts access to the application. Enable Strict Access for the trial rule when a denial from that rule must override the default rule. |
| One or more matching rules allow access | The user is allowed access unless another matching rule denies access with Strict Access enabled. A denial from a rule with Strict Access disabled does not override a matching allow rule. If multiple matching rules allow access, IDaaS uses the matching allow rule that comes first alphabetically by rule name. |
Common resource rule patterns
Use these patterns as starting points when you translate an access policy into a resource rule design. The exact risk factors and authentication flows depend on the application type and tenant configuration.
| Pattern | When to use it |
|---|---|
| Baseline rule for all users | Use a broad group or no group filter to define the default authentication behavior for an application. If the rule has no risk factors, matching requests use the low-risk flow. |
| Stricter rule for privileged users | Use group targeting for administrators, operators, or other privileged users. Require stronger authentication at low risk, disable SSO, or enable strict access when needed. |
| Blocked-country or high-risk-location | Use geolocation to add risk or deny access when requests come from countries that are not allowed for the application. |
| Remembered-machine step-up | Use machine authentication to require stronger authentication on first use or when the machine signal changes, while allowing lower-friction access for recognized machines. |
| High-risk access denied | Configure risk factors and thresholds so suspicious requests reach high risk, then map high risk to Deny Access when the policy requires blocking instead of step-up. |
| Transaction-sensitive access | Use transaction risk factors when the action inside the application changes the risk, such as payment amount, transfer destination, account, operation type, or channel. |
| Fresh authentication for sensitive access | Disable Single Sign-On when users must reauthenticate for sensitive applications or sensitive user populations, even if they already have a session for another application. |
Application types and resource rules
Every application that uses IDaaS authentication requires at least one enabled resource rule. Resource rules do not have separate types, but the application type determines which rule options, risk factors, and authentication flows are available. In this context, applications include SAML applications, OIDC applications, RADIUS applications, IDaaS portals, and integrations that use the Authentication API.
When you plan a resource rule, start with the application type you are protecting.
| Application type | Resource rule behavior |
|---|---|
| SAML and OIDC applications | Can use access filters, adaptive risk evaluation, SSO behavior, and authentication flows that match browser-based sign-in. Resource rules for SAML and OIDC applications cannot use External Authentication as the First Authentication Step. |
| RADIUS applications | Support a smaller set of risk factors and authentication decisions than SAML and OIDC applications. RADIUS resource rules include only Date / Time, Geolocation, and Source IP Address risk factors. Identity Provider and Smart Login flows are not available. The authentication decisions you can select depend on whether the RADIUS application uses EAP RADIUS authentication. |
| Authentication API applications | Can use transaction contexts when the protected action inside the application changes the risk. See Modify risk-based authentication general settings. |
| IDaaS portal applications | Protect access to the User Portal and Administration Portal. IDaaS includes default portal resource rules, and you can add portal resource rules when portal access needs different behavior for specific user groups, requests, or risk levels. |
| Entrust Identity Enterprise applications | Support only the Date / Time risk factor. The available authenticators are limited by the application type. |
IDaaS portal resource rules
Resource rules for IDaaS portals define the authentication level required to access an IDaaS account. IDaaS accounts include two default portal resource rules that cannot be deleted.
| Default rule name | Resource | Description |
|---|---|---|
| User Portal - All Users | User Portal | Enables users without a role to authenticate to the User Portal of their account. |
| Administration Portal - Administrators | Entrust Identity as a Service Administration | Enables users with an administrator role to authenticate to the Administrator portal of their account. See Create and assign roles for more information. |
You can add other portal resource rules when portal access needs different authentication behavior. The special portal-related case is the Edit User Portal resource rule, which supports step-up authentication when users edit their user profile. For details, see Edit User Profile resource rule for step-up authentication.
Plan and test a resource rule
Before you create or change a resource rule, identify the policy outcome you want, then configure the rule to express that outcome. Test the rule with users and access paths that represent the real environment before you roll it out broadly.
- Which application or portal does this rule protect?
- Which users must match this rule?
- Must the rule respond to specific ACR values or domain-based Identity Provider behavior?
- Which risk factors are reliable for this application and user population?
- What happens at low, medium, and high risk?
- Should a high-risk result step up authentication or deny access?
- Can users reuse an existing SSO session, or must they reauthenticate?
- If this rule denies access, must that denial override other rules?
- Are the selected signals reliable for office networks, VPN users, remote workers, mobile users, proxies, and global user populations?
- If you use device certificates, do you have a process to issue, install, renew, revoke, and troubleshoot certificates?
- Which test users, groups, machines, IP addresses, countries, time zones, and transaction examples will verify each expected outcome?
For configuration steps, see Add resource rules, Add Access Controls, Add Risk Factors, and Add Risk Evaluation.
For help investigating unexpected access denial, see Troubleshoot resource rule access denial.
Topics in this section
Authentication flows
Built-in login flows
Authentication context
Authentication Context References (ACRs) are labels that are used by SAML or OIDC and OAuth Identity Providers to set the type of authentication that should take place to allow access. IDaaS provides a number of System ACRs, but you can also add custom ACRs. In IDaaS, ACRs are used in resource rules to determine the type of authentication required to either allow or deny access to the protected Identity Provider.
Rule creation
4 items
User Profile step-up rule
An Edit User Portal resource rule placeholder is added to configure step-up authentication rules to enforce user to perform step-up authentication when they edit their user profile.
Access denial
Use this page to identify why a resource rule denied access or did not apply the authentication behavior you expected. Resource rule evaluation depends on authentication audit events, enabled rules, access filters, risk factors, risk evaluation outcomes, authentication flows, and strict access behavior.