[GAP-8] HTTP auth runtime

[mfranciszkiewicz]

No description provided.

[stranger80]

A couple of points:

A. The end-to-end scenario including basic-auth-runtime is to me unclear.
It would be useful to have a basic diagram showing example usage, explaining the sequence of activities by Requestor, Provider(s), Users.

So is the usage scenario one fo the following (diagrams under: https://app.diagrams.net/#G1dmtsgmfLsOBrnk4s14QyyEVyCWt-VO2H) oris it something totally different? :

Scenario A:

1. Provider A offers some service X (published via basic-auth-runtime) on golem market
2. Requestor provisions an instance of service X on Provider A
3. Requestor calls Management API to create user credentials for service X
4. Users of service X call the endpoint published by basic-auth-runtime (on Provider A) with user credentials,
   the basic-auth-runtime authenticates and forwards the requests to service X instance (on the same Provider)

Scenario B:

1. Provider A offers basic-auth-runtime on golem market
2. Provider B offers some service X on golem market
3. Requestor provisions an instance of basic-auth-runtime on Provider A
4. Requestor provisions an instance of service X on Provider B
5. Requestor wants to configure reverse proxy with user authentication for service X, so he calls Management API to:
   • create service-forwarding configuration to route HTTP/S traffic to service X on Provider B
   • create user credentials for service X
6. Users of Service X call the endpoint published by basic-auth-runtime (on Provider A) with user credentials,
   the basic-auth-runtime authenticates and forwards the requests to service X instance (on Provider B)

B. Which party uses the ManagementAPI?
a) Is it the Requestor, after obtaining an instance of basic-auth-runtime?
b) Is it the Provider, to dynamically configure services?

• How is the caller of Management API authenticated?

[mfranciszkiewicz]

@stranger80 A quick reply before updating the doc and answering more thoroughly.

We replace nginx (or another web server) with our custom HTTP proxy. Services were, so far, configured by a human (or local scripts) via nginx config and htpasswd files. We introduce a Management API for our HTTP proxy as a replacement.

Management API is an interface between the Runtime and the Proxy. The API is exposed on a private address only and is hidden from both requestors and providers.

Side notes:

• we execute as many runtimes as activities; runtimes use the Runtime SDK (so Runtime API) to be controlled by ExeUnit Supervisor (ExeScripts, signals, etc.)
• we spawn a single instance of an HTTP proxy; each runtime communicates with the proxy via Management API

I'll edit the document to address your remarks and hopefully make things (more) clear

[stranger80]

TC session 27/01/2022:

1. TLS concern - handling self-signed certificates - is it secure?

• the cert hash included in the offer will need to be validated, and that should be sufficiently secure
• it is assumed that major libraries will support the self-signed cert-based TLS scenario

2. Do we support exposing many services on one port but under different paths? because it can be problematic for some users to forward the multiple exposed ports?

• yes, it is supported.

3. Should the proxy support HTTP (without TLS)?

• Yes, that may be useful in dev mode, and should require explicit flag to enable (ie. to prevent enabling HTTP by error)

4. Should Golem Factory run its own CA infrastructure?
   4.1. Should Golem Factory issue certificates on request (signed by its own root certificate)?

• question not relevant for the GAP
  4.2. Should Golem Factory's runtime accept by default the Golem Factory's certificates?
• it's enough for the auth runtime to allow any server side certs as configured by the Provider. A specific client-side cert is not required, and will not be validated by the runtime/proxy - but rather will be rejected (the client-side cert must be generated during handshake).

5. Is this runtime something that may with time be enhanced with other modes of authentication? Should we call it a more generic "HTTP auth runtime"?

6. Why are we writing a custom reverse proxy rather than using nginx?

• because we have no robust way of gathering usage counters (with nginx that could be only derived from logs, a parser would need to be written, etc.). Having a custom reverse proxy give full flexibility in implementing usage counters.
• can the rationale be added to the GAP please

[maaktweluit]

We could use https://streamr.network/ for the next steps of this GAP