This article describes how geo-location data can be used in the Curity Identity Server to customize the authentication process such as filtering, enabling or disabling certain authenticators or triggering an action like requesting authentication with an additional factor.
When talking about multi-factor authentication many readers may be familiar with the following three authentication factors:
- Knowledge factor - something you know
- Possession factor - something you possess
- Inherence factor - something you are
The Curity Identity Server features an additional factor:
- Location factor - the place where you are
With the help of the location, an administrator can filter, enable or disable certain authentication methods, allow or deny a login based on the user’s country. However, making use of the Curity Identity Server’s flexible authentication pipeline basically any action can be taken on events such as when a user enters a new country, changes the country or performs an impossible journey between two logins. Consequently, Curity Identity Server enables companies to maximize compliance with security policies and improve user experience.
Authenticator Filters are technically not a multi-factor feature since they do not enforce an additional factor. However, they are still very useful when it comes to facilitating security policies. When enforcing a policy, support your users in following the policy and help them to get it right from the beginning. The Curity Identity Server supports different types of authenticator filters that allow defining rules for which authentication method a user should be prompted for or not.
A filter of type
geo-country specifies which authentication methods (authenticators) will be listed based on the country which the user tries to login from. In this way you can customize the options for a certain country or list of countries. Since authenticators are not bound to one single authentication method but can contain a whole pipeline of other factors and actions,
geo-country-filters are the perfect tool for listing only multi-factor options for a login from abroad, for instance.
Keep in mind that filters are only a UI feature. It is possible for users to bypass the filter by manipulating the request and pointing to a specific authentication method. Actually, a user may unintentionally bypass the filter by saving a bookmark to a certain authentication method. Filters still improve the user experience by supporting users in following the policies.
As we stated above filters are a good to guide users, but they do not provide any security. To actually implement a security policy and enable or disable authentication methods for a certain country or list of countries independent of the visibility to the user, you will have to configure geo-location settings for each authenticator.
There are two types of configurations options:
- Configure a white-list and enable the authenticator only for logins from the listed countries.
- Configure a black-list and make sure the authenticator will not be available for users located in any of the listed countries.
In contrast to filters the Curity Identity Server will raise an error when the user selects an authentication method that is not available in the country. However, Authenticator Filters and Geographic Filtering on authenticators level complete an enforcement of a security policy.
Did you know?When enabling Geographic Filtering on authenticators you add a location factor to the authentication. Users have to be in a certain country and provide the correct credentials for the authentication to succeed. By definition, this is a multi-factor authentication though transparent to the user.
Actions are a very powerful tool. They can be chained together for customized and complex workflows. The Curity Identity Server ships with a set of predefined actions but is not limited to them. The geo-location related actions are:
- Allow Deny Country
- New Country
- Changed Country
- Impossible Journey
This action is very similar to the Geographic Filtering that you can configure per authenticator. It allows you to fail an authentication based on the user’s location. There is however a slight but important difference between the action and the setting on the authenticator. Actions are executed after the main authentication succeeded meaning the user has to enter the credentials and authenticate before the action is triggered. Whereas the Geographic Filtering configured for an authenticator is enforced when the authenticator gets selected that is before the user enters the credentials.
What are the benefits of the
Allow Deny Country-action if there is already another feature with the same result and better user experience? The answer lies within the strength of actions: Actions can be chained. As a result there can be other actions before and after
Allow Deny Country that allow you to customize your workflow and enable you to perform tasks such as logging or sending notifications. To conclude, there is no benefit if you use the action alone, but it is inevitable if you need to adapt the workflow with other actions.
Add these actions to your authenticator to determine if a user logged in from a different country than the last time. The main difference between
New Country and
Changed Country is that the latter triggers every time the country differs between logins whereas the first only flags if the country changed to a location that the user has never logged in from before thus the user logs in from a new country.
The result of the action is a simple subject attribute of type boolean, i.e. the attribute will be
True if the country is different from the last time the user logged in or if the user logged in from a new country respectively. This result can then be picked up by other actions such as
Multi Factor Condition. In that way another factor for multi factor authentication can be requested.
Sometimes it is not enough to only know if the country changed, but you may also want to know if the change is reasonable in the meaning that if it is feasible to log in from the current country concerning the previous location and time between the logins. The action
Impossible Journey defines the parameters for reasonable travel time. This action will flag if the user travels too fast from one country to another between two logins thus indicates suspicious activity.
The result is a subject attribute that contains a boolean value indicating the detection of an impossible journey.
True means that an impossible journey has been detected according to the settings. The default speed is 250 km/h.
The Curity Identity Server uses an offline database for retrieving geo-location data. This means there is no need for any web service calls to resolve a user’s location. However, the geo-location feature is subject of an additional license. As a result though the database is provided by Curity it must be downloaded separately. As part of the download you are required to accept additional Terms and Conditions. Geo-location data can change, and you are obliged to update the database on a regular basis. Even though the accuracy of the geo-location data provided by Curity is limited, do not use the data provided to you to track individual persons!
Geo-location data is based on the user’s IP address. When using a reverse proxy to protect the Curity Identity Server it must forward the user’s IP address and be white-listed by the Curity Identity Server for the server to be able to resolve the country. See Configuration Guide for details on white-listed proxies.
Geo-location data allows you to refine the implementation of your security policies by adding another factor to your authentication. Actions and filters enable you to customize the workflow based on the user’s country. The Curity Identity Server simplifies the implementation for an authentication process that takes local preferences and regulations into consideration.
Let’s Stay in Touch!
Get the latest on identity management, API Security and authentication straight to your inbox.