Merged
Conversation
…w user to use webauthn for 2FA. Why: So we can support strong authentication via hardware security keys as a new 2FA option How: Generate a challenge on the server side and present the browser with a list of credentials that are registered to the user. Use the Credential Manager API (navigator.credentials.get) to ask the browser to sign the challenge if the authenticator contains one of the given credentials and the user gives consent. The web page then automatically submits the form with the signed assertion for the server to verify. Use the webauthn gem to verify the assertion response. Upon success the user is authenticated.
**Why**: We have guard-rspec in our Gemfile, but never set up the Guardfile. The byebug update was necessary for zeus to work on my computer.
**Why**: In SessionsController, we were using `.empty?` instead of `.blank?`. I forgot that `fetch` with a default value only works if the hash key itself is not present, not if it's present and has a nil value.
LG-641 Handle nil request_id properly
**Why**: The background job does not actually run in the background since we are using the inline adapter, but it does add a lot of complexity to our code. Since we are not using the background job, this commit moves the proofing logic into the foreground in the idv step objects.
Add Guardfile for faster local testing
**Why**: Users are confused / frustrated why we’re asking for the phone number again **How**: Change language on the page to make it feel like users are verifying their identity rather than repeating an action.
**Why**: These are the most sensitive digits. A variety of identity proofing operations often require only the last 4 digits, including for things like pulling a credit report. **How**: Replace the last four digits with asterisks.
…ount-page LG-654 Redact entire SSN from /account page
…webauthn-at-account-creation LG-599 LG-603 Allow webauthn at account creation. Allow webauthn for 2FA.
…ddress-confirm-page LG-609 Change language on phone / address confirmation page
**Why**: We want to support multiple email addresses per account. **How**: We start by creating a table that lets us store more than one email address for a user. We tie in to the user model because we need to support Devise for creating accounts.
**Why**: PR #2501 was not rebased against master, and caused specs to fail on master and on other branches based on master. **How**: - Update webauthn setup controller to use the new personal key policy object and fix the logic so that LOA3 users don't see the personal key before the IdV flow. - Update French translations
Update webauthn setup to match master branch
**Why**: The current cancel flow takes the user back to the user's account. It will be more useful for them to go back to the SP. **How**: Replace the link to the accounts page with the failure_to_proof_url which will use the return_to_sp link if a failure to proof url is not provided. Thus, it will satisfy requirements for both LOA1 and LOA3.
**Why**: We now require exact matches, and the config didn't have the exact redirect URI
**Why**: The Devise locale folder is for Devise-specific strings. None of the strings we had under the `two_factor_authentication` section were related to Devise. We have a separate folder for 2FA localizations: `config/locales/two_factor_authentication` **How**: - Cut and paste anything under `devise.two_factor_authentication` into the `two_factor_authentication` folder - Run `make normalize_yaml` - Do a search and replace for `devise.two_factor_authentication` with `two_factor_authentication`
LG-515 Move 2FA localizations out of Devise file
Update redirect URI for sp-oidc-sinatra app
**Why**: We want to support multiple email addresses per account. This requires that we store email addresses in their own table. **How**: A rake task to copy existing email information to the new table.
…-address-table [LG-588] Rake task populating email addresses
**Why**: We are getting an error raised if no phone configuration exists. **How**: Check for nil and return a blank string.
Return blank for nil phone numbers
**Why**: When the feature flags are disabled the routes are not valid so references to the urls throw an error unless guarded with a feature flag. **How**: Add feature flag checks for all PIV/CAC and webauthn urls and test coverage
LG-442 Remove unused sidekiq and worker code
LG-684 Rescue Faraday::ConnectionFailed errors
**Why**: For HOMES.mil integration testing **How**: Update the help text hooks for the new service provider friendly names. Update the locale files
**Why**: The `newrelic_rpm` gem added a call to `SecureRandom.hex(8)` on 6/13/18: newrelic/newrelic-ruby-agent@60ef61c Some of our tests stub calls to `SecureRandom`, and because we have New Relic tracers in an initializer, the newly-added call to `SecureRandom` in the gem caused the tests to fail because they are not expecting that additional call. RSpec tells us to stub the call with a default value first in this case.
LG-651 Allow newrelic_rpm to be updated
**Why**: We want to show all of the phones that a user is using. **How**: In the account management page and the various mfa login and management selection views, we allow multiple phones. We tweak a few other places to help make things a bit more consistent.
**Why**: Some phones will visit the SMS link to retrieve a thumbnail and this triggers a cancel. **How**: Add a confirm screen and have it call the old logic via a post request. Prevent token leakage by placing a valid token in session.
**Why**: The link accidently included a `path:` component, making a bad link. **How**: Remove the `path:` part of the call and add tests to make sure we don't introduce it back in.
Get link right for adding a phone
**Why**: Because according to AAMVA this is the longest a state id number can be, and they perform this validation on the requests that we send to them.
**Why**: When a user chooses to verify by mail and then returns to say they can't receive mail at this address we should remove their verification pending status **How**: Ensure that if they are on the phone verification page they have effectively cancelled their pending status.
**Why**: Because AAMVA says it is supported now
**Why**: To make it more consistent with the other classes under the AccountReset namespace.
LG-666 Refactor AccountResetService
**Why**: The PIV/CAC feature will not be disabled going forward, so we are removing code that checks whether or not it is enabled. **How**: I am searching through the code and removing all references to the FeatureManagement.piv_cac_enabled? class method where appropriate. I am also removing any tests or changing tests as needed.
LG507: Remove PIV/CAC feature flag
**Why**: We want to make it easier to distinguish between headers and list items. **How**: For now, add a new class that pads left. Later, we'll make the list of configurations a proper <ul/>.
Pad list items in account management screen
**Why**: To allow us to test in production without enabling the feature for all users. **How**: Update the policy object to include the current SP and enable webauthn when the SP is nil.
**Why**: Because AAMVA has started supporting these states
**Why**: Sometimes, requests to the Twilio Verify service fail to connect or time out. Twilio suggested that we retry the request to see if it works the second time. We had implemented retries for the Twilio REST API earlier. Now, we are adding it to the Verify service as well. **How**: - Use Faraday to catch and rescue timeouts and connection failures, and raise our own custom `VerifyError`. Typhoeus does not raise exceptions, and therefore does not support retries out of the box. Since the `twilio-ruby` gem uses Faraday, and we rescue Faraday errors in `TwilioService`, I thought we'd use Faraday here too for consistency. - Use dependency injection to specify the connection class, which makes testing easier. - Include "Twilio Verify" in the custom error message to make it easier to differentiate from timeout and failed connection errors raised by the Twilio REST service.
LG-543 Retry failed Twilio Verify requests
…atching (#2451) **Why**: To enhance the security of the identity verification services we offer. **How**: Interface to external vendors to verify document authenticity and selfie matching. Perform resolution on the document PII along with a user supplied ssn and phone number. Provide options to replace the existing LOA3 flow or allow both to coexist so doc auth can be tested by manually entering the path /verify/doc_auth in the browser. Create a new framework that automatically implements our coding guidelines, minimizes the code we write, and seamlessly manages session state via a state machine with pluggable flows and steps.
**Why**: To emphasize that we will never ask the user to 'verify' the key, and it will only be used in the account recovery flow. **How**: Update the HTML, CSS, and language. Add new images.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.