[#227] implement jku checking feature

[gimppa]

Description

Related issues

Implements #227

Type of change

• New feature (non-breaking change which adds functionality)

Changes Made

Added new config variable trusted_jkus and a check in beacon_api.ga4gh.get_ga4gh_permissions to see if passport jku is whitelisted.

Testing

• Unit Tests

Mentions

@teemukataja helped with writing tests

[blankdots]

might want to base this branch on feature/python_3_10 so that 3.10 changes are take into consideration

[blankdots]

i think we need a combination of iss and jku, because this only trusts the jku not the actual issuer

[blankdots]

i think we need a combination of iss and jku, because this only trusts the jku not the actual issuer

we can do that in a different PR because:

If a Passport Clearinghouse is to use the jku URL to fetch the public keys to verify the signature, then it MUST verify that the jku is trusted for the given iss as part of the Passport Clearinghouse's trusted issuer configuration. This check MUST be performed before calling the jku endpoint.

source: https://github.com/ga4gh/data-security/blob/master/AAI/AAIConnectProfile.md#conformance-for-passport-clearinghouses

@teemukataja seems like you suggested that: neicnordic/sda-download#82 (review)

[teemukataja]

i think we need a combination of iss and jku, because this only trusts the jku not the actual issuer

we can do that in a different PR because:

If a Passport Clearinghouse is to use the jku URL to fetch the public keys to verify the signature, then it MUST verify that the jku is trusted for the given iss as part of the Passport Clearinghouse's trusted issuer configuration. This check MUST be performed before calling the jku endpoint.

source: https://github.com/ga4gh/data-security/blob/master/AAI/AAIConnectProfile.md#conformance-for-passport-clearinghouses

@teemukataja seems like you suggested that: neicnordic/sda-download#82 (review)

I was thinking that we don't need to check the issuer, because only the key matters for the validity of the token (as long as we trust the key, the token is good), and this way it also makes a simpler implementation, when we can load a csv from env, and don't need to worry about the issuer, which can be just any string (but usually an address) 🤔

But the sda-download implementation is correct according to the spec 😄