The following are few example configuration to describe how you can use risk-based authentication:
Scenario: Calculating Risk Based on the Device Type
Scenario: Calculating Risk Based on the Location from Where an Access Request Originates
Scenario: Calculating Risk Based on the HTTP Header Value
Scenario: Evaluating the Grant Permissions using the Historical Access Data
Scenario: Calculating Risk Using Device Fingerprinting
Scenario: Determining an Improbable Travel Event
Scenario: Calculating Risk Based on the Device Type
You want to configure an authentication mechanism or an additional authentication mechanism based on the type of the device.
You can configure risk-based authentication in this scenario by using Risk-based Pre-Auth Class. You can create a risk rule to choose an authentication mechanism or an additional authentication mechanism based on the type of device used by a user.
For example, if a user is logging in from a mobile device, you can prompt the user to provide an additional authentication such as SMS or One-Time Password based authentication after the user is authenticated.
You can define an HTTP Header rule by using a user-agent property such as Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_0) to verify whether the request is from a mobile.
Configuration Steps:
Click Risk-based Policies > Risk Rules > Plus icon.
Specify a name for the rule.
Select HTTP Header Rule.
Specify HTTP Header Name as User-Agent.
Select Contains in HTTP Header Value and specify Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_0).
NOTE:You must configure NAT settings for this rule to work. See Configuring NAT Settings.
Click Save.
Assign the rule to a risk-policy and follow steps Step 7 to Step 9.
Scenario: Calculating Risk Based on the Location from Where an Access Request Originates
You want to grant access only to employees. You want to deny access for any request from a specific region even if the user is an employee of your organization. you can create a policy to identify the following conditions and calculate the risk score for each condition:
Access request by an employee, not from a specific location
Access request by an employee from a specific location
Access request by a person who is not an employee
This scenario requires to create two separate rules: one for geolocation named example_geolocation and another for user profile named example_user_profile.
You can configure risk-based authentication for this scenario by using Risk-based Auth Class.
Configuration Steps:
On the Home page, click Policies > Risk-based Policy.
Click the Plus icon.
Under New Policy, specify the following details:
Policy Name: Specify a name.
Policy Description: Specify the purpose of this policy.
Assign Policy To: Select Identity Server cluster and then configure an authentication class.
Select New Risk-based Auth Class.
Specify Class Name.
Click OK.
Create a Geolocation rule and a User Profile rule.
Geolocation Rule
Under Rule Evaluation Order > Plus icon > Add New Rule and specify the following values:
NOTE:You must configure a Geolocation provider for a geolocation rule to work.
Rule Name: Specify example_geolocation.
Rule Definitions: Select Geolocation Rule.
User Location: Select is not.
Specify the following geolocation details of the region which you want to deny all login requests from:
- Country Code
- State Name
- State Code
- City Name
- Zip Code
- Metro Code
- Area Code
- Region Code
- Region Name
If rule condition is met, then: Allow Access and Exit Policy
If rule condition is not met, add risk score: 60
Click OK.
User Profile Rule
Under Rule Evaluation Order, click Plus icon > Add New Rule and specify the following values:
Rule Name: Specify example_user_profile.
Rule Definitions: Select User Profile.
Select employeeType.
Select Equals.
Specify Employee.
If rule condition is met: Click Next and then: Proceed to Next Rule
If rule condition is not met, add risk score: 60
Click Finish.
To evaluate example_user_profile first, drag it up before example_geolocation in the rules list in Administration Console.
Under Risk Levels, click Plus icon and create the following risk level:
For more information, see
Risk Score
in Table 6-1.Field
Value
Risk Score
Equals to or greater than 50
Risk Level
High
Action
Deny Access
Click Save.
Create an authentication method. See Configuring a Method for the Risk-based Authentication Class.
Create a contract. See Configuring a Contract for the Risk-based Authentication Class.
Assign the contract to the protected resource.
Scenario: Calculating Risk Based on the HTTP Header Value
If the user is an employee and is not located in a specific region, grant the access. If the user is an employee, but accessing from a specific region, deny the access. If the user is an employee and accessing from the specified location, but the HTTP header contains a specified email ID, grant the access.
You can configure a risk policy for this scenario by using the combination rule. A combination rule assesses more than one parameter to validate an authentication request from a user.
The rule must assess the user profile and geolocation first and consider the HTTP header condition only when the first condition evaluation fails.
You can configure risk-based authentication in this scenario by using Risk-based Auth Class.
Configuration Steps:
On the Home page, click Risk-based Policies > Risk Policy.
Click the Plus icon.
Under Add Risk Policy, specify the following details:
Policy Name: Specify a name.
Policy Description: Specify the purpose of this policy.
Assign Policy To: Select Identity Server cluster and then configure an authentication class.
Select Risk-based Auth Class.
Specify Class Name.
Click OK.
Create a Geolocation rule and a User Profile rule as a single rule.
Under Policy Rules, click Create Rule and specify the following values:
Rule Name: Specify example_combination_rule.
Configure the geolocation rule.
NOTE:You must configure a geolocation provider in the Geolocation user interface for this rule to work.
Rule Definitions: Select Geolocation Rule.
User Location: Select is not.
Specify the following geolocation details of the region which you want to deny all login requests from:
- Country Code
- State Name
- State Code
- City Name
- Zip Code
- Metro Code
- Area Code
- Region Code
- Region Name
Click Plus icon in Rule Definitions to add the user profile rule.
Select User Profile Rule.
Under User Attributes, Select employeeType and Equals, and specify Employee.
Click Plus icon in Rule Definitions to add the HTTP Header rule.
Select HTTP Header Rule.
Specify the HTTP header Name and the specific HTTP header value that you want to search for an HTTP header.
In Combination Strategy, click the Edit icon > Plus icon and then select user profile rule. Click Plus icon again and select geolocation rule, see
Combination Rule
in Table 6-1.Click Plus icon and re-click Plus icon and select HTTP Header Rule.
Select the OR operator for Condition Group 1 and Condition Group 2.
If rule condition is met, then: Allow Access and Exit Policy.
If rule condition is not met, add risk score: 50
Click Finish.
Under Risk Levels, click Plus icon, and create the following risk levels:
You can define actions for a risk score or for a range of risk score. When evaluation of all conditions in a risk policy fail, the action is taken based on the accumulated risk score. For more information, see
Risk Score
in Table 6-1.Low
Field
Value
Risk Score
Less than 30
Risk Level
Low
Action
Allow Access
Medium
Field
Value
Risk Score
Between 30 and 50
Risk Level
Medium
Action
Authenticate using Trust levels
High
Field
Value
Risk Score
Equals to or greater than 50
Risk Level
High
Action
Deny Access
Click Save.
Create an authentication method. See Configuring a Method for the Risk-based Authentication Class.
Create a contract. See Configuring a Contract for the Risk-based Authentication Class.
Assign the contract to the protected resource.
Scenario: Evaluating the Grant Permissions using the Historical Access Data
You want to store the details of login attempts in the configured history databases and take actions based on these details in subsequent login attempts.
While configuring risk-based authentication, you can determine if you want to save the history details and the number of days for which history to consider for evaluation of the authentication attempt.
For example: Let us assume that you have enabled recording of history details and have specified that the history of last 10 days are used for evaluation before granting or denying access. If the user logs in from a different geolocation, additional authentication is requested as the risk is high. The risk evaluation details are stored in the database. Next time the user logs in from the same geolocation, the historical details for the last ten days are checked to see if there are details about a login attempt from the same geolocation. As the geolocation details exist in the database, the user is granted access without being prompted for additional authentication.
You can enable recording of user history only for a risk policy that uses Risk-based Auth Class.
For information about how to enable recording of user history, see Configuring User History.
Scenario: Calculating Risk Using Device Fingerprinting
You want to identify characteristics or fingerprints of devices users use for login. The device can be a desktop, a laptop, or a mobile device. You want this information to achieve the following activities:
Uniquely identify users’ devices used in login attempts
Use the device identification details in evaluating risks associated with a login attempt and decide the action based on the risk.
You can configure a risk policy for this scenario by using the Device Fingerprint rule. The Device Fingerprint rule enables you to identify user devices previously used for access. A fingerprint can be imprinted on the device itself or stored to the risk database. In pre-authentication scenarios, the device fingerprints consist of the device characteristics. In post-authentication scenarios, the device fingerprints consist of the device characteristics and user identifier.
For example, when a user logs in the first time through a laptop, the user needs to provide an additional authentication. After the successful additional authentication, a device fingerprint is computed and stored either in the device (without any user information) or in the database (tied to the user). If the rule is configured for a pre-authentication scenario, the details are stored in the browser cache on the device. For a post-authentication scenario, you can configure to save these details in the browser cache or a risk database.When the user logs in next time, the device fingerprint of this device is computed and matched with the stored values. If the value does not match, the user is asked for additional authentication or a risk is added to the session.
For an example configuration, see Configuring an Example Device Fingerprint Policy.
Scenario: Determining an Improbable Travel Event
You want to configure a policy to restrict the HR portal access beyond working hours. You are also concerned about bot attacks and unusual suspicious access requests from throughout the world. This policy should prompt for an additional authentication to the user if the user meets any one of the followings conditions:
The device is not recognized
A login attempt is made from a different geolocation than the user’s registered location
An unrealistic consecutive login attempt is made within a short time from a very far location than the user’s last login location. For example, a user logs in at 4 PM MST in the USA. A login is requested from the same user account at 5 PM MST from another country, which cannot be reached within an hour.
To meet these requirements, create a policy and configure the following rules as a combination rule:
User Time of Login: To verify the login time and restrict the access beyond office hours.
Device Fingerprint: To recognize the device.
Geolocation: To recognize the location of login.
Geo-Velocity Tracker: To determine the velocity from the last login time and to help prevent man-in-the-middle, brute force, and DDoS attacks.
Configuration Steps:
On the Home page, click Risk-based Policies > Risk Policy.
Click the Plus icon.
Under Add Risk Policy, specify a name and description of this policy.
Policy Name: Specify a name.
Policy Description: Specify the purpose of this policy.
Select an Identity Server cluster in Assign Policy To and select an authentication class that will use this policy. You can also create a new class here.
For information about how to create a new class, see Adding a Risk Policy.
Create a combination rule as follows:
Under Rule Evaluation Order, click Plus icon > Add New Rule, and specify a name for this rule.
Select User Time of Login Rule under Rule Definitions and specify the following values:
User Time of Login: is
Day: Monday to Friday
Time: 9 AM to 5 PM
Click Plus icon in Rule Definitions, and specify the following values:
Valid for (in days): 30
Store Fingerprint in: Browser
Parameter Settings: Keep the default parameters or select the required ones. See Section 6.10.2, Understanding Device Fingerprint Parameters.
Click Plus icon in Rule Definitions and specify the details of the region which you want to accept all login requests from without additional authentication.
For example, if you select the is condition and specify USA as the Country Code, Access Manager will prompt for additional authentication to all users who try to login from any other country.
Click Plus icon in Rule Definitions and specify the following details:
Specify the interval in hours after which you want to check the user’s location.
Select the Negate Results option.
Add a condition to prompt for an additional authentication if any of these rules fails.
In Combination Strategy, click the Edit icon > Plus icon and then select all four rules. Select AND in Group Operator. For information about how these operators work, see
Combination Rule
in Table 6-1, Risk-based Authentication Terms.Click Save > Next.
In Add Rule to Policy, specify the following values:
If rule condition is met, then: Allow Access and Exit Policy.
If rule condition is not met, add risk score: 10
Click Finish.
Under Risk Levels, click Plus icon and create the following risk level:
Field
Value
Risk Score
Greater than or Equal to 10
Risk Level
Medium
Action
Additional Authentication > X509
This policy evaluates all four rules and if any rule fails, the user is prompted for an additional X509 authentication.
