jimfuqian/BB2-3276-auth-flow-events-adding-language-field

[JFU-NAVA-PBC]

JIRA Ticket:
BB2-3276

User Story or Bug Summary:

Enrich Auth flow logging events with language (en, es), needed to correlate authorization flow splunk dashboard queries.

Authorization Flow Logging Events:

AUTH EVENTS	SPLUNK SEARCH	TYPE	PATH	LANG_CODE	COMMENTS
1	baseSearch1	req_resp_log	/o/authorize	es/en
2	baseSearch2	req_resp_log	/mymedicare/login	es/en
3	baseSearch3	Authentication:start		es/en
4	baseSearch4	fhir.server.authentication.match_fhir_id		es/en
5	baseSearch5	mymedicare_cb:get_and_update_user		es/en
6a	baseSearch6a	mymedicare_cb:get_and_update_user		es/en
6b	baseSearch6b	mymedicare_cb:create_beneficiary_record		es/en
7	baseSearch7	Authentication:success		es/en
8	baseSearch8	req_resp_log	/mymedicare/sls-callback	es/en
9	baseSearch9	req_resp_log	/o/authorize/(?P[\w-]+)	es/en	location=""
10	baseSearch10	req_resp_log	/o/authorize/(?P[\w-]+)	es/en	location!=""
11	baseSearch11	Authorization		es/en
12	baseSearch12	AccessToken	/o/token/	es/en
13	baseSearch13	Flow agnostic (make it a pie chart)		es/en

What Does This PR Do?

• Added language code to auth flow logging events ('auth_language' field added to numerous auth flow log events)
• Extended AuthflowUUID model - adding field 'auth_language' - this is need to persist lang code across sessions
• Tweak testclient Authorization page - adding button "Authorizate with beneficiary (medicare.gov login in Spanish)" which will append a lang=es parameter at the end of the authorize URL...

What Should Reviewers Watch For?

If you're reviewing this PR, please check these things, in particular:

• TEST
• Local Test
  • Checkout PR and spin up a local BB2 server
  • Aim browser at localhost:8000 and go to test client page
  • Start AUTH flow (targeted at medicare.gov Spanish login) by hitting Auth in spanish button as below:

• Following through the data access grant steps, and collect logging at the std out of BB2 server start terminal

• Search through the captured logging output for "auth_language": "es" to verify that all authorization logging events are having language code (which will be used by Splunk search for auth flow aggregation on lang code.

• Test on LLE (e.g. TEST env)

  • Deploy the PR to LLE (e.g. TEST) - Need pre deploy migration (AuthflowUUID model change)
  • Test the scenarios as with local test, however do not use testclient (TestApp) since it is excluded by Splunk auth flow dashboard, instead create an application and use e.g., BB2 sample client to hit with authorization flow.
  • Observe the splunk dashboard - toggle the "Language" drop down to see flows with the selected language...

What Security Implications Does This PR Have?

Submitters should complete the following questionnaire:

• If the answer to any of the questions below is Yes, then here's a link to the associated Security Impact Assessment (SIA), security checklist, or other similar document in Confluence: N/A.
  • Does this PR add any new software dependencies? Yes or No.
  • Does this PR modify or invalidate any of our security controls? Yes or No.
  • Does this PR store or transmit data that was not stored or transmitted before? Yes or No.
• If the answer to any of the questions below is Yes, then please add a Security Engineer and ISSO as a reviewer, and note that this PR should not be merged unless/until he also approves it.
  • Do you think this PR requires additional review of its security implications for other reasons? Yes or No.

What Needs to Be Merged and Deployed Before this PR?

This PR cannot be either merged or deployed until the following pre-requisite changes have been fully deployed:

• CMSgov/some_repo#42

Any Migrations?

• Yes, there are migrations
  • The migrations should be run PRIOR to the code being deployed
  • The migrations should be run AFTER the code is deployed
  • There is a more complicated migration plan (downtime, etc)
• No migrations

Submitter Checklist

I have gone through and verified that...:

• This PR is reasonably limited in scope, to help ensure that:
  1. It doesn't unnecessarily tie a bunch of disparate features, fixes, refactorings, etc. together.
  2. There isn't too much of a burden on reviewers.
  3. Any problems it causes have a small "blast radius".
  4. It'll be easier to rollback if that becomes necessary.
• I have named this PR and its branch such that they'll be automatically be linked to the (most) relevant Jira issue, per: https://confluence.atlassian.com/adminjiracloud/integrating-with-development-tools-776636216.html.
• This PR includes any required documentation changes, including README updates and changelog / release notes entries.
• All new and modified code is appropriately commented, such that the what and why of its design would be reasonably clear to engineers, preferably ones unfamiliar with the project.
• All tech debt and/or shortcomings introduced by this PR are detailed in TODO and/or FIXME comments, which include a JIRA ticket ID for any items that require urgent attention.
• Reviews are requested from both:
  • At least two other engineers on this project, at least one of whom is a senior engineer or owns the relevant component(s) here.
  • Any relevant engineers on other projects (e.g. BFD, SLS, etc.).
• Any deviations from the other policies in the DASG Engineering Standards are specifically called out in this PR, above.
  • Please review the standards every few months to ensure you're familiar with them.