Skip to main content

Manage Risk-based authentication (RBA) settings

Risk-based authentication (RBA) identifies the level of risk associated with every user who attempts to authenticate to your Identity as a Service account. This feature is useful when you want your users who access Identity as a Service to 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 needs to be authenticated using RBA, Identity as a Service runs two preliminary IP address checks that determine which (if any) of the IP/Geolocation tests are performed. The preliminary checks are:

  • Expected locations Identity as a Service determines whether the user’s IP is on the expected location list.
  • Private IP addresses Identity as a Service determines whether the user’s IP is public or private.

Based on the results of the expected locations and private IP address checks, the following IP/Geolocation tests are run:

  • IP Blocklist Runs only if the preliminary tests conclude that the user’s IP address does not match one of the expected locations (the expected locations allow list applies before the IP address blocklist).
  • Country Blocklist Runs only if the preliminary tests conclude that the user’s IP address does not match one of the expected locations, and the IP address is public (since only public IP address can belong to a particular country).
  • Location History Runs only if the preliminary tests conclude that the user’s IP address does not match one of the expected locations.
  • Velocity Runs only if the user's policy setting Check Velocity is set to yes, and Identity as a Service determines that the user’s IP address is public. (Private IP addresses are of the form 10.*.*.*, 172.16.0.0 through 172.31.255.255, or 192.168.*.*. Any IP address that is not in this range is considered a public IP address.)

Based on the results of these tests and other resource rule conditions, such as transaction context conditions, the user authenticating is assigned a low, medium, or high-risk score. That score defines the level of authentication required from the user when authenticating to an application as defined by the application resource rule. See Create resource rules for more information.

The Expected Locations list contains recognized locations that your Identity as a Service users are expected to log in from. Identity as a Service provides two expected location lists:

  • System-wide expected locations list (defined in the Risk-based authentication settings).
  • A user's personal expected location list, which overrides the system-wide list when the two conflict (defined in the user's risk-based authentication settings)
    • For example, if a user authenticates from a location that is not on the system-wide list, but is on the user's personal expected location list, the location is accepted.
    • When a user logs in from a location on the Expected Location list (the system-wide list or user list), the Source IP, Geolocation and Location History / Known Location risk-based authentication tests are skipped. The tests related to the Date / Time, Machine ID, Travel Velocity, and potentially Transactions Items resource rule conditions are still performed.

The expected location list can include public and private locations.

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

  • Country
  • City Name
  • ISP name
  • IP Address
note

You do not need all of these for a useful comparison. If any of these fields are missing, comparisons are performed using the information provided. For example, if the expected location list contains an entry with just the country, it matches any location within that country. If the list contains an entry with the country and region, it matches any location within that region of the country.

Risk factors​

The following are used to determine a user's level of risk when they log into Identity as a Service:

Travel velocity​

When a user logs in, Identity as a Service converts a public IP address to location data. For a velocity test, Identity as a Service 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 velocity is greater than that allowed by the Maximum Travel Velocity value, the velocity test fails.

  • An administrator can disable the velocity test on a per-user basis.
  • No velocity test occurs when the IP address is a private address.
  • When a user authenticates to an application for the first time, that user has no location history list; therefore, the velocity test passes.

IP/Geolocation​

Identity as a Service determines the approximate geographical location of any user seeking access. Identity as a Service converts the IP address of the user into location data that includes the country, region, city, Internet Service Provider (ISP) name, latitude, and longitude.

With this data, Identity as a Service can determine if the user passes the requirements of a resource rule, for example:

  • Compare the user’s current IP address with all addresses on the IP blacklist. If a user's address is on a blacklist, the test fails.
  • Compare the user’s current location with the last location associated with the user. If the user changed locations faster than the speed defined by the Maximum Travel Velocity setting, the user fails the velocity test. For example, if the user logs in from Toronto at 10:00 a.m. and then logs in from New York a few minutes later, this indicates a likely attack, and the test fails.
  • Compare the user’s current location with the list of expected locations. If there is a match, the user passes an expected location test.
  • Compare the user’s current location with the list of locations previously associated with the user. If that location matches one on the list, the user passes a location history test.

In Identity as a Service, you can set up the following IP/Geolocation tests in the resource rule settings:

  • Source IP Address: If a user logs in from an IP address that is listed as a Deny IP Address/cidr on a resource rule's Source IP Address condition, this test fails.
  • Geo Location: If a user logs in from a country that is on a Geo Location's Deny Country List on a resource rule, this test fails.
  • Location History / Known Locations: If the user logs in from an IP address that is not in the user’s location history list, this test fails.
  • Travel Velocity: If a user logs in from two widely separated geographic locations in a suspiciously short period of time, this test fails.

The consequence of failing a test is defined by the resource rules in your account.

Device Data​

See Manage machine authenticator settings for more information.

Topics in this section​