DAPS token generation

[c0c0n3]

This PR implements #3 and #7, providing a configurable mechanism to request identity tokens from a DAPS server and using them to generate the context broker response header.

Functionality overview

When an external request for Orion hits the Istio mesh gateway, it gets routed to our adapter where we check there's a valid IDS header (see PR about client token validation) and then, if valid, we go on to requesting an ID token from the configured DAPS server. With that ID token in hand, we generate an IDS response header (fiware-ids-server-token) holding the ID.

The adapter sets up mTLS with DAPS. Hostname, certificates, etc. can be configured in Istio---for an example look at the daps block in deployment/sample_operator_cfg.yaml. Also through Istio config, you can control the format of the IDS JSON object holding the DAPS ID token---again, have a look at the above YAML file. This comes in handy to change e.g. connector ID, model version, etc.

[c0c0n3]

@gboege if you could please test this on your side too as documented in the README. You first try taming the beast in your local Minikube cluster using the provided spoof DAPS server. Then you can try reconfiguring the adapter to make it hook up with Fraunhofer's DAPS at daps.aisec.fraunhofer.de. Just follow the steps in the README. One thing you should check is the format of the JSON object we output in the response header...thanks!!!

[c0c0n3]

@gboege just following up on our chat the other day. I implemented the two changes you requested and pushed them to the dev branch so they'll be merged with this PR.

Server header

The header the adapter outputs that will be added to the headers returned to the client is now called header instead of fiware-ids-server-token.

Response message UUID

The id field of the JSON object in the above header now contains a v4 UUID that's generated on every call, e.g.

http://industrialdataspace.org/resultMessage/2c421a8a-1024-44a8-beb8-253f145c767b