[v18] Add Browser MFA

[danielashare]

This is a backport of the Browser MFA feature to v18. The RFD for this feature can be found here.

I've had to make some modifications to get this working with v18:

1. Backport in-band MFA's MFAService because some Browser MFA RPCs/proto was added to that service, added files are:
   • challenge.proto
   • service.proto
   • buf.yaml
   • grpcserver.go
2. In master message MFADevice has been moved out of types.proto in to mfa_device.proto, so I've moved message BrowserMFADevice back for the backport
3. Switched the Route in Teleport.tsx to use element instead of component to work with v18's version of react-router, along with test router changes in BrowserMFA.test.tsx

changelog: Added browser-based MFA option to tsh, enabling passkey/biometric authentication via the browser

Manual Test Plan

Test Environment

Using a mix of v17/v18 clients and servers, testing with OSS and e Teleport (with SSO via Keycloak) locally against with these resources:

• local ssh server
• windows desktop
• remote ssh server (for Vnet testing)

For Browser MFA to be offered to a client, a WebAuthn device must be registered for that user.

Test Cases

• tsh login
  • specifying --mfa-mode=browser uses Browser MFA
  • without specifying --mfa-mode=browser falls back to Browser MFA when no keys present locally
  • Browser MFA isn't offered when it is disabled at a cluster level
• tsh ssh
  • specifying --mfa-mode=browser uses Browser MFA
  • without specifying --mfa-mode=browser falls back to Browser MFA when no keys present locally
  • moderated sessions support Browser MFA
• Teleport Connect
  • can use Browser MFA to login
  • can use Browser MFA to MFA for ssh
  • can use Browser MFA to MFA for Windows Desktop
• tctl
  • edit cap specifying --mfa-mode=browser uses Browser MFA
  • edit cap without specifying --mfa-mode=browser falls back to Browser MFA when no keys present
• SSO MFA unaffected by these changes
  • with Browser MFA enabled on the cluster
  • without Browser MFA enabled on the cluster
  • and can use Browser MFA if specified manually
• Vnet SSH
  • works with no per-session MFA required
  • with per-session MFA required
    • works with a hardware key present
    • fails with no hardware key present
    • works with Browser MFA
    • doesn't request Browser MFA when disabled via config

[cthach]

@danielashare

I'm doing a full review right now.

Just curious, did you test with VNet? I learned last week that MFA implementation is a separate code path than tsh and Teleport Connect. Please add to the manual test cases just to ensure we exercised it.

[cthach]

In addition to manual testing VNet, can we also add test cases for testing backwards compatibility if a newer client that tries browser MFA with an older cluster that doesn't support it if it makes sense? I'm expecting it should fail fast, but I think it is worth checking since we might have users running newer clients that may try to connect to older clusters.

[cthach]

Changes look OK overall and comments are mostly questions or nits. They are not blocking.

Please just perform the additional manual testing for VNet and older Teleport clusters before merging.

[danielashare]

Changes look OK overall and comments are mostly questions or nits. They are not blocking.

Please just perform the additional manual testing for VNet and older Teleport clusters before merging.

Thanks for the thorough review, @cthach. I tested VNet, which worked as it uses similar code paths to the MFA prompts that are triggered and resolved inside of Connect. I had tested old/new client/servers, but had forgotten to mention that in my test plan, added now.