[82599] prevents new user verification creation for locked CSPs

[bramleyjl]

Summary

• Runs validation on new UserVerification creation, checking for an existing UserVerification with the same CSP type that is locked
• If a locked UserVerification is found the new UserVerification will still be created, but locked as well to prevent successful authentication.

Related issue(s)

• Prevent locked Login.gov UserVerification creation va.gov-team#82599

Testing done

• New code is covered by unit tests

To test, select the (Login.gov) user you wish to use and locate its corresponding UserAccount. Then delete the existing UserVerification if it exists and create a linked UserVerification that is locked.

UserCredentialEmail.delete_all
UserVerification.delete_all
UserVerification.new(user_account_id: <account id>, logingov_uuid: SecureRandom.hex, verified_at: Time.now, locked:true).save

• During SiS callback the user_verifier class will detect the linked UserVerification of the same CSP type & locked status and will set locked to true for the new UserVerification, as well as log the event.
  Rails -- [Login::UserVerifier] Locked UserVerification created for type=logingov_uuid identifier=e444837a-e88b-4f59-87da-10d3c74c787b
• Attempt to authenticate via /token with the selected user - login should be prevented by the existing credential lock behavior and Rails will throw an error:
  [SignInService] [V0::SignInController] token error -- { :errors => "Credential is locked" }

What areas of the site does it impact?

Authentication, new user creation

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected

[bosawt]

Few comments for some small updates, otherwise looks good!

[bosawt]

sorry, couple more changes, I realized this was in a transaction so we can't have the log directly in there

[bosawt]

Just one tiny comment that I found, otherwise looks good

[bosawt]

Can you start with function with return false unless existing_user_account?

This way you can remove all of the safety &. operators here

[bramleyjl]

I removed it from the user_account & user_verification since we know they'll be there with the guard clause, but the last one I think needs to stay because most times the existing account won't have a user_verification of the CSP type so it will be trying to call .where on a nil value.

[bosawt]

actually, you don't have to worry about nil, this is the beauty of ActiveRecord chaining:

UserAccount.last.user_verifications.send(:dslogon)
=> []

And then if you call .where on the result of this:

UserAccount.last.user_verifications.send(:dslogon).where(locked: true)
=> []

How is that possible? It's because ActiveRecord queries actually return an ActiveRecord_AssociationRelation, which you can still chain queries off of even if it's empty:

UserAccount.last.user_verifications.send(:dslogon).class
=> UserVerification::ActiveRecord_AssociationRelation

[bosawt]

Created a new user verification, confirmed that locked: false, as expected. Set the user_verification.locked: true, then created yet another user verification but with the same ICN as the old one. Confirmed a new user verification was created with user_verification.locked: true