Troubleshoot resource rule 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.

Review the following areas to troubleshoot access denial:

• Check authentication audit logs
• Check enabled resource rules
• Check access filters
• Check risk factors
• Check risk evaluation outcomes
• Check authentication flow requirements
• Check strict access and overlapping rules

Check authentication audit logs

Start with the authentication audit event for the denied sign-in. Audit event details can confirm the user, application, source IP address, authentication type, event outcome, and other request context that IDaaS evaluated.

1. Click > Dashboard. The Dashboard page appears.
2. Select Authentication.
3. Open the denied authentication event.
4. Review the event details and compare them with the resource rules configured for the application.

For details, see View and export audit logs.

Check enabled resource rules

Confirm that the application has at least one enabled resource rule that can allow access.

1. Click > Security > Resource Rules. The Resource Rules List page appears.
2. Find the application or portal resource.
3. Confirm that at least one resource rule for the resource is enabled.
4. If all rules are disabled or all enabled rules deny access, enable or create a rule that permits the intended users and requests.

Check access filters

Access filters determine whether a resource rule is eligible before IDaaS evaluates risk factors. If the request does not match the access filters, the rule does not apply to that request.

Review the following filters:

• Group. Confirm that the user is a member of a group selected by at least one enabled resource rule. If the rule has no group access filter, the rule can apply to all users who otherwise match the rule.
• Authentication Context Reference (ACR). Confirm that the request includes the expected ACR value, no ACR value, or any ACR value, depending on the filter configuration.
• Domain-based IdP. Confirm that the user matches the expected domain-based Identity Provider behavior, such as no domain-based IdP, any domain-based IdP, or a specific configured domain-based IdP.

For configuration details, see Add Access Controls.

Check risk factors

Risk factors add risk points when their configured conditions are triggered. Some risk factors can also deny access directly, depending on the risk factor and rule configuration.

Review the configured risk factors and compare them with the user's sign-in context:

• Source IP address or IP list
• Geolocation country
• Date and time
• Device certificate verification
• Location history
• Machine authentication
• Travel velocity
• Transaction rules
• External risk engine results

If a risk factor is not configured on the rule, IDaaS does not use that signal to increase risk for the rule. For example, a rule without a source IP address risk factor does not make an IP-based risk decision.

For configuration details, see Add Risk Factors.

Check risk evaluation outcomes

Risk evaluation maps the generated risk score to low, medium, or high risk. The selected risk level determines which authentication flow or access result applies.

1. Open the resource rule graph.
2. Select the Risk Evaluation node.
3. Review the Risk Weights for each configured risk factor.
4. Review the Risk Levels thresholds for low, medium, and high risk.
5. Review the authentication flow or access result connected to each risk level.
6. Use Risk Simulation to test the combination of triggered and non-triggered risk factors.

If the final risk level maps to Deny Access, IDaaS denies access even if the user matched the access filters. For configuration details, see Add Risk Evaluation.

Check authentication flow requirements

If a resource rule allows access through an authentication flow, the user must be able to complete one of the authentication paths in that flow.

Review the selected authentication flow and confirm the following conditions:

• The flow is available for the application type.
• The user has an authenticator allowed by the selected flow.
• The selected first-factor and second-factor options match the intended user experience.
• The application type supports the selected authentication options.
• Any required external Identity Provider, passkey, Smart Login, or user certificate configuration is available to the user.

For configuration details, see Create authentication flows.

Check strict access and overlapping rules

Strict access changes how a denial from one rule interacts with other rules for the same resource.

If a rule denies access and Strict Access is enabled, that denial can override another enabled rule that would otherwise allow access. Use Strict Access when a denial from a targeted rule must not be bypassed by a broader permissive rule.

When an application has overlapping rules, review each enabled rule for the same resource. Confirm which rules can apply to the user and request, and avoid overlapping rules with conflicting outcomes unless you intentionally tested that behavior.

Common causes of access denial

Use this checklist when the reason for denial is not clear.

Cause	Check
No enabled resource rule exists for the application.	Check enabled resource rules
The user does not match the group filter for any permitting rule.	Check access filters
The request does not match the ACR filter for any permitting rule.	Check access filters
The user does not match the domain-based IdP filter for any permitting rule.	Check access filters
A risk factor triggered a direct access denial.	Check risk factors
The generated risk level maps to Deny Access.	Check risk evaluation outcomes
A strict-access rule denied access and overrode another permitting rule.	Check strict access and overlapping rules
The selected authentication flow requires an authenticator or Identity Provider path that the user cannot complete.	Check authentication flow requirements
The application type does not support the selected risk factor, authentication flow, or authenticator.	Check authentication flow requirements

Next steps

After you identify the cause, update the relevant access filter, risk factor, risk evaluation threshold, authentication flow, SSO setting, or strict access setting. Test with representative users, groups, IP addresses, locations, machines, and transaction examples before you roll out the rule broadly.