Risk-based authentication provides the following features:
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
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.
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:
For SAML applications: Assign the risk policy authentication method to the service provider’s contract as a second-factor authentication method. For more information, see Contracts Assigned to a SAML 2.0 Service Provider.
For applications protected by Access Gateway: While configuring an authorization policy, select Re-authenticate with Contract in Actions. For more information, see Configuring an Authorization Policy to Protect a Resource.
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
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.
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:
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 |
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. |
Set the logical operator between parameter sets as AND.
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.