78001 - Representative User validation

[bramleyjl]

Summary

• Updates AccreditedRepresentativePortal::RepresentativeUserLoader to validate Veteran::Service::Representative record
• Validation based on first_name, last_name, ssn, birth_date - dob & birth_date sourced from an MPI call using ICN
• If no record is found authentication will be blocked with a RecordNotFoundError

Related issue(s)

• Sign in Service Representative Attribute Validator va.gov-team#78001

Testing done

• New code is covered by unit tests
• To test, you will need to create a Veteran::Service::Representative with the attributes of the test user you have chosen:

attributes = {
  first_name: 'GREG',
  last_name: 'ANDERSON',
  ssn: '796121200',
  dob: '1933-04-05',
  representative_id: '12345',
  poa_codes: ['TEST']
}
Veteran::Service::Representative.new(attributes).save!

• The above example uses the information from [email protected]
• You should then be able to perform representative authentications to test the validation with your chosen user (successful auth) and other users (failed auth).

Logs

Rails -- User is not a VA representative : {:access_token_authorization_header=><access_token>}

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
• 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
• I added a screenshot of the developed feature

[asg5704]

😎

[gabezurita]

The ARP engine will likely use a VS::Representative's OGC number to get their POA codes, which is currently stored in vets-api's representative_id. This will not be used for validation, but to get the poa_codes associated with a Representative.

See this Zenhub issue exploring ARP engine RepresentativeUser validation/authentication. Summary below.

RepresentativeUser Authentication/Validation Exploration Summary

Interim, Pilot Solution

@amprokop, @nihil2501, and I explored the hypotheses outlined in the above issue. The most feasible pilot alternative seems to be to add an enabled: bool attribute to the RepresentativeUser model, with ARF engineers setting this in a static JSON file within vets-api. This would be a whitelisting approach.

Other Explored Alternatives

• Is there a private OGC registration number that is treated as a secret?
  • Per the OGC API's v1/accreditations/Representatives/{id} endpoint, there are two returned IDs (in UUID format), repVSoid and accrRepId, that could potentially be used for this. ARF is unsure if these OGC API IDs are treated as a secret or are IDs meant for internal use, and OGC<>ARF coordination will be necessary around that. Even then, thought would need to be given to how ARF would get these identifiers to Representatives. Additionally, given that these identifiers are in UUID format, it would be cumbersome for VSReps to enter them manually in ARP.
• Could ARP require users to perform one-time authentication using the email address OGC already has on file? (this will probably block some users from access, as ARM found data quality issues with rep contact data, but it may be a sound long-term incentive to keep that data correct?)
  • This is possible, but it may be a heavy lift for the ARP Pilot. Additionally, there would be friction to this alternative, given OGC data quality issues around emails.
• Could we match on SSN, DOB first name, and last name and have that be enough? (SSN is found in OGC's internal dataset, though we need to verify how reliably it is present)
  • The OGC API's/api/v1/accreditations/Representatives/active endpoint returns DOB and SSN as fields in the response body, but all values are currently empty. The ARF Team would have to check with OGC if they plan on returning populated DOBs and SSNs in their responses. This is a promising alternative if OGC plans to return non-nil values for DOB and SSN.

[gabezurita]

@bosawt, what are your thoughts on pushing forward with the above interim solution for the ARP pilot?

[gabezurita]

ARP will use session.user_verification and have a join table between UserVerification (credential someone logged in as) <> VS::Representative, which will get used to set a RepresentativeUser's poa_codes here.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This PR has been closed because it has had no activity for 37 days