Use geo-velocity as a risk check
You can define user access based on speed of travel between the previous login and current login attempt.
In the Geo-velocity section, move the slider to Enabled.
Set the following:
Set Velocity Limit
Set the limit in miles-per-hour to determine access based on the speed of travel between the previous login and current login attempt.
For example, if the user logged in from Virginia, USA (point A) at 11:15 a.m. and then from London, UK (point B) at 11:45 a.m. on the same day, then the failure action kicks in.
A geo-velocity violation occurs when when the time span between the last successful login and the current login attempt is less than the travel time between the two locations.
The duration of the violation period is calculated based on the distance between the two locations defined in the Set Velocity Limit field. During the violation period, unsuccessful login attempts are not stored, even if multiple geo-velocity violations are detected.
When the end user successfully logs in within the geo-velocity limit boundaries, and if another violation is detected, the new violation period starts at the last successful login attempt.
The following are example scenarios of geo-velocity violations and successful logins for a Set Velocity Limit of 500.
Scenario 1
10:00 a.m. EST: End user successfully logs in from Virginia, USA (point A).
10:15 a.m. EST: A login attempt from London, UK (point B) is detected.
Since the Set Velocity Limit is set at 500 mph and the distance between the locations is about 3,500 miles, the violation period is valid for about 7 hours (3500 / 500) – that is, until 5:15 p.m. EST.
Scenario 2
11:00 a.m. EST: End user in Virginia, USA (point A) successfully logs in again an hour later.
11:15 a.m. EST: Another violation from London, UK (point B) is detected.
The violation period is valid until 6:00 p.m. EST, 7 hours from the last successful login event.
Scenario 3
6:15 p.m. EST: End user in London, UK with valid credentials successfully logs in since the 7-hour violation period has passed.
In order to keep track of user access history, a field on the Data tab must be mapped to the Access Histories property to the data store (LDAP, AD, etc.) with the Writeable check box as shown next:
Failure Action
Specify the adaptive authentication action SecureAuth IdP takes when the user is allowed or denied access to a protected resource (realm).
For more information about the actions and its descriptions, see the risk check action definitions.
Save your changes.