server: add schema validation / authentication

[derekperkins]

Following up on a discussion about multi-tenancy, I'm thinking about submitting a PR that's fairly opinionated, where the user can provide a flag for which "trusted headers" have to match the schema name. Here's what I envision that flow looking like:

1. Mosaic is configured with tenant_id, user_id, or something like that as the preagg.schema
2. Client sends through authenticated requests. Implementation is out of scope for this PR, but this assumes that there is a cookie or Authorization header per request, which is verified through an API Gateway or other mechanism. That middleware would inject some trusted headers, like X-Tenant-Id: 12345, verified-user-id: abc
3. Mosaic server is started with a flag: --schema_match_headers=X-Tenant-Id,verified-user-id
4. When the Mosaic server receives a request, it calls json_serialize_sql to get the full AST. It recurses through all the schema objects, and returns a 403 error if any schemas are referenced that don't match the header values
5. Finally execute the original SQL (or possibly json_execute_serialized_sql if there are performance benefits) and return the results as normal

A production implementation might pull those valid values out of a jwt or other mechanisms, headers just seems like the broadest solution for OSS. If that sounds like a reasonable fit, I'm happy to submit a PR to the Go server.

There's a larger question around the purpose of the servers (currently python, rust, and go). Are they there more as an option to have a plug and play server to use with mosaic, or if they're more intended as a proof of concept / implementation starter. The Go server I contributed was more in line with the latter, assuming that most use cases would have custom logic to run alongside the code, but maybe I'm thinking about it the wrong way.

Related Discussion:

• Security + multi-tenancy #817

[jheer]

The existing servers are intended primarily as proof-of-concept demos. I would expect production deployments would want to set up their own server implementations that align with an organization’s auth and data deployment strategies.

That said, I see no reason why the Go server can’t include some candidate mechanisms for more complex access scenarios. I would just want those to be opt-in via appropriate configuration options, along with documentation that conveys that these aren’t a “standard” for Mosaic.