[
https://issues.apache.org/jira/browse/PHOENIX-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-3686:
--------------------------------
Attachment: PHOENIX-3686.001.patch
.001 Here's what I was thinking...
> De-couple PQS's use of Kerberos to talk to HBase and client authentication
> --------------------------------------------------------------------------
>
> Key: PHOENIX-3686
> URL: https://issues.apache.org/jira/browse/PHOENIX-3686
> Project: Phoenix
> Issue Type: New Feature
> Reporter: Josh Elser
> Assignee: Josh Elser
> Fix For: 4.10.0
>
> Attachments: PHOENIX-3686.001.patch
>
>
> Was trying to help a user that was using
> https://bitbucket.org/lalinsky/python-phoenixdb to talk to PQS. After
> upgrading Phoenix (to a version that actually included client
> authentication), their application suddenly broke and they were upset.
> Because they were running Phoenix/HBase on a cluster with Kerberos
> authentication enabled, they suddenly "inherited" this client authentication.
> AFAIK, the python-phoenixdb project doesn't presently include the ability to
> authenticate via SPNEGO. This means a Phoenix upgrade broke their app which
> stinks.
> This happens because, presently, when sees that HBase is configured for
> Kerberos auth (via hbase-site.xml), it assumes that clients should be
> required to also authenticate via Kerberos to it. In certain circumstances,
> users might not actually want to do this.
> It's a pretty trivial change I've hacked together which shows that this is
> possible, and I think that, with adequate disclaimer/documentation about this
> property, it's OK to do. As long as we are very clear about what exactly this
> configuration property is doing (allowing *anyone* into your HBase instance
> as the PQS Kerberos user), it will unblock these users while the various
> client drivers build proper support for authentication.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
