Risk-based authentication in the Loginapp REST API/UI

Risk-based authentication takes one or more pieces of context information into account to assess the current risk. The authentication process can then be influenced based on the assessed risk. It can be used, for example, to omit the second factor in low-risk situations, deny access altogether in very risky situations, or choose a different path in the authentication flow.

More conceptual information can be found in Risk-based authentication.

Risk Assessment Step configuration

To assess the risk during an authentication process the Risk Assessment Step is inserted into the sequence of authentication flow steps.

  1. Go to:
    Loginapp >> Applications and Authentication >> <affected target application> >> Authentication Flow.
  2. Add a new plugin of the type Risk Assessment Step to the list of flow steps.
  3. Configure the Risk Assessment Step by adding one or more Risk Extractors to it.
  4. Use the flow tags produced by the risk extractors to influence the authentication flow. This is achieved by using skip conditions, preconditions, selection, or other flow concepts.
RiskBasedAuthenticationFlow
  • Hints for using the Risk Assessment Step in the authentication flow:
  • The Risk Assessment Step adds flow tags to the flow session. The tags can then be used to influence the authentication flow and/or identity propagation. Therefore, the Risk Assessment Step‚Äč does not directly influence the authentication flow.
  • The Risk Assessment Step may be used multiple times in the authentication flow.

Risk extractors and order of authentication flow steps.

Risk extractor plugins take the risk context information into account and, based on the configuration, produce one or more flow tags.

  • Risk extractor plugin examples (more plugins may be available in the configuration):
  • IP Address Range Risk Flow Extractor: produces flow tags based on the client's IP address.
  • Typical Geolocation Risk Flow Extractor: produces flow tags based on whether the current geolocation of the client is typical for the user logging in. A geo-location service must be configured for this risk extractor.
  • Impossible Journey Risk Extractor: produces flow tags based on the theoretical traveling speed between the current geolocation and the geolocation of the latest login. A geo-location service must be configured for this risk extractor.
  • Typical User-Agent Risk Flow Extractor: produces flow tags based on whether the current user-agent HTTP header is typical for the user logging in.
  • Anomaly Shield State Risk Extractor: produces flow tags based on the Anomaly Shield state reported by Airlock Gateway (8.0 or later).
  • Session Hijacking Notification Risk Extractor: produces flow tags based on the session hijacking notification reported by Airlock Gateway.
  • Client Fingerprinting Score Risk Extractor: produces flow tags based on the client fingerprinting score reported by Airlock Gateway

Make sure to place the Risk Assessment Step after the user-identifying step, if it contains risk extractors depending on user data.

  • Example:
  • The Risk Extractor Step contains the Typical Geolocation Risk Flow Extractor and therefore needs to know who is logging in.
  • The Risk Extractor Step is placed after the Username Password Authentication Step.

Other risk extractors, e.g. the IP Address Range Risk Flow Extractor, do not depend on user data at all and may be placed before the user-identifying step.

Login history repository

The login history repository stores information about a user's successful logins. It contains contextual information such as date, time, geolocation, user agent, etc. Risk extractors can use the information to judge whether the current risk context information is normal for a user or not.

  • For such risk extractors to work correctly, consider the following configuration settings:
  • Configure a Login History Repository in Loginapp >> Applications and Authentication.
  • For each authentication flow (independent of whether the flow contains a risk assessment step), decide whether it adds an entry to the login history if it was successful.
    • There are two ways to ensure this:
    • If the flow uses the Default Authentication Processor: enable its Write Login History checkbox.
    • If the flow uses the Custom Flow Processors plugin: add the plugin Login History Processor to the list of processors.