search

apache / accumulo-proxy

Apache Accumulo Proxy
https://accumulo.apache.org
Apache License 2.0
9 stars 19 forks source link

Make the proxy single user #16

Closed mikewalch closed 1 year ago

mikewalch commented 4 years ago

From code review of #15, Simplify the proxy by dropping this login mechanism entirely, and make the proxy single-user (using the user specified in the proxy/client properties file).

ctubbsii commented 4 years ago

Under this paradigm, it still would be possible to support multiple users with a single proxy. However, the way it would be done is much simpler: you simply specify which client properties file the proxy should use to create AccumuloClient objects for the requested operations.

mikewalch commented 4 years ago

Under this paradigm, it still would be possible to support multiple users with a single proxy. However, the way it would be done is much simpler: you simply specify which client properties file the proxy should use to create AccumuloClient objects for the requested operations.

Does the proxy client need to be on the same server as the Proxy if this is done? There are Java bindings in case you want to limit access from the client to cluster. I am not sure if limiting access is still needed, I just wanted to bring it up.

ctubbsii commented 4 years ago

Does the proxy client need to be on the same server as the Proxy if this is done?

No. The client just needs to send a filename for a file that exists local to the proxy server... or, it could send the raw client properties, I suppose. The main point is to standardize client initialization around the client properties, either as raw properties or as a properties file, rather than the custom "logon" session stuff that the proxy has now. Avoiding the custom stuff and using the client properties in the same (familiar) way that the Java API uses them, would be the main goal.

The simplest thing to do is just have one set of client properties in the proxy server so it has one Java AccumuloClient for the lifetime of the proxy, to handle all the real client's requests. That implies a single-user scenario, so that's why I thought of that first.

The more complicated case would be the multi-user support via multiple sets of client properties. I haven't fully through through all the possible multi-user options and their implications... but just thinking that it could still be done, if we really wanted to have that complexity.

Which direction this goes is really up to user demand and how tolerant for complexity those maintaining the proxy are. I'm fine with the single user case (because my tolerance for complexity in Accumulo is low right now)... I just want to see the custom and unfamiliar proxy-specific stuff go away in favor of the friendly and familiar client properties.

milleruntime commented 2 years ago

@ctubbsii With the update in Accumulo 2.0.1, most of the ITs are throwing security exceptions. I have been looking where the user "user" gets setup but have not found that yet. I am wondering if this ticket is more important now that the exception bug was fixed in: https://github.com/apache/accumulo/pull/1828

Edit: The ITs can still pass but they are throwing security exceptions.

ctubbsii commented 2 years ago

@ctubbsii With the update in Accumulo 2.0.1, most of the ITs are now failing. I have been looking where the user "user" gets setup but have not found that yet. I am wondering if this ticket is more important now that the exception bug was fixed in: apache/accumulo#1828

I'm not sure how this ticket would relate to that one. The idea here is to just create a single AccumuloClient for that specific proxy instance, built from the client properties, and remove any "login" mechanisms.

I'm not sure what's going on with the ITs. It may be entirely unrelated.

milleruntime commented 2 years ago

I'm not sure what's going on with the ITs. It may be entirely unrelated.

See https://github.com/apache/accumulo-proxy/issues/31

DomGarguilo commented 1 year ago

Is the suggestion here to pass the client properties when creating the Accumuloproxy.Client which will be used to create the AccumuloClient once, which will then be used for all operations without having to pass in the "login" every time we want to do an operation?

ctubbsii commented 1 year ago

Is the suggestion here to pass the client properties when creating the Accumuloproxy.Client which will be used to create the AccumuloClient once, which will then be used for all operations without having to pass in the "login" every time we want to do an operation?

The suggestion is that starting the AccumuloProxy (via it's main method) will either automatically locate the client properties using the class path and/or environment and construct an AccumuloClient from that (just like bin/accumulo jshell does). I'm not sure what features we have right now to explicitly set the path to the client properties file... it might be a Java system property you can set with -Daccumulo.properties=/path/to/file or similar... but that should work also. The user should have to do nothing to construct the AccumuloClient object inside the proxy service. We may want to add some mechanism for the proxy client to authenticate to the proxy service, but that can be addressed later. The first pass, is just to simplify the proxy service authenticating to Accumulo.

DomGarguilo commented 1 year ago

Addressed in #59