[uss_qualifier] add auth tests for strategic coordination endpoints for USSs

[brandoncorrea]

This PR (partially?) addresses #703 by adding auth tests for USS endpoints for the following requirements:

• USS0105,1 (Get operational intent details)
• USS0105,3 (Notify operational intent details changed)
• USS0105,4 (Make USS report)

Notable Changes

• Moves GenericAuthValidator to a shared location, renaming the query_wrong_scope method to query_with_scope.
• Adds scd_authentication_validation scenario and documentation.
• Adds SCDAuthenticationValidation scenario to f3548_21.yaml suite and regenerates related docs.
• Increments message_signing.yaml validation criteria to include this scenario.

Additional Notes

• USS0105,2 (Get operational intent telemetry) was omitted, since a USS may not implement this (and may return 404).
• Notify operational intent requests are made with a random UUID and empty operational intent details. Any successful notification requests to a USS would be notifications of an unknown and empty operational intent.
• USSs are not tested with a missing scope, since the dummy oauth provider rejects token requests with a blank scope /token?intended_audience=foo&scope= with "Missing 'scope' query parameter"

Operational Intent Creation

In order to obtain the USS base URL for the USS under test, the scenario must first create an operational intent and query the DSS for the intent, which holds the USS base URL.

I'd love it if there were a way to obtain this without creating an operational intent that I'm not seeing.

[BenjaminPelletier]

Thanks for this -- looks like a good new scenario! A few comments below.

[brandoncorrea]

@BenjaminPelletier each of your comments have been addressed in the latest push!

Your last two comments had me thinking: if an endpoint only permits one scope, then a positive check probably isn't necessary (since the positive case is almost certainly exercised elsewhere).

Endpoints that permit many scopes, however, will probably need positive tests verifying that requests are not blocked, since we cannot guarantee the endpoint will have been exercised by every scope. For this reason I left the positive tests in for the makeUssReport tests, but I'd be happy to remove those as well if you feel they aren't necessary.

On the flip side of this: does the API contract require that only the scopes listed under the OpenAPI's Authority are accepted, and everything else rejected? For example, should a USS forbid a utm.constraint_management (or anyone not utm.strategic_coordination) user from requesting Operational Intent Details, or may a USS opt to extend the scopes it permits?

If the USS should forbid it, should we have checks that validate all other scopes are also rejected? Ran this scenario locally and the timing difference was milliseconds.

If the USS may permit it, should we remove the check that checks that an invalid scope is rejected?

[BenjaminPelletier]

Endpoints that permit many scopes, however, will probably need positive tests verifying that requests are not blocked, since we cannot guarantee the endpoint will have been exercised by every scope. For this reason I left the positive tests in for the makeUssReport tests, but I'd be happy to remove those as well if you feel they aren't necessary.

Makes sense and sounds good to keep :)

On the flip side of this: does the API contract require that only the scopes listed under the OpenAPI's Authority are accepted, and everything else rejected? For example, should a USS forbid a utm.constraint_management (or anyone not utm.strategic_coordination) user from requesting Operational Intent Details, or may a USS opt to extend the scopes it permits?

This is a little tricky from a strict requirements standpoint since OpenAPI doesn't specify that an implementation must not also implement additional capabilities (e.g., accept alternate authorization methods). For the purposes here, I think the interpretation is pretty clear that the enumerated scopes should usually be the only ones that can be used to access the associated resources.

If the USS should forbid it, should we have checks that validate all other scopes are also rejected? Ran this scenario locally and the timing difference was milliseconds.

I don't see a problem with that additional coverage apart from the normal tradeoffs (more coverage requires maintenance and runtime, so it should be "sufficiently" valuable...though there is no single definition of "sufficiently"). But, more smaller PRs are generally better than indefinitely iterating on the same PR so I would encourage this to be in a separate PR if you're interested in building it.