Implement policy rules on PreferredName / demographics call

[wesrowe]

Description

User story

As a Cartography team member, I want to implement rules that will reduce the likelihood of a 401 error.

Notes

• This change is needed because the VA Profile endpoint that provides demographics will fail if the user does not satisfy these policies. It is undesirable to have the VA Profile service return 401 errors even if we can catch it on the Vets API side.
• Aligned with Patrick on 4/2
• The recommendations and policies are captured in
  • Notes in the sensitive repo
  • The post-mortem (PR here, not sure where final file lives)
• The policy rules should be implemented at the API client level instead of the code that uses the data. This will make sure no other uses of the client will result in these 401 errors. This also means that we may need to update existing code owned by another team. Speak with Tom Harrison about this.
• Should this be behind a feature flag?
• An example of policy on claim data (also using a feature flag) – per @dcloud

Quick summary of policies that cause 401 errors (make sure to check referenced docs above):

• The demographics_policy checks that the user has an idme_uuid or a logingov_uuid.
• The mpi_policy ensures that the user either has an ICN or all of the following before making the call: first_name, last_name, birth_date, ssn, and gender.

Possible tasks:

• Discuss with Tom Harrison (@tpharrison) to ensure alignment
• (separate PR) Re-add the rolled-back code behind feature flag
• Implement policy rules for the demographics client.
• Make sure the dependencies/other piece aren't broken
• Informed VA Profile team of the changes to the client before merging, so they can monitor for issues.
• Test:
  • test data available in "VCR tapes" for unit tests
  • Look for users in Staging
  • Smoke test in prod, watching Datadog

Acceptance criteria

• Informed VA Profile team of the changes to the client before merging.
• Rules are implemented prior to calling the demographics service
• Verify other uses of the Demographics service are unchanged.
• Verify there is no increase of 4xx responses from the VA Profile demographics service (contact VA Profile on how to see this)

[dcloud]

Notes

Carlo's reverted PR placed a call in the app/services/users/profile.rb, adding a scaffold.demographics to the fetch_and_serialize_profile function. It lacked a policy check, and policies are typically called in controllers' before_action callbacks, e.g. before_action { authorize :demographics, :access? } in preferred_names_controller.rb.

app/controllers/v0/users_controller.rb is brief and makes use of app/services/users/profile.rb, and that in turn relies on functions in app/models/user.rb which relies on other files for fetching data from cache or API call. For example, the veteran status originating in VA Profile data uses app/models/va_profile_redis/veteran_status.rb to fetch data from Redis or from the lib/va_profile/veteran_status/service.rb, where API calls are made.

Files of interest:

• app/services/users/profile.rb - where user data is fetched/pre-serialized
• app/controllers/v0/users_controller.rb - runs the user.pre_serialize fn

[dcloud]

http://localhost:3001/sign-in/mocked-auth

[dcloud]

• https://github.com/department-of-veterans-affairs/va.gov-team-sensitive/blob/master/products/identity-personalization/developer/mock_va_profile_service_history.md
• https://github.com/department-of-veterans-affairs/va.gov-team-sensitive/blob/master/products/identity-personalization/developer/mock_data.md