joshelser commented on issue #884: HBASE-23347 Allowable custom authentication methods for RPCs URL: https://github.com/apache/hbase/pull/884#issuecomment-561763753 ## Client fallback It looks like we had copied an idea from Hadoop where the client which was configured to auth'n over Kerberos, could fall back to trying to authenticate via SIMPLE. This seems silly to me and is off by default. I see one instance of someone poking at this https://issues.apache.org/jira/browse/HBASE-20993 but I'm missing the "why". I can't think of a reason that we would want to encourage this (not using the correct configuration to talk to HBase). Am I missing a use-case? ## How will compat be managed? Great question. I specifically avoided being prescriptive as to how compatibility should be maintained within some AuthenticationProvider. We have a couple ways that compatibility rears its head. ### RPC client/server <-> AuthenticationProvider interface I think this shouldn't be too bad to maintain since the interfaces are presently not tied to any RPC-related classes. Meaning, the RPC impl can do whatever processing it needs to do and just needs to extract the info to make the calls into the AuthProvider methods. ### ClientAuthnProvider v1 to ServerAuthnProvider v2 (etc) Clearly, each client/server AuthenticationProvider impl needs to have compatibility across versions to ensure that clients can continue to authenticate properly. I specifically avoided being prescriptive as to how implementations should account for this. The current interfaces don't leave much to "extrapolate" in the current interface -- I don't see much being able to change on the surface. Presently, I've only done stuff with Auth'nProviders which still rely on Hadoop Tokens. In theory, we could set up TLS in some other way, but that's a can of worms I didn't want to open. The other related piece here is that the `LimitedPrivate` annotation I marked this code with comes with a "you bet your butt it's gonna evolve" message. I think we have a good start, but expect that there's a world of other kinds of auth'n where these interfaces fall short (but I just don't know enough to plan for them all). ## You have a use-case? Wellington and I have been playing around with an implementation where we hook up HBase to Linux PAM. Client creates a new Token (ala TokenUtil) in which they put in their username/password, this is sent across the wire to the Master/RegionServer who asks PAM if the credentials are valid, allowing/disallowing the RPC per PAM's reply. This has been pretty slick in practice -- suddenly, HBase has username/password auth'n and we aren't in the business of storing/managing those passwords. The problem with this approach is that we have to handle a plaintext password going over HBase RPC. Best as I know, the RPC encryption we get from SASL only comes with the GSSAPI mechanism, not as a function of any SASL mechanism. PAM is (usually for real installations) going against some corporate auth'n database (e.g. active directory), and not just the local password db on each host. When we scale up&out, there's also going to be a worry about how well the backend auth'n database works (and is that going to kill HBase perf). So, it's a win to me, but it does bring some baggage with it. Hope that helps.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
