[uss_qualifier] new resource for cleanly exposing the client identity

[Shastick]

This is the proper fix for #306:

The client identity (or more colloquially the sub field of its JWT) is now exposed to any resource or scenario that needs it via a ClientIdentityResource, which now holds the whoami_* audience and scope definitions that were formerly passed to the IDGeneratorResource.

The IDGeneratorResource now depends on the new resource to obtain the client_identity.

It should be noted that the whoami_* audience and scope will be used to request a token only if no other token had yet been requested by the auth_adapter:

The IDGeneratorResource will wait until subscriber() is called for the first time before checking if get_sub() returns something.

[Shastick]

edit indeed, a problem in the config caused the DSS tests to be skipped and this got caught by the aggregate check. This is ready for review.

This would be ready for review: It is unclear to me what causes the failure. Could it be due to a subtle change in the configuration files?

The logs show this:

 2023-11-22 11:30:52.233 | ERROR    | monitoring.uss_qualifier.reports.validation.report_validation:validate_report:306 - Validation criterion 2 failed to validate.  Criterion definition:
applicability:
  skipped_actions: {}
pass_condition:
  elements:
    count:
      equal_to: 0.0

But both the F3411-19 and F3411-22a test suites indicate a SUCCESS so I'm confused.

edit2: Now running into this warning:

2023-11-22 11:27:44.056 | WARNING  | monitoring.uss_qualifier.suites.suite:__init__:259 - Skipping action 1 (test_suite suites.astm.utm.f3548_21) because Test suite "ASTM F3548-21" is missing resource invalid_flight_intents (resources.flight_planning.FlightIntentsResource)

edit3: a resource was indeed missing.

[BenjaminPelletier]

Most AuthAdapter subclasses do not have this method, so this line will fail when using most types of AuthAdapter

[Shastick]

get_sub seems to be defined on the AuthAdapter parent class:

it returns a None if no token with a sub can be found, and the constructor properly initializes self._tokens to an empty Dict so I assume this will at worst always return a None?

That would indeed seem to be a problem in situations where the adapters implement issue_token() (which raises a NotImplementedError in the superclass) and then do not update the adapter's token map for some reason: in such a case get_sub would return a None again after issue_token() has been called below.

(although, possibly for such situations the sub field value would be known and get_sub() could be overridden, such as has been done in DummyOAuth in this PR? This way we would not even call issue_token())

Now, if some implementations would effectively fail on get_sub, can I assume issue_token will always be available?

[BenjaminPelletier]

Oops, entirely my mistake; my original comment here was entirely wrong. Sorry about that!

The thing that was throwing me off was the new get_sub on just one subclass, but of course this makes sense as there is a particularly easy/better way to implement that pre-existing base-class method on that specific subclass. In any case, entirely my bad.