Add Access Token Information to FHIR endpoint logging

[loganbertram]

JIRA Ticket:
BB2-3108

User Story or Bug Summary:
As a security engineer, I want logging to contain the access token user ID and hash fields to FHIR Resource endpoint logging, to tie each request to the specific user that made the request, so that we could better understand the incident problem and troubleshoot to resolve it in an efficient and timely manner

What Does This PR Do?

This PR adds to the FHIRRequestSerializer everything necessary to extract access token id and hash and add it to the object.

What Should Reviewers Watch For?

Testing this is tricky.

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

• Run the application locally and use the test client to generate authenticated fhir endpoint requests. Check the log to confirm.

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? No.
  • Does this PR modify or invalidate any of our security controls? No.
  • Does this PR store or transmit data that was not stored or transmitted before? No.
• If the answer to any of the questions below is Yes, then please add StewGoin 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? No.

Any Migrations?

• 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.

[jimmyfagan]

The changes looks good, however when testing locally, I'm still seeing empty values for the access token:

2024-05-07 04:03:15,871 INFO [44] audit.data.fhir line:151 {
                    web-1  |   "access_token_hash": "",
                    web-1  |   "access_token_id": "",
                    web-1  |   "api_ver": "v2",
                    web-1  |   "application": {
                    web-1  |     "id": "1",
                    web-1  |     "name": "TestApp",
                    web-1  |     "user": {
                    web-1  |       "id": "2"
                    web-1  |     }
                    web-1  |   },
                    web-1  |   "auth_app_data_access_type": null,
                    web-1  |   "auth_app_id": null,
                    web-1  |   "auth_app_name": null,
                    web-1  |   "auth_client_id": null,
                    web-1  |   "auth_pkce_method": null,
                    web-1  |   "auth_uuid": null,
                    web-1  |   "fhir_id": "-10000010254647",
                    web-1  |   "includeAddressFields": "False",
                    web-1  |   "path": "/v2/fhir/Patient/-10000010254647",
                    web-1  |   "request_uuid": "bb0ce08e-0c26-11ef-ba3a-0242ac180003",
                    web-1  |   "start_time": "2024-05-07 04:03:15.824907",
                    web-1  |   "type": "fhir_pre_fetch",
                    web-1  |   "user": "patientId:-10000010254647",
                    web-1  |   "uuid": "bb0ce08e-0c26-11ef-ba3a-0242ac180003"
                    web-1  | }

Similar results on other endpoints. Any ideas why that's the case?

[jimmyfagan]

I do see these fields in the logs, but I'm unsure if we're logging the right thing here. Also the AC of the ticket references updating tests, not sure if we have tests that can easily be updated to cover this, but if you could just leave a comment or add to the description to address that, that would be helpful too.

[jimmyfagan]

The ticket says we want a Access Token User ID and User Hash, but this seems to be the application id. Do we have access to the user id here instead? As it is, it's unclear how I would use these to tie the logs to a specific user.

[loganbertram]

It's a pattern taken from request_logging.py where access tokens are similarly extracted for logging purposes. Our use case may be slightly different. I swapped this out for at.id here.

[jimmyfagan]

It seems like the at.id is showing the user id associated with the application, not necessarily the one associated with the access token. I might recommend starting a fresh server, and generating an access token, looking in Django Admin to see the details of the access token, then setting a breakpoint at this point in the code to see if the access token details are visible anywhere there. As far as I understand, it shouldn't matter exactly what field is logged, as long as it's something that we can search on in Django admin to find the user, and I'm still not seeing that in my testing still.

[loganbertram]

That makes sense! I can walk that back into a value searchable from django admin. I had been approaching it to match up with the similar AT logging done in the HHS Oauth Server request audit logging, but the values we need may be even easier.

[jimmyfagan]

Looks good, just one simple suggestion but nothing that requires an additional review.