4.5.5 Understanding Risk-based Authentication through Scenarios

The following are few example configuration to describe how you can use risk-based authentication:

Scenario 1

You want to enable two-factor authentication for a user outside the corporate network, and single factor authentication when the user is in the corporate network.

You can configure risk-based authentication in this scenario by using Risk-based Pre-Auth Class. You can determine the authentication method required for an access based on the context before the user’s identity is validated through authentication. You can choose from many authentication methods and apply them as per your security policy requirements.

For example, you can enable a simple username/password prompt when the user is in the internal network. If the user is trying to login from outside the corporate network using a known device, prompt for Advanced Authentication Framework (username/password and smartphone) authentication.

Configuration Steps:

  1. Go to Policies > Risk-based Policies > Risk Policy.

  2. Click the Create Risk Policy icon.

  3. Under Add Risk Policy, specify the following details:

    Risk 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 Pre-Authentication Class.

    • Specify Display Name.

    • Click Save.

  4. Create an IP Address rule.

    1. Under Policy Rules, click Create Rule and specify the following values:

      • Rule Name: Specify a name.

      • Rule Definitions: Select IP Address Rule.

      • Select Allow if IP Address Is in the list.

      • Specify the corporate IP Address details. For more information, see IP Address in Step 2.

    2. Click OK.

    3. If rule condition is met, then: Exit with Risk level as.

    4. Select Risk Level: Low

    5. Click OK.

  5. Create a Device ID rule.

    1. Under Policy Rules, click Create Rule and specify the following values:

      • Rule Name: Specify a name.

      • Rule Definitions: Select Device ID Rule.

      • Specify the details. For more information, see Device ID in Step 2.

    2. Click OK.

    3. If rule condition is met, then: Exit with Risk level as.

    4. Select Risk Level: Medium

    5. If rule condition is not met, add risk score: 50

    6. Click OK.

  6. Under Risk Levels, click Actions > Add Risk Level and create the following risk levels:

    • Low

      Field

      Value

      Risk Score

      Less than 50

      Risk Level

      Low

      Action

      Authenticate by using Name/Password - Basic

    • Medium

      Field

      Value

      Risk Score

      Equals to or greater than 50

      Risk Level

      Medium

      Action

      Authenticate by Advanced Authentication Framework (username/password and smartphone)

      NOTE:To enable this configuration, you must configure Advance Authentication with Access Manager. For more information, see Section 4.3.3, NetIQ Advanced Authentication.

  7. Click OK.

  8. Create an authentication method. For more information, see Configuring a Method for an Authentication Class.

  9. Create a contract. For more information, see Configuring a Contract for an Authentication Class.

  10. Assign the contract to the protected resource.

Scenario 2

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:

  1. Click Risk-based Policies > Rules.

  2. Specify a name for the rule.

  3. Select HTTP Header Rule.

  4. Specify HTTP Header Name as X-Forwarded-For.

  5. 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 Section 10.7.5, Configuring NAT Settings.

  6. Click OK.

  7. Assign the rule to a risk-policy and follow steps Step 7 to Step 9.

Scenario 3

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.

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:

  1. Go to Policies > Risk-based Policies > Risk Policy.

  2. Click the Create Risk Policy icon.

  3. Under Add Risk Policy, specify the following details:

    Risk 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 Create Risk-based Auth Class.

    • Specify Class Name.

    • Click Save.

  4. Create a Geolocation rule and a User Profile rule.

    • Geolocation Rule

      Under Policy Rules, click Create Rule and specify the following values:

      NOTE:You must configure a provider in the Geolocation user interface 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 Policy Rules, click Create 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, then: Proceed to Next Rule

      • If rule condition is not met, add risk score: 60

      • Click OK.

        To evaluate example_user_profile first, drag it up before example_geolocation in the rules list in Administration Console.

  5. Under Risk Levels, click Actions > Add Risk Level and create the following risk level:

    For more information about risk scores, see Risk Score in Table 4-5, Risk-based Authentication Terms.

    Field

    Value

    Risk Score

    Equals to or greater than 50

    Risk Level

    High

    Action

    Deny Access

  6. Click OK.

  7. Create an authentication method. For more information, see Configuring a Method for an Authentication Class.

  8. Create a contract. For more information, see Configuring a Contract for an Authentication Class.

  9. Assign the contract to the protected resource.

Scenario 4

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:

  1. Go to Policies > Risk-based Policies > Risk Policy.

  2. Click the Create Risk Policy icon.

  3. Under Add Risk Policy, specify the following details:

    Risk 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 Create Risk-based Auth Class.

    • Specify Class Name.

    • Click Save.

  4. Create a Geolocation rule and a User Profile rule as a single rule.

    1. Under Policy Rules, click Create Rule and specify the following values:

    2. Rule Name: Specify example_combination_rule.

    3. Configure the geolocation rule.

      NOTE:You must configure a geolocation provider in the Geolocation user interface for this rule to work.

      1. Rule Definitions: Select Geolocation Rule.

      2. User Location: Select Is not.

      3. 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
    4. Click Combine with to add the user profile rule.

      1. Select User Profile Rule.

      2. Under User Attributes, Select employeeType and Equals, and specify Employee.

    5. Click Combine with to add the HTTP Header rule.

      1. Select HTTP Header Rule.

      2. Specify the HTTP header Name and the specific HTTP header value that you want to search for an HTTP header.

    6. In Combination Rule Definition > Condition Group, click Assign Rules and then select user profile and geolocation rules. Select AND in Group Operator. For information about how these operators work, see Combination Rule in Table 4-5, Risk-based Authentication Terms.

    7. Click Add Condition Group and select HTTP Header Rule.

    8. Select the OR operator for Condition Group 1 and Condition Group 2.

    9. If rule condition is met, then: Allow Access and Exit Policy.

    10. If rule condition is not met, add risk score: 50

    11. Click OK.

  5. Under Risk Levels, click Actions > Add Risk Level 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 4-5, Risk-based Authentication Terms.

    • 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

  6. Click OK.

  7. Create an authentication method. For more information, see Configuring a Method for an Authentication Class.

  8. Create a contract. For more information, see Configuring a Contract for an Authentication Class.

  9. Assign the contract to the protected resource.

Scenario 5

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 more information about how to enable recording of user history, see Section 10.7.2, Configuring User History.

Scenario 6

You want to identify the 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 Section 5.4, Configuring an Example Device Fingerprint Policy.

Scenario 7

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

To watch the video explaining how to create the policy, see How to Calculate Access-related Risks by Using Current Location, Device, and Login History of a User.

Configuration Steps:

  1. Go to Policies > Risk-based Policies > Risk Policy.

  2. Click the Create Risk Policy (+) icon.

    Under Add Risk Policy, specify a name and description of this policy.

    Risk Policy Name: Specify a name.

    Policy Description: Specify the purpose of this policy.

  3. 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 more information about how to create a new class, see Adding a Risk Policy.

  4. Create a combination rule as follows:

    1. Under Policy Rules, click Actions > Create Rule, and specify a name for this rule.

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

    3. Click Combine with > Device Fingerprint Rule 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 5.2, Understanding Device Fingerprint Parameters.

    4. Click Combine with > Geolocation Rule 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.

    5. Click Combine with > Geo-Velocity Tracker Rule 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.

    6. Add a condition to prompt for an additional authentication if any of these rules fails.

      In Combination Rule Definition > Condition Group, click Assign Rules and then select all four rules. Select AND in Group Operator. For information about how these operators work, see Combination Rule in Table 4-5, Risk-based Authentication Terms.

    7. Click OK.

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

    9. Click OK.

  5. Under Risk Levels, click Actions > Add Risk Level 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.