BB2-4250: Make v3_endpoints waffle switch app specific

[JamesDemeryNava]

JIRA Ticket:
BB2-4250

What Does This PR Do?

This PR ensures that once we enable the v3_endpoints waffle switch, we are able to control access to v3 endpoints on an app by app basis.

What Should Reviewers Watch For?

• Do the new unit/integration tests cover the needed cases?
• Is the deployment plan (link here) sufficiently detailed to roll this out?
• Note: If the flag has been added, and the application your are testing with is not in the flag, you will see the 403 immediately upon clicking Authorize as a Beneficiary when going through the v3 auth flow in the testclient. In Postman, if your local postman app is not in the flag, you will see the 403 immediately upon clicking Get New Access Token.

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

Validation

• Do unit and integration tests pass?
• Below is a way to manually validate this work that I have done as I moved through this. It's a bit to validate, so if reviewers want to split it up, feel free:
  • Pull down the branch, log into the admin UI
  • Go to Application Core -> Flags
  • Add a flag with name, 'v3_early_adopter'
  • Leave the Everyone value as Unknown
  • Add a specific user_id from your local bluebutton_crosswalk table to the Users section below (should be an integer value, should be a user you can log in as like BBUser00575)
  • To test the flow of an app being in the flag and able to access v3 endpoints:
    • Run the following statement: UPDATE dot_ext_application SET user_id = {{user_id added in django admin to flag}} WHERE id = 1;
    • That will make it so the TestApp is in the flag, and able to use v3 endpoints
    • Go through the v3 test client flow, ensure all of the v3 endpoints work once you are through to the test client
    • Validate through Postman using v3 authorize. Make sure you are able to refresh your token successfully and get a 200 back when running /v3/connect/userinfo. Note, you will need to run the same update statement as above, but swap out id = 1, with id = {{id of your local postman app}}
    • Go through v2 auth flow and confirm no issues there
  • To test the flow of an app NOT being in the flag, and not being able to access v3 endpoints:
    • Run the following statement: UPDATE dot_ext_application SET user_id = {{any user_id besides the one added to the flag in django admin}} WHERE id = 1;
    • You could also go into the Admin UI and just remove the user_id that you added previously
    • Go through the v3 testclient flow. As soon as you click Authorize as a Beneficiary, you will see a 403 error with a message explaining that the app does not have access to v3 endpoints yet
    • In your local Postman, try to execute v3 read/search calls for patient/coverage/EOB. You will also see a 403, with the same message as the auth flow
    • In your local Postman, try to refresh your token, you will see a 403 in the console
    • In your local Postman, try to execute a /v3/connect/userinfo call. You will see a 403 response with the same error message as read/search calls on patient/coverage/EOB.

What Security Implications Does This PR Have?

Please indicate if this PR does any of the following:

• Adds any new software dependencies
• Modifies any security controls
• Adds new transmission or storage of data
• Any other changes that could possibly affect security?

• Yes, one or more of the above security implications apply. This PR must not be merged without the ISSO or team
  security engineer's approval.

Any Migrations?

We are not adding data to the database, but we will have to create a waffle flag as we roll this out. We will then add specific user_ids to that flag to enable v3 endpoint access.

• 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

[jimmyfagan]

This is close to being good to go, but just a little more fine tuning. Hopefully we can just do a quick working session on some of this in the morning.

[jimmyfagan]

In testing with a running local server with the flag created but without any apps enabled, I ended up with a generic 500 server error when issuing the authorize request. Seems like maybe in this path we need to add some kind of exception handling?

[JamesDemeryNava]

I'm assuming this was a v3 auth flow, do you know what the Everyone setting was? Had to be No or Unknown, but just want to confirm. Have not been able to reproduce the generic 500 error on the authorize request yet. I also set the superusers setting to False here, though I don't think that would have any bearing.

[JamesDemeryNava]

Confirmed today that we throw 404s when the flag is there but v3_endpoints switch is not active. Might be worth another set of eyes on that as well as that is what it will be in prod.

[jimmyfagan]

Looks good!