search cancel

Disabled Remember Device but no second factor after that in VIP and Netscaler Integration

book

Article ID: 257248

calendar_today

Updated On:

Products

VIP Service

Issue/Introduction

We are configuring Load Balancing Gateway for Citrix remote access and 2FA.

We disabled the remember device option as requested by Broadcom team but even after that we do not see second factor being asked but users are directly logged in and Radius logs shows authentication successful.

Environment

Release : 1.0

Resolution

This behavior is observed because the Intelligent Authentication is enabled at the VIP manager account level. See screen shot below for reference.

A summary of IA operation is:

IA has three engines, a Rules Engine, a Behavior (learning) engine, and a Device engine.  They function as follows:

Rules Engine: Match against various configurations and data feeds to determine if a transaction is risky (e.g. a list of risky IPs or risky countries).

Behavior Engine: Match against past transactions for a user to see if the user behavior appears to be unusual (e.g. new user, the user logging in with elements of their user agent string (e.g OS or Browser version) which we have not seen before, the user logging in from a location very distant from a prior login location within a short period, etc).  Initially, when an unusual behavior is triggered, we will treat the transaction as risky, over time as we see more repetitive behavior from the user and we know that the prior similar behavior was not risky (because they passed MFA prompts regarding it), then we start to treat that behavior as not risky.

Device Engine: This provides a fingerprint stored on a device.  If we see a login without a fingerprint (unrecognized device) then the login will be treated as risky.  If we subsequently receive a DenyRisk call with a request to remember the device on our server and the customer also makes a JavaScript writeTag() call to persist the fingerprint on the device then the device will be remembered (this process can be automated by the VIP javascript inclusion on the customer's login page).  Once a device is remembered, we will not treat the device as risky.

The IA system collates the risk evaluations of its individual engines.  If the risk contribution of each of the engines results in a risk score below the risk threshold configured for the customer account, then the transaction will be treated as non-risky.  

If the customer integrates via VIP SOAP APIs, then can evaluate the IA result and decide what they wish to do based on the result (it could be an MFA step-up auth, or a request to call a call center for verification, etc).  

If the customer integration uses VIP JavaScript, which will automate what happens when IA returns a risk evaluation result.  In such a case:

When there is a risky transaction detected, an MFA step-up (e.g. a push message to the user's phone) will occur.
If the transaction is evaluated as non-risky, then it will be judged that there is no need for MFA step-up authentication, (the user will not receive a push message to the phone), and the user will be granted access to the requested resource (e.g. logged into the secure site). 
IA itself is treated as an authentication factor, so if authentication with it passes (IA returns a non-risky result), there is no need to try to continue with additional authentication (such as a push message).

Attachments