Policy Selection Priority When Request Contains ACR Values

Products

• Symantec Identity Security Platform - IDSP (formerly VIP Authentication Hub)

Issue/Introduction

When a client application initiates a login request and includes an Authentication Context Class Reference (acr_values) parameter, the policy evaluation engine overrides high-priority global policies that are based on account context.

Instead of evaluating all available policies and selecting the one with the absolute highest priority, the engine limits its evaluation to policies matching the requested ACR.

Expected Behavior

A global policy with a high priority (e.g., priority 1) based on account context (such as verifying if a user is in a specific LDAP group) should trigger and take precedence over lower-priority, application-specific ACR policies.

Observed Behavior

1. A user belonging to a high-priority group initiates a login.

2. The client application passes an ACR value (e.g., acr_values=urn:example:any) in the authentication request.

3. The policy engine ignores the high-priority, context-based global policy and instead enforces the policy matching the requested ACR.

Environment

Symantec Identity Security Platform - IDSP (formerly VIP Authentication Hub)

Cause

By design in the current implementation, the policy evaluation engine handles requests containing acr_values with a specific precedence logic:

• ACR Exclusion Filter: When acr_values are present in the incoming request payload, the engine immediately filters the policy pool. Only policies with a matching ACR condition are considered for evaluation. All other policies—including global, context-based policies without an ACR condition—are excluded from the evaluation pool, regardless of how high their priority is set.

• Priority Application: Priority is only evaluated within the filtered subset of ACR-matched policies. The engine selects the policy with the highest priority from among those that match the requested ACR.

Resolution

Current Product Limitation: The described behavior is the current system design. A design enhancement is being planned for a future release to allow global, non-ACR policies to take precedence over ACR-specific policies when configured with higher priority.

Until this enhancement is released, you can use one of the following workarounds to achieve global policy enforcement:

Workaround 1: Duplicate Global Conditions inside ACR Policies

To ensure that global rules (such as LDAP group checks) are still enforced even when an ACR policy is triggered, you must append the global context conditions directly into your existing ACR-based policies.

Workaround 2: Explicitly Map ACRs to the Global Policy

If the global policy must apply to all login paths, edit the global policy to explicitly include matching conditions for all ACR values used across your applications. This ensures the global policy is not filtered out during the initial ACR-matching phase.