Features of Risk-based Authentication

Risk-based authentication provides the following features:

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

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 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:

Cumulative scoring

You can configure to add the risk score of the current session while evaluating contracts.

For example, 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 is 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 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 a user is from the US and the method used to authenticate is Kerberos. The user must not be using a device with an anti-virus software version 1.1.0.99. In this scenario, the configuration is as follows:

  1. Create Parameter Set 1, set the 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.

Behavioral Analytics

To enable detection of an unknown threat or anomalies, Access Manager integrates with Micro Focus Interset and leverages its User and Entity Behavioral Analytics capability.

Using the organization's data, Interset establishes the normal behavior for the organizational entities and then, using advanced analytics and machine learning, identifies the anomalous behaviors that constitute potential risks such as compromised accounts, insider threats, or other unknown cyber threats. See Configuring Behavioral Analytics.