2040292 - Admins can enforce sign-out conditions via policy

Status: NEW

(Enterprise Products :: Firefox, enhancement)

Comment 2

[Gian-Carlo Pascutto [:gcp]]

There's a preference to make crashes a fail-safe, which is to say they enforce sign-out. (Could still be admin configurable)

Comment 3

[Josh Porter [:jporter]]

For uniformity across the policy and prefs for each signout path, I've come up with the following policy / mapped prefs. Since some sub-keys will have additional prefs, I kept the others consistent with the enabled subkey rather than keying on the trigger.

{
  "SignOut": {
    "BrowserClose": {
      "Enabled": true // enterprise.signout.browser_close.enabled
    },
    "BrowserCrash": {
      "Enabled": true // enterprise.signout.browser_crash.enabled
    },
    "BrowserRestart": {
      "Enabled": false // enterprise.signout.browser_restart.enabled
    },
    "ScreenLock": {
      "Enabled": false // enterprise.signout.screen_lock.enabled
    },
    "UserSwitch": {
      "Enabled": true // enterprise.signout.user_switch.enabled
    },
    "OSSleep": {
      "Enabled": true // enterprise.signout.os_sleep.enabled
    },
    "Idle": {
      "Enabled": true, // enterprise.signout.idle.enabled
      "TimeoutSeconds": 900 // enterprise.signout.idle.timeout_seconds
    },
    "NetworkLoss": {
      "Enabled": true, // enterprise.signout.network_loss.enabled
      "GracePeriodSeconds": 30 // enterprise.signout.network_loss.grace_period_seconds
    }
  }
}

Comment 4

[Brian Thomas Smith [:bsmth]]

We need to revisit this one, CCing Fiji

Comment 5

[Josh Porter [:jporter]]

Adding some additional context and notes here per our conversation about this today. Please correct me if I am wrong about my understanding of this!

The original bug was framed around signing users out, however this introduces high levels of friction in day to day use since a policy-driven signout is rather disruptive and can cause uses to lose their sessions/work. To mitigate this, it was proposed to add the ability to instead persist the session using the OS keystore. Essentially, for each trigger, the policy's boolean will determine whether the browser is signed out or "locked," thus requiring OS-level re-auth to resume.

Idle timeout, OS screen lock, OS sleep, and OS user switching we've deferred since each is already its own locking layer that gates resume with OS-level auth. Duplicating that in the browser just adds a second prompt without adding any security.

Updated list from above with some additional context from me added inline:

• Policy allows admins to specify sign-out/resume from keystore logic (true/false) for the following cases:
  • Browser is closed
  • Browser is restarted (i.e., update)
    • Child browser restarts currently do nothing with session since FELT manages tokens. Restarts for updates also restart FELT, which currently requires re-auth.
    • Current behavior:
      • Has pending update: FELT is relaunched and the user is signed out. (searchfox)
      • No pending update: Browser is relaunched by FELT and the user remains signed in. (searchfox)
  • OS screen lock (deferred/out of scope)
  • OS user switch (deferred/out of scope)
  • OS hibernate/sleep (deferred/out of scope)
  • Idle/inactivity timeout (deferred/out of scope)
    • Configurable timer
  • Browser crash
    • Users are already signed out on multiple crashes, which should be kept as a failsafe. Adding a policy for this can handle the single-crash scenario.
    • Current behavior:
      • Single crash: Browser is relaunched by FELT and the user remains signed in since FELT maintains the tokens. (searchfox)
      • Multiple crashes: User is signed out, FELT login is displayed with an error message. (searchfox)
  • Network connection loss
    • Hinges on console connectivity (ConsoleClient). Will have a configurable grace period, which can be set to 0 to trigger signout/lock immediately). Maybe make this a followup?
    • I have a draft for this here.