BB2-4675: Add SAMHSA checkbox to v3 permissions screen

[JamesDemeryNava]

JIRA Ticket:
BB2-4675

What Does This PR Do?

Adds a checkbox on the v3 permissions screen, if the app has any ExplanationOfBenefit scopes. The checkbox is not selected by default. If the user leaves the checkbox unchecked, then the include_samhsa value on the oauth2_provider_accesstoken_extension record will be false, SAMHSA data will be filtered out of v3 EOB responses, and v1/2 EOB calls will be blocked for that token. If the user checks the checkbox, then the include_samhsa value on the oauth2_provider_accesstoken_extension record will be true, SAMHSA data will NOT be filtered out of v3 EOB responses, and v1/2 EOB calls will be allowed.

What Should Reviewers Watch For?

• Is test coverage sufficient?
• Any concerns about the caching strategy?

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

Validation

• Pull down the branch and build the project
  • In Postman, make sure your app has EOB scopes, go through a v3 auth flow
  • Leave the SAMHSA checkbox unchecked
  • Query the database for the most recent oauth2_provider_accesstoken_extension record, confirm include_samhsa is false
  • Make a v3 EOB search call, confirm that _security:not=42CFRPart2 is included in the link attribute of the response
  • Refresh the token, confirm the oauth2_provider_accesstoken_extension (it will be a new record, as the access token will have been deleted), still has include_samhsa of false
  • Go through another v3 auth flow, this time, check the SAMHSA checkbox.
  • Query the database for the most recent oauth2_provider_accesstoken_extension record, confirm include_samhsa is true
  • Make a v3 EOB search call, confirm that _security:not=42CFRPart2 is NOT included in the link attribute of the response
  • Refresh the token, confirm the oauth2_provider_accesstoken_extension (it will be a new record, as the access token will have been deleted), still has include_samhsa of true

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?

• 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

[ryan-morosa]

Nice work! I left a few comments and I think the testing coverage is sufficient and the functionality works as described. I wasn't able to do a case through postman where there was a code for the cache - is there a way this can get tested?

[JamesDemeryNava]

Nice work! I left a few comments and I think the testing coverage is sufficient and the functionality works as described. I wasn't able to do a case through postman where there was a code for the cache - is there a way this can get tested?

Thanks! For me, I always get a value for code in both form_valid of AuthorizationView and the post of TokenView if I am going through an auth flow. If you do a refresh token flow, code will be a None value in the post of TokenView, and we won't hit form_valid of AuthorizationView. For refresh tokens, we just grab the prior include_samhsa value, and apply that to the new access_token_extension record.

To me, if you did not check the checkbox, and include_samhsa was false on the resulting access_token_extension record, that means the caching is working. Though I am hoping to get @jimmyfagan's opinion on the caching strategy before merging this.

[ryan-morosa]

Nice work! I left a few comments and I think the testing coverage is sufficient and the functionality works as described. I wasn't able to do a case through postman where there was a code for the cache - is there a way this can get tested?

Thanks! For me, I always get a value for code in both form_valid of AuthorizationView and the post of TokenView if I am going through an auth flow. If you do a refresh token flow, code will be a None value in the post of TokenView, and we won't hit form_valid of AuthorizationView. For refresh tokens, we just grab the prior include_samhsa value, and apply that to the new access_token_extension record.

To me, if you did not check the checkbox, and include_samhsa was false on the resulting access_token_extension record, that means the caching is working. Though I am hoping to get @jimmyfagan's opinion on the caching strategy before merging this.

Totally. I think it makes sense to have an event-based caching strategy like you have here where we update the database and then remove the previous one from the cache. But I'd be open to other strategies too.