Merge crossbar config with OCS crossbar config

[BrianJKoopman]

Our goal is for a sisock DataNodeServer to subscribe to data feeds provided by OCS to provide live monitoring in grafana. While the autobahn documentation leads one to believe a single Component can communicate with multiple crossbar servers, in practice we have yet to implement that. This led us to using a common crossbar server.

One change here is the realm name. We've moved to the OCS realm, 'realm1', from 'sisock'. This provides the common namespace for pub/sub and RPC.

For compatability with OCS we've added the OCS roles, 'iocs_agent' and 'iocs_controller', and the unsecured websocket transport on port 8001.

For interoperability between sisock and OCS we've also switched the auth on port 8001 to use the 'server' role. This is needed, as sisock needs to communicate with uri's that don't match the 'observatory.' prefix enforced for the 'iocs_agent' role. If this uri prefix for OCS needs to be this strict this should be fixed, but at the time of writing it's not entirely clear to the author the best way to accomplish this and maintain sisock/ocs communication.

This config allows sisock and ocs to run off of the same crossbar server, as well as communicate with each other.

[BrianJKoopman]

I just pulled this commit out of my working branch, since I'm sure there will be discussion about it. The config works for the sisock/ocs communication as is, but uses the sisock 'server' role instead of the 'iocs_agent' role to avoid the 'observatory.' prefix requirement, which would prevent the sisock end of things from working when using that port.

[ahincks]

Can we choose a different realm name? The name realm1 sounds too much like an example or default. How about simons or simonsobs?

Also, to make sure I understand, in the configuration you're working on, one will be able to connect either securely (port 8080) or unsecurely (8001), right? Presumably the latter is for clients on the same local network as the router. Do we have a policy or system in place to ensure that 8001 never gets exposed to the internet? I.e., I think we want to force clients outside the local network to connect using TLS.

[BrianJKoopman]

Can we choose a different realm name? The name realm1 sounds too much like an example or default. How about simons or simonsobs?

Yeah, I agree here. I chose realm1 because that's what was used in the OCS config (I haven't opened a similar pull request in the OCS repo, because no changes there are needed given this config in its current form.)

Also, to make sure I understand, in the configuration you're working on, one will be able to connect either securely (port 8080) or unsecurely (8001), right? Presumably the latter is for clients on the same local network as the router. Do we have a policy or system in place to ensure that 8001 never gets exposed to the internet? I.e., I think we want to force clients outside the local network to connect using TLS.

That's right, and the DataNodeServer I'm working on that subscribes to the OCS data feeds connects over 8001. Though now that I'm writing that it makes me wonder if what caused me to switch to that port was simply my not fully understanding the implications of the configuration. (And it has me wondering if I can have this connect over 8080 instead.) And yes, that's the idea, local connections can be made on 8001.

I'm not aware of any written down policy yet, but yes, we must make sure 8001 isn't exposed. I'm sure a port policy will come together as we approach actually having networking equipment.

[ahincks]

OK, so the question I have is whether we want to pin down a stable definition for our router at this point, or whether this version of sisock will use the transitional definitions currently used by ocs. I.e., should we just change both ocs and sisock in one fell swoop now? Let's see if @mhasself, as the ocs dean, has an opinion.

To summarise, for the stable definition I think we need at least the following:

• Choose a proper realm name.
• Decide on which port(s) we are going to use, whether we want non-secure connexions even on the local network and, if so, how we are going to ensure that non-secure ports are not exposed to the internet.

[mhasself]

Firewall config and port allocation are probably beyond the scope of this repo. We should talk about it elsewhere, though. Here, it's important that we've found a config that works with those two exposures (ws and wss) simultaneously.

I think we should consider the realm name and port numbers as site-specific configuration parameters. And to that end, we should provide a template for a plausible .crossbar, rather than the .crossbar we intend people to run live. If you want an example to run easily, use realm name and ports that you expect will not be the final ones, so that there's no risk of conflict and confusion if someone tries to run the example near the real, running system.

So how about defaulting to "test_realm"; and we'll reserve "sobs_realm" or "yale_realm" for real, deployed, vulnerable systems?

Also I like having "realm" in the realm name; when all strings say "test" or "simons" it can be challenging to remember what they are the name of! But admittedly I can't remember in this case if it's already pretty obvious when one is naming the realm vs. naming, e.g., the prefix for RPC. So might not be a big deal.

[BrianJKoopman]

I have updated this to use test_realm as the default. The latest version of OCS off loads the realm name configuration to the ocs-site-configs repo, which I've pushed an update to.

Merging and closing this pull request.

[BrianJKoopman]

Accidentally closed this. Reopening to merge...