On Thu, Aug 29, 2019 at 2:51 PM Noah Randolph <[email protected]> wrote: > > Hi Christopher, > > Can you clarify the "multi user aspect?" Is it the ability to login as > multiple users through one client connection, or is it the ability to have > multiple users in general (beyond just root), or is it something else?
Sure, I can try. Currently, you the proxy is stateless with respect to authentication. Each client of the proxy constructs a serialized form of their credentials by calling `login()`, and then has to keep passing those credentials for each subsequent request. In this way, it supports multiple users (same connection or not). This isn't really the way the proxy is intended to be run, though. (I certainly wouldn't recommend it.) It's much better for the proxy to not sit as a service handling arbitrary client requests... but actually be run for a specific (presumably non-Java) client, locally to, and only for the lifetime of, that single client. Basically, one proxy per client. If you run it this way, it can be stateful... and it can take advantage of the new client configuration properties stuff in 2.0. When it starts, it can read the client.properties file and use those properties to construct a ready and waiting AccumuloClient object for that specific user. This is obviously a very different design than the current proxy, but doing things this way can dramatically simplify the proxy code, making it rely more on standard client configuration for Accumulo rather than doing its own custom stuffs. Any security model we implement to authenticate the real client to the proxy could be much simpler, if it's even necessary (could use a unix domain socket instead of IP so the connection can be secured by POSIX permissions). In any case, it was just one possible way we could simplify the proxy and make it more maintainable for future, while also designing it to work like the way we recommend (one proxy per client).
