Skip to content

GitLab

Closed
Created by Maxime Besson@maxbes🔧Maintainer

Contextual / Adaptive authentication / Risk-based authentication

Summary

We have growing demand for a set of inter-related features:

  • Send an email when connecting from a new IP (#2325 (closed))
  • Send an email when connecting from a new country (own customer use case)
  • Send an email when connecting from a different browser (own customer use case)
  • Skip 2FA when connecting from an internal network (Plugins::AdaptativeAuthenticationLevel)
  • Skip authentication entirely when connecting from the same browser (Plugins::StayConnected)
  • Remember 2FA and don't ask it again on the same browser (#2490)

And maybe, someday, someone will ask:

  • Remember 2FA and don't ask it again on the same browser, except when the connection comes from a different country, in which case, send an email.
  • Ask 2FA when IP is in Crowdsec blacklist
  • etc.

All these plugins have the generic behavioral template in common:

  1. Identity a specific condition in the authentication context:
    • New geo location (country, city...) compared to history
    • New user-agent configuration (different browser vendor, different locale, etc.) compared to history
    • Remembered user-agent (stayconnected cookie)
    • IP range, etc.
  2. Implement an action based on this condition
    • Skip 2FA
    • Send an email
    • Auto-login
    • Deny attempt (BruteForceProtection, etc)

In order to allow complex configuration, a plugin should not implement both of these steps.

Design proposition

I think we should ship a set of plugins to implement step 1. And a different set of plugins to implement step 2 (or modify existing plugins)

Example:

  • Plugins::NewLocation (uses ip address, optionally GeoIP)
  • Plugins::NewBrowser (uses UserAgent sniffing)
  • Plugins::RememberBrowser (uses a cookie to remember a browser without using UA sniffing, see #2591 (closed))
  • Plugins::AllowIpRange
  • more as needed

These plugins might set a $suspiciousActivityLevel variable incrementally (integer). And populate a $suspiciousActivityDetail variable containing user-oriented detail

$suspiciousActivityDetail = {
  'newLocation' => "France",
  'newIp' => '1.2.3.4',
  'unknownBrowser' => 1,
}

Starting from this common interface:

  • You can add $suspiciousActivityLevel > 0 to your 2FA rule, to only trigger 2FA on supicious logins (as defined by the other currently enabled plugins)
  • We can create a new AlertSuspicious plugin that sends an email, formatted from $suspiciousActivityDetail, to the user when a login is suspicious, whether it is because of a new IP, unregistered browser, etc.
  • We could modify the Crodsec plugin to only flag the auth attempt as suspicious, but not deny it.
  • We can implement an detection algorithm that collects suspiciousActivityDetail from all existing plugins, performs Machine Learning on it (or deep learning, blockchain sorcery, buzzword-of-the-day-here), and sets the suspicion level accordingly, without having to reimplement "punitive actions" inside it.
  • YOUR_USE_CASE_HERE

@guimard @clement_oudot let me know what you think of this approach, and if you have a better/different approach to suggest to make all these plugins work together

Edited by Maxime Besson