4.5.3 Features of Risk-based Authentication

Risk-based authentication provides the following features:

  • Risk identifications by using rule definitions: Risk-based authentication helps you define rules that are classified as follows:

    Rule Category

    Rule Description

    IP Address

    Use this rule to define a condition to track login attempts from an IP address, range of IP addresses, an IP subnet range, or a list of IP addresses from an external provider.

    For example: If you are aware that login attempts from a specific range of IP addresses are riskier, you can define a rule to watch for such login attempts. When a request originates from the specified IP address range, you can prompt for additional authentication.

    IMPORTANT:It is not possible to create a rule by using the IP subnet condition. Instead you can use the IP address range condition to select a range of IP addresses in the rule.

    NOTE:The IP address may not be the clients IP address, but that of an intermediate device. In such a case, you need to use the X-Forwarded-For to determine the IP address of the workstation

    Cookie

    Use this rule if you want to track login attempts from a browser-based application that has a specific cookie value or name.

    For example: Consider a scenario where you have a financial application and a user accessing this application has cookies stored on the browser. If the cookie has a specific value or name, the user can be granted access without additional authentication. But, if the user accessing the application has no cookies stored, then you can request additional authentication to validate the user.

    HTTP Header

    Use this rule to track the HTTP header of requests based on the name or the value contained in the HTTP header.

    For example, if you want to track HTTP requests containing custom HTTP header information, you can define the action to be performed on evaluation of this rule.

    User Last Login

    This rule creates a cookie in browser after a successful step up authentication. Subsequent login verifies this cookie. Use this rule to define the duration for which the cookie is valid. On expiry of the specified duration, the user is prompted for additional authentication.

    For example, this rule can be used to evaluate if the user is logging in by using a device that was used earlier for a login attempt. You can define the risk level and also request additional authentication, as necessary.

    User Profile

    Use this rule to define a condition based on the LDAP attribute of the user.

    For example, you can define a rule to deny access if the employee ID of the user matches a specific string.

    User Time of Login

    Use this rule to define a condition based on the user’s attempts to login at a specific time.

    For example, if the usual login pattern for an employee is between 9 a.m. to 5 p.m., you can define a rule that takes an action if the login pattern differs from the observed pattern.

    Device Fingerprint

    Use this rule to uniquely identify and control the type of device from which a user could log in to the applications secured by Access Manager.

    When a user log in the first time from a device and device fingerprint is not available for that device, a risk is added and Access Manager can be configured to prompt for an additional authentication. After the first successful authentication, a device fingerprint is calculated based on the parameters configured in the Device Fingerprint rule.

    In subsequent login attempts, Access Manager verifies device fingerprint parameters configured in the Device Fingerprint rule.

    In the current implementation, you cannot add more than one Device Fingerprint rule per Access Manager setup.

    For more information about device fingerprinting, see Section 5.0, Device Fingerprinting.

    Device ID

    (Deprecated)

    From Access Manager 4.3 onwards, this rule has been replaced with the Device Fingerprint rule. If you have configured any Device ID rule in Access Manager 4.1 or 4.2, this rule will be listed as deprecated after upgrading to Access Manager 4.3 or later.

    External Parameters

    Use this rule to consider inputs from external providers to evaluate the risk associated with a login attempt.

    For example, if a user is already authenticated with an external authentication provider, Access Manager receives authentication details from that provider such as the method used for the authentication. Access Manager can use this information for evaluating the risk.

    NOTE:To use this rule, you must create a custom authentication class to retrieve details from an external provider. For more information, see User Information Methods and Creating a Custom Rule Class in the NetIQ Access Manager 4.5 SDK Guide.

    Geolocation

    Use this rule to track login attempts based on the geographical location of the user. You can track details ranging from a wide area such as a country or to a smaller area such as a region.

    For example, you can use this rule to introduce additional authentication attempts in the following scenarios:

    • when a user logs in from a specific geolocation

    • when a user accessing from a specific gelocation to be considered as a valid user and be granted access without further checks

    Geo-Velocity Tracker

    Use this rule to check user’s current time and location compared to the time and location of the last login. Access Manager supports only country as the location for this rule.

    The last login details are picked from the history database. If the time between the last successful login and the current login attempt is less than the shortest possible travel time, you can configure the following actions:

    • Prompt for an additional authentication

    • Deny access

    For example, a user logged in at 2 p.m. IST in Bangalore and tries to re-login at 5 p.m. IST from Hong Kong. Reaching Hong Kong in three hours from Bangalore is not possible. To mitigate such malicious login attempts, you can configure a policy using this rule to either ask for an additional authentication or deny the access.

    For more information, see Scenario 7.

    Custom Rule

    Use this rule to define your own custom rules by using a custom Java authentication class. This is useful in deployments where the existing rules do not meet the requirements.

    For example: Consider a situation where the HTTP header contains the company name in an encoded format. You can create a custom rule to decode the HTTP header and retrieve the name of the company. This value can later be compared to an LDAP attribute, and based on the results, action to be taken.

    For more information about creating a custom class, see the NetIQ Access Manager 4.5 SDK Guide.

  • Risk Engine: The risk engine evaluates and assesses rules, including risk score and risk level processing. It ensures that the risk associated with the login attempt is considered during authentication.

  • History: Each time a user makes a login attempt, the rules are evaluated and then based on the analysis, the user is either granted access or additional authentication is requested. These details are stored in an external database. The details recorded in history are:

    • Risk score after evaluation of the rule

    • Last login time of the user

    • Geolocation details such as city or country

    • IP address of the client

    • Risk level details after evaluation of the rule

    • Details of additional authentication

    • Details of error messages displayed during risk assessment

    • Time zone details

    It is recommended to configure Oracle, MySQL, or Microsoft SQL Server as the database to store the risk-based authentication data. Built-in Data Store is not recommended in a production environment.

  • Risk Policies for risk mitigation: A risk policy is a group of risk rules. A rule must be assigned to a risk policy for functioning. The risk policy was called rule group in Access Manager 4.1.

  • Authorization policies for protected resources: You can define a condition group as part of the authorization policy that uses the risk score from Identity Server to protect a resource. This provides an additional level of security for your environment. For more information, see Section 10.7.6, Configuring an Authorization Policy to Protect a Resource.

  • Continuous authentication during an application access: You can reevaluate the risk of an application access request when a user’s contextual parameters, such as IP address or location, get changed. In such scenarios, Access Manager can prompt the user to re-authenticate or to perform second-factor authentication.

    To configure this feature, refer to the following information:

  • Risk score and risk levels validation utility: After configuring a risk policy and corresponding scores and actions, you can use the Validate utility to emulate the total risk score and the action in event of rule failure. The validation result provides the total risk score and action. Based on the result, you can adjust the risk score and risk levels. For more information, see Understanding How to Use the Validate Tool to Emulate Total Risk Score and Risk Levels.

  • Risk Rule Validation Utility: This utility helps you determine the best way to implement risk levels and actions for your business needs. See Understanding How To Use the Risk Rule Validation Utility To Troubleshoot Rule Configuration.

  • Cumulative Scoring: You can configure to add the risk score of the current session while evaluating contracts.

    For example, assume that you have configured two contracts, Contract A and Contract B. Contract A contains both PreAuthRiskBasedAuthenticationClass and RiskBasedAuthClass (post authentication). In this case, cumulative scoring is enabled in RiskBasedAuthClass. When Contract A is executed, RiskBasedAuthClass considers the risk score calculated by PreAuthRiskBasedAuthenticationClass.

    Contract A is configured with the following two risk-based methods:

    • A_RiskMethod1, which uses a PreAuthRiskBasedAuthenticationClass that in turn uses a risk policy A_SamplePolicy1.

    • A_RiskMethod2, which uses a RiskBasedAuthClass that in turn uses a risk policy A_SamplePolicy2.

    For an arbitrary request, A_RiskMethod1 and A_RiskMethod2 calculate risk scores 100 and 150 respectively. As RiskBasedAuthClass has cumulative scoring enabled, total risk score calculated at the end of Contract A execution is 250.

    Contract B is configured with a method named B_RiskMethod. B_RiskMethod uses a RiskBasedAuthClass that in turn uses a risk policy named B_SamplePolicy. The risk score associated with this policy is 75. If evaluation of Contract B fails, 75 is returned as the risk score. If cumulative scoring is enabled, the final risk score of the session is 250 (risk score of Contract A) + 75 (risk score of Contract B) = 325. If cumulative scoring is not enabled, risk score is 75

  • Risk Score Reduction After a Successful Additional Authentication: The Reduction option enables you to reduce the risk score by a specified value after a successful strong additional authentication.

    For example, Assume you want to reduce the risk score by 100 after a successful additional authentication. You have configured to prompt for an additional authentication when the risk score is more than 200. You have configured an authentication class with a risk policy that includes the following rules:

    • IPAddressRule: If this rule fails, the risk score is 125

    • HTTPHeaderRule: If this rule fails, the risk score is 150

    • UserProfileRule: If this rule fails, the risk score is 200

    Specify 100 in Reduction. For an arbitrary request, IPAddressRule and HTTPHeaderRule have failed and the effective risk score is 275. The user will be prompted for an additional authentication. If this authentication succeeds, the risk score becomes 175. If you have configured to share the risk score, the reduced risk score is shared. If you have enabled recording user history, the reduced value is logged.

    If the risk score value is less than one after reduction, risk score will be considered as zero.

  • Using External Parameters in Risk Assessment: The External Parameters Rule enables you to consider inputs from external providers in evaluating the risk associated with a login attempt.

    For example, if a user is already authenticated with an external authentication provider, Access Manager can receive authentication details such as the authentication type, IP address, and location of the user from that provider. Access Manager can then use this information for evaluating the risk.

    You can configure to retrieve the input based on multiple parameters. Assume, you want to get the input if the user is from US and the method used to authenticate is Kerberos. Also, the user must not be using a device with the anti-virus software version 1.1.0.99. In this scenario, the configuration is as follows:

    1. Create Parameter Set 1, set logical operator as AND, and configure the following two parameters:

      Parameter Name

      Regex

      Operator

      Parameter Value

      Authentication Mechanism

      NA

      Is equal to

      Kerberos

      Location

      NA

      Is equal to

      US

    2. Create Parameter Set 2 and configure the following parameter:

      Parameter Name

      Regex

      Operator

      Parameter Value

      Anti-virus software

      \\d+\\.\\d+\\.\\d+\\.\\d+

      is not equal to

      The version of anti-virus software is 1.1.0.99.

    3. Set the logical operator between parameter sets as AND.

    NOTE:To use this rule, you must create a custom class to retrieve details from an external provider. For more information, see User Information Methods and Creating an Authentication Class in the NetIQ Access Manager 4.5 SDK Guide.