[WIP] Allow accepting JWT tokens from other CARDs instances

[OrdiNeu]

Description

For the hub-and-spoke principle that we're hoping to use, it'll be convenient for us to pass JWT tokens between CARDS instances (for example, to pass updates on a form from one instance to another). This PR introduces a few things that allow this:

1. Switching from symmetric to asymmetric encryption, so that we can pass the ability for CARDS instances to verify one another without needing them to be able to create new tokens for each other. The current CARDS implementation uses symmetric encryption, where the same key is used for encryption & decryption, which opens up a vulnerability where if you can decode it, you could also fake requests coming from another CARDS instance.
2. Allowing you to store peer tokens, trusting or distrusting their JWTs as needed. This allows each site to selectively choose which peers they trust, which is a key part of federation (although slightly annoying in practice because we've had issues in CanDIG where people retained out of date keys).

To Test

• Start up two cards instances:
  1. On one, add: audBuilder.add("localhost8081"); to CardsJwtTokenManagerImpl:152 and start via ./start_cards.sh --dev --test
  2. On the other, export CARDS_HOST_AND_PORT=localhost:8081 and then run ./start_cards.sh --dev --test -p 8081
• Create a new patient/visit for each

You'll notice, under /bin/browser.html, that the JWTSigningKey has been moved to a node named JWTRSA256Key replaced with an asymmetric key:

You'll also notice, after creating a Survey for the new patient and logging in as that patient, that the structure of the JWT in the cards_auth_token has changed

You can then create a new Node /jcr:system/cards:jwt/localhost8080 (EDIT: you now need to use the hex representation of the hash of the public key as the node name) to the second instance, with property "verify" equal to the "verify" token from the first instance. If you login to the second instance as a Visit subject, and then replace the cards_auth_token cookie with its value from the first instance, it will not crash when you refresh the page.

This code is technically backwards compatible with running instances of Cards, retaining the ability to decode tokens under the previous encryption scheme. However, it will no longer mint new Tokens using the old symmetric key.

Future work

• Automatically providing/downloading peer tokens given just their URL is a feature that is enabled in CanDIG via the OIDC protocol, but I haven't implemented it here. Normally this involves Keycloak providing an OIDC endpoint for us to read all the public key, etc for.
• Dev-only endpoint for minting tokens? I should probably have a dev endpoint just to mint/test the JWTs rather than co-opting the Survey link.

[OrdiNeu]

Closed as it's been moved to IAP (see data-team-uhn/iap#40 )