Add support for the Google Chrome Endpoint Verification extension

[esilverberg]

This PR adds support for the Endpoint Verification extension to support Context Aware Access to your AWS SAML app, which is a feature of Cloud Identity Premium.

This means, for example, that you can ensure that users of gsts are running on the latest version of MacOS, on a laptop whose serial number is registered to your company.

This PR works by detecting whether or not the Endpoint Verification Extension has already been installed on your system (presumably it would have been if this is a feature your organization is trying to use). If so, it tells Chromium about the local path, because the only way to get Chromium to use extensions if if they are already downloaded locally.

[ruimarinho]

Hello @esilverberg. Thanks for the PR. I've finally had a chance to look at your changes and here's some feedback based on my experience:

• Endpoint verification is very tricky. Officially, it is only supported in Chrome (not in Chromium or other Chromium-based browsers like Brave or Edge).
• Endpoint verification creates a keychain entry on macOS login vault called Endpoint Verification Safe Storage to manage its credentials.
  • By default, it looks like Chrome is allowing all apps to use it, but if you try to launch gsts with it's built-in chromium binary and load the endpoint verification extension manually, it will throw a Can't sync because of a Keychain authorization error. message on the extension's UI
  • You can fix this error by removing the entry and then manually clicking Sync now on the extension UI once in headful mode on the chromium instance.
  • However, if you do this, then Chrome will break and require you to delete the entry before you can do a Sync now again, effectively forcing you to choose one browser or the other.
• Alternatively, you could point gsts to use Chrome and keep the same binary interacting with the keychain entry (--engine-executable-path="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome") although I'm not completely sure the use of another user data (profile) directory would create other problems.
• Nevertheless, if your organization deploys endpoint verification on Chrome, it's likely it's also force installing the Endpoint Verification extension and whitelisting which extensions can be installed. In this case, loading unpacked extension (the mechanism used on this PR and the only one I know of that could work) is disallowed.
• Presently, Chrome/Chromium only allow extensions to be loaded in headful mode. This means a highly degraded UX of gsts, as every login attempt will require a headful popup (interaction won't be needed, but a window will pop up).

Unless I'm missing something, the only possible successfull path for Chrome Endpoint Verification in gsts is if you meet the following conditions:

• You need to use an existing Chrome installation (--engine-executable-path="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome") to avoid the keychain error (presumably).
• Your organization must allow unpacked extensions to be loaded (essentially removing the wildcard extension blocklist, creating other security risks).
• You're ok with seeing a Chrome window popup every time you log in.

If you confirm this experience, I'm not sure if an organization would prefer applying other policies (non device-policies) specifically to this SAML integration as a counter-measure.

[esilverberg]

Thank you for this feedback!

• I have confirmed that by using --engine-executable-path="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" we can avoid the keychain error 🎉
• Our org is definitely OK with the Chrome window -- that is the only way to reliably authenticate with Google and the main reason for our use of gsts vs aws-google-auth

At this point the tradeoff is between allowing our employees to load unpacked extensions in Chrome, vs reducing the attack surface against our AWS endpoints from "anyone who obtains employee credentials and the second factor" to "anyone who obtains employee credentials + the second factor + one of a few dozen physical devices". Given that Chrome in this configuration is run for a narrow period of time, and my developers already have effective root access to their laptops, that seems like a tradeoff very much worth making.

Lastly, I also believe that Google would endorse this approach in their BeyondCorp architecture: https://cloud.google.com/beyondcorp

Endpoint Verification is basically Google productizing their BeyondCorp philosophy:

• Access to services must not be determined by the network from which you connect
• Access to services is granted based on contextual factors from the user and their device
• Access to services must be authenticated, authorized, and encrypted

At this point the only sticking point with this implementation is the race condition that exists just after you successfully login -- the login completes and attempts to auth with AWS SAML before Endpoint Verification extension has sync'd. The first time through it will always land on an error page. You have to hit the back button after the extension has sync'd, and then the page + gsts script complete with success. I'm not sure that it's possible to add a delay between the successful login on Google's side at the attempt to https://signin.aws.amazon.com/saml.