4.5.1 How Risk-based Authentication Works

You can configure risk-based authentication in the following two ways:

  • Risk assessment and risk mitigation before authenticating a login attempt

  • Risk assessment and risk mitigation after authenticating a login attempt

Risk Assessment and Risk Mitigation before Authenticating a Login Attempt

You can assess the potential risk of a particular login attempt before authenticating the user and then mitigate the risk, if required. You can also configure specific authentication mechanisms based on the risk. In this scenario, user profile is not involved. In this scenario, risk-based authentication works by developing a risk score based on the following parameters:

  • IP Address

  • Cookie

  • HTTP Header

  • Geolocation

  • External parameters

  • Time of login

  • Device Fingerprint (without user attributes)

  • Custom rule (without user attributes)

This risk score is then evaluated against defined risk levels. You can define the risk levels based on the sensitivity of the information. After the risk level is identified, the authentication mechanism is selected and the user is authenticated. In cases of high risk, the user is either denied access or is required to go through additional authentication methods.

NOTE:You cannot record history in this configuration because there are no user-context. If you want to use history with pre-authentication risk assessment, you must configure a post risk-based authentication.

For example, an employee trying to log in to a payroll application by using the corporate Intranet is authenticated through Kerberos authentication mechanism. However, the employee logging into the payroll application from outside the office must provide an x509 certificate for authentication.

The following graphic illustrates how risk-based authentication works in this scenario:

Risk Assessment and Risk Mitigation after Authenticating a Login Attempt

You can assess the potential risks associated with a particular login attempt after authenticating the user and then mitigate the risk, if required. In this scenario, risk-based authentication works by developing a risk score for each login attempt based on the following parameters:

  • Geographical location

  • Device Fingerprint

  • IP address

  • HTTP Header

  • User attributes

  • Cookie

  • User last login

  • Time of login

  • External parameters

  • Custom parameters

This risk score is then evaluated against defined risk levels. The risk levels are defined based on the sensitivity of the information. After the risk level is identified, the user is granted or denied access. In cases of high risk, the user is prompted for additional authentication to confirm the user identity one more time and assess the validity of the request.

For example, an employee logging into a payroll application by using the office laptop during the usual business hours from the same location and IP address will have a low-risk score. Whereas, an attempt to access the payroll application by using a personal hand-held device from non-office location yields an elevated risk score. If the risk score for a user’s access attempt exceeds the defined risk score, the login attempt is considered as high risk, and the user might need to provide a higher level of authentication using a PIN or token.

Additional authentication can be implemented by using techniques such as TOTP authentication or Advance Authentication Framework methods. If the risk is too high, access can be denied. For more information, see Section 4.3, Advanced Authentication.

The following graphic illustrates how risk-based authentication works based on specific parameters: