Create a `uss_qualifier` dev scenario for auth testing

[BradNicolle]

Is your feature request related to a problem? Please describe.
When testing the configuration of a uss_qualifier with a new Token Exchanger, it would be useful to test this configuration in isolation. This is difficult using the existing scenarios, as these typically assume the existence of a DSS/USSs and particular scopes.

Describe the solution you'd like
A new dev scenario (akin to NoOp) which will perform a single token request using a provided AuthSpec, scope list, and audience. It should succeed if a valid token is returned, and fail otherwise. The HTTP request/response should be included in the report where applicable.

Describe alternatives you've considered
Trying to use existing scenarios such as AuthenticationValidation with dummy DSS URLs. It does not appear that custom scopes can be provided here though, and the test will likely fail against a non-existent DSS.

[BenjaminPelletier]

There is now a pending PR to address most of this request, but I think this portion is challenging (and isn't addressed by the current PR):

The HTTP request/response should be included in the report where applicable.

The response would contain an access token which is usually redacted from reports, and the request would likely often contain information even more sensitive than access tokens (e.g., credentials by which many access tokens can be generated). In addition, the current AuthAdapter framework doesn't produce Query objects so this would require a bit more effort than the scenario in the current PR. Is this an important element, or could it be descoped from the request? If important, do you have a suggestion on how the sensitive information in the request and response could be treated before/when being included in the report?

[BradNicolle]

Great, thanks!

The most important thing we want to verify is that the AUTH_SPEC has been generated and mounted to the uss_qualifier in the format it expects, and that the values in this AUTH_SPEC must be correct due to their interaction with the Token Exchanger.

That's a good point regarding sensitive values - it's not a strong requirement to record the exact request/response, we just need some way to verify:

• that the token request was made to the expected host (i.e. demonstrate that our AUTH_SPEC was configured as expected)
  • this would be satisfied if the report records the token endpoint it called
• whether the request was successful (further demonstrating that the AUTH_SPEC must have contained valid credentials for the requested scopes/audience)
• whether the token returned in the request was valid

On the last point, if the uss_qualifier could automatically verify that for us, that would also meet the requirement, i.e.:

• try parsing the JWT
• verify against the configured public key
• check that all fields are as expected (algorithm, issuer, expiry, audience, subject, scopes).

If those JWT verification steps are difficult/complex, we could potentially relax that requirement too. We are able to separately manually check that the Token Exchanger returns tokens as expected, and then the uss_qualifier test could just verify that it can call that Token Exchanger with given credentials and receive a success response.

[BradNicolle]

In addition, another nice-to-have would be an indication of any error response for debugging. This could be just the response code and response body in a non-200 case (provided we don't expect sensitive values there).

We also have logs available, so it is suitable if this debugging information is just included in the logs (and not report).