VIP Authentication Hub - Question about resolving Risk rules when multiple conditions met

Products

• VIP Authentication Hub

Issue/Introduction

We have rules applied on one of our application, which executes different authentication flows, based on the returned risk from a custom risk engine. We want to define a rule, to exclude a test user from a risk analysis. This means, only the test user needs to be put through a different authentication flow.

When we just add the rule for a test user, it has no effect. We need to explicitly exclude the same user from the rest of the rules.

The policy documentation: https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/vip-authentication-hub/2022-Oct/Using/Management-APIs/PolicyManagement.html#concept.dita_307ab17a-0116-4fd8-950c-eec65795a8d1_principal

explains that a principal condition will be triggered, when there is a match, but it does not specify the hierarchy/order or anything about the rules, when another more generic rule matches.

We need to understand how the rules are applied, when there are multiple matches. Is it possible to exclude users/groups and put them into different authentication flows?

Environment

Release : Oct.04

Resolution

VIP Authentication executes all the rules defined across all the policies at a tenant level. There is no order or hierarchy of how the rules would be executed by the policy engine. Rule output of all the matched rules will then be consolidated to get the final set of authentication obligations. To have a different authentication flow for certain users (e.g., auhm11) and groups (e.g. admin) you should Have generic rules that excludes the certain users and groups (i.e., Principal not condition for users/groups)

Examples of matching rules consolidation logic

Scenario1:
----------
Matched Rule1 has obligations PASSWORD:1, PUSH:1, SMSOTP:2, MOBILEOTP:3 and  effect = "allow"
Matched Rule2 has obligations returns PASSWORD:1, SECURITYKEY:2 and effect = "allow"

Result: Authentication obligations will be PASSWORD:1, PUSH:1, SMSOTP:2, SECURITYKEY:2, MOBILEOTP:3Scenario2
---------
Matched Rule1 has obligationsPUSH:1, SMSOTP:2 and  effect = "allow"
Matched Rule2 has no obligations and effect = "deny"

Result: Authentication obligations will be none because one of the rules has an effect="deny" and this stops authentication flow with status AUTH_DENIED