Manage risk-based authenticator 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

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.

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:

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

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:

– 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.

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

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.

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

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:

a. Compare the latitude and longitude coordinates of the current location and most recent location, and calculate the distance between them.

b. Compare the current time with the timestamp of the most recent location, and calculate the difference.

c. 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.

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.

Manage Risk-based authentication (RBA) settings

How risk-based authentication works