LG-775 Do not present FIDO auth option if browser does not support FIDO

[stevegsa]

Why: So the user is not presented with an option they can't use.

How: Display the security key option as hidden in the list of 2FA options. Use javascript to determine if FIDO is supported. If it is supported unhide the security key option. If it is not supported make sure that the next 2FA option is selected by default.

Hi! Before submitting your PR for review, and/or before merging it, please
go through the checklists below. These represent the more critical elements
of our code quality guidelines. The rest of the list can be found in
CONTRIBUTING.md

Controllers

• When adding a new controller that requires the user to be fully
  authenticated, make sure to add before_action :confirm_two_factor_authenticated
  as the first callback.

Database

• Unsafe migrations are implemented over several PRs and over several
  deploys to avoid production errors. The strong_migrations gem
  will warn you about unsafe migrations and has great step-by-step instructions
  for various scenarios.

• Indexes were added if necessary. This article provides a good overview
  of indexes in Rails.

• Verified that the changes don't affect other apps (such as the dashboard)

• When relevant, a rake task is created to populate the necessary DB columns
  in the various environments right before deploying, taking into account the users
  who might not have interacted with this column yet (such as users who have not
  set a password yet)

• Migrations against existing tables have been tested against a copy of the
  production database. See LG-228 Make migrations safer and more resilient #2127 for an example when a migration caused deployment
  issues. In that case, all the migration did was add a new column and an index to
  the Users table, which might seem innocuous.

Encryption

• The changes are compatible with data that was encrypted with the old code.

Routes

• GET requests are not vulnerable to CSRF attacks (i.e. they don't change
  state or result in destructive behavior).

Session

• When adding user data to the session, use the user_session helper
  instead of the session helper so the data does not persist beyond the user's
  session.

Testing

• Tests added for this feature/bug
• Prefer feature/integration specs over controller specs
• When adding code that reads data, write tests for nil values, empty strings,
  and invalid inputs.

[jgsmith-usds]

I was in the all-hands meeting where this was discussed. @brodygov and I discussed what we hoped for this. The concern was in defaulting to webauthn if the user was using a browser that didn't support it. Rather than change the options we show, we want to bounce them to the option list if we would otherwise show them the webauthn once they've submitted their username/password. That is, if we show them webauthn because of the logic in Users::TwoFactorAuthenticationController#show, redirect them to TwoFactorAuthentication::OptionsController#index.

[stevegsa]

@jgsmith-usds I updated the PR to include a redirect back to the option list if the user winds up on the webauthn login screen.

[brodygov]

@stevegsa What is supposed to happen when loading this with a browser that doesn't support WebAuthN?

I tested this in Safari, and contrary to what I expected, it threw a JS error and stayed on the "Present your security key" page.

TypeError: undefined is not an object (evaluating 'navigator.credentials.get')
nrWrapper — webauthn:18:11408

[brodygov]

Also is there a problem with our JS New Relic license key? An error appeared in dev from what I assume is the New Relic JS stuff trying to post the exception info to New Relic.

https://bam.nr-data.net/1/329e70d6b7?a=46002276&sa=1&v=998.365d633&t=Unnamed%20Transaction&rst=276&ref=https://idp.dev.identitysandbox.gov/login/two_factor/webauthn&...
[Error] Failed to load resource: the server responded with a status of 403 (An error occurred validating the license key)

[stevegsa]

@brodygov I see the problem. I hooked the redirect up to the setup js but not the auth js. The selection list does correctly not show webauthn but since we propel you to the first option bypassing the selection list it didn't catch the redirect which uses webauthn-authenticate.js. I will fix this. Good catch! Good thing it's not in prod yet.