Skip to main content

Manage risk-based authentication (RBA) settings

Risk-based authentication (RBA) evaluates the risk level of each user who attempts to authenticate to your IDaaS account. This feature helps you determine whether users should be:

  • Immediately accepted.
  • Given an extra authentication challenge.
  • Denied access based on their apparent level of risk.

The RBA settings and the resource rules for the application work together to define the level of authentication required to access the application. See Create and manage resource rules for more information.

note

Risk-based authentication cannot be used for RADIUS applications.

How risk-based authentication works​

When a user authenticates with RBA, IDaaS runs two preliminary IP address checks to determine which IP/geolocation tests to perform:

  • Expected locations. IDaaS checks whether the user's IP address is on the expected locations list.
  • Private IP addresses. IDaaS checks whether the user's IP address is public or private.

Based on the results of these preliminary checks, IDaaS runs the following IP/geolocation tests:

  • IP Blocklist. Runs only if the user's IP address does not match an expected location. The expected locations allow list is evaluated before the IP blocklist.
  • Country Blocklist. Runs only if the user's IP address does not match an expected location and the IP address is public, because only public IP addresses map to countries.
  • Location History. Runs only if the user's IP address does not match an expected location.
  • Velocity. Runs only if Check Velocity is set to yes and the user's IP address is public. Private IP addresses are 10.*.*.*, 172.16.0.0 through 172.31.255.255, and 192.168.*.*. Any address outside these ranges is considered public.

Based on these test results and other resource rule conditions, such as transaction context, IDaaS assigns the user a low, medium, or high risk score. This score determines the authentication level required by the application resource rule. For more information, see Create and manage resource rules.

The Expected Locations list contains locations that IDaaS users are expected to sign in from. IDaaS provides two expected location lists:

For example:

  • If a location is not on the system-wide list but is on the user's personal list, the location is accepted.
  • If a user signs in from a location on either expected locations list, the Source IP, Geolocation, and Location History / Known Location tests are skipped. Tests related to Date / Time, Machine ID, Travel Velocity, and potentially Transaction Items resource rule conditions still run.

Expected locations can include public and private locations.

Each entry for a public address in an expected locations list can include one or more of:

  • Country
  • City name
  • ISP name
  • IP address
note

You do not need all fields for a useful comparison. If any fields are missing, IDaaS compares using only the information provided. For example, an entry with only a country matches any location in that country. An entry with country and region matches any location in that region.

Risk factors​

The following are used to determine a user's level of risk when they sign in to IDaaS:

Travel velocity​

When a user logs in, IDaaS converts a public IP address to location data. For a velocity test, IDaaS compares the current user location data to the most recent location data in the user's location history list by following these steps:

  1. Compare the latitude and longitude coordinates of the current location and most recent location, and calculate the distance between them.
  2. Compare the current time with the timestamp of the most recent location, and calculate the difference.
  3. Use the distance and time to calculate the velocity required to travel this distance in the given time.

If the calculated velocity exceeds the Maximum Travel Velocity value, the velocity test fails.

  • Administrators can disable the velocity test per user.
  • The velocity test does not run when the IP address is private.
  • The velocity test passes when users authenticate to an application for the first time because no location history exists yet.

IP/Geolocation​

IDaaS determines the approximate geographic location of users requesting access. It converts the user IP address into location data, including country, region, city, Internet Service Provider (ISP) name, latitude, and longitude.

With this data, IDaaS can determine whether users pass resource rule requirements. For example, IDaaS can:

  • Compare the user's current IP address with the IP blocklist. If there is a match, the test fails.
  • Compare the user's current location with the most recent location associated with the user. If the user appears to have moved faster than the speed defined by Maximum Travel Velocity, the velocity test fails. For example, a sign-in from Toronto at 10:00 a.m. followed by a sign-in from New York a few minutes later indicates likely risk.
  • Compare the user's current location with the expected locations list. If there is a match, the expected location test passes.
  • Compare the user's current location with locations previously associated with the user. If there is a match, the location history test passes.

In IDaaS, you can configure the following IP/geolocation tests in resource rule settings:

  • Source IP Address. This test fails if a user signs in from an IP address listed in Deny IP Address/cidr under a resource rule’s Source IP Address condition.
  • Geo Location. This test fails if a user signs in from a country listed in a resource rule’s Geo Location Deny Country List.
  • Location History/Known Locations. This test fails if a user signs in from an IP address that is not in the user’s location history list.
  • Travel Velocity. This test fails if a user signs in from two widely separated locations in a suspiciously short period.

The action taken when a test fails is defined by your account’s resource rules.

Device Data​

See Manage machine authenticator settings for more information.

Topics in this section​