The following illustration depicts risk-based authentication process:
The following illustration depicts the risk-based authentication in a federated setup:
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
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 evaluated against defined risk levels. After the risk level is identified, the authentication mechanism is selected and the user is authenticated. If the risk is high, the user is required to go through additional authentication methods or access is denied.
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.
NOTE:You cannot record history in this configuration because no user-context is available. To use history with pre-authentication risk assessment, configure a post risk-based authentication.
The following graphic illustrates how risk-based authentication works in this scenario:
You can assess potential risks associated with a particular login attempt after a user is authenticated and mitigate the risk. In this scenario, risk-based authentication generates 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
The risk score is evaluated against defined risk levels. After the risk level is identified, the user is granted or denied access. If the risk is high, the user is prompted for additional authentication.
For example, an employee logging into a payroll application through an office laptop during business hours from the same location and IP address will have a low-risk score. Whereas, an attempt to access the payroll application through a personal device from home yields an elevated score.
If the score exceeds the defined value, the login attempt is considered as high risk. The user might need to provide a higher level of authentication using a PIN or token.
The following graphic illustrates how risk-based authentication works based on specific parameters:
You can implement additional authentication through TOTP authentication or Advance Authentication methods. If the risk is too high, access can be denied. For more information, see Two-Factor Authentication Using Time-Based One-Time Password and Advanced Authentication.