Secure communication between Connector and Domain Registry

[rjflp]

Connector and Domain Registry only communicate with each other. HTTPS with client and server certificates can be used to ensure security and authentication.

If these two are guaranteed to be deployed in a private LAN, HTTPS could be turned off for better performance.

[rjflp]

Currently implemented in the load balancer from the server side.
Waiting for implementation on the connector side.

Client side authentication still missing.

[rjflp]

Currently secure access is not implemented as the Discovery Service requires access to the Domain Registry.

A compromise must be reached. At least, write access should be restricted.

[rjflp]

At the Lisbon meeting, it was decided to:

• Keep the REST API open for read access from everyone (at least for the time being).
• Implement HTTPS and mutual authentication (certificates?) between the domain's Message Node and Domain Registry. Writes will only be permited through this connection.
• In the future, when the Message Node authenticates the user from the runtime, only enable writes from the user that "owns" the hyperty instances being modified.

[sbecot]

I think management of security between message node and domain should be delegated: if you are (like now) on a local LAN, no security rule is necessary. In case of open access, it can be delegated through an API Gateway with credentials. At least the possibility to have a simple http access should be kept for performance reason. Also because behind a proxy (or gateway), no need to add stack of https.

[rjflp]

Status update:
-Currently having difficulty accessing the certificate from the client side. Also having difficulty with Spark, which apparently does not support client authentication using HTTPS certificates.
-If no solution is found to the previous problems, will go ahead with using a signature to validate requests and replies, even though these already use HTTPS.

[nunofmn]

Added in release 0.8.0