accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: [External] Re: Accumulo 2.0 and the proxy Server
Date Fri, 30 Aug 2019 00:07:07 GMT
On Thu, Aug 29, 2019 at 2:51 PM Noah Randolph <> 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 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).

View raw message