You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Josh Elser (JIRA)" <ji...@apache.org> on 2019/07/17 17:42:00 UTC

[jira] [Created] (PHOENIX-5393) Perform _HOST principal expansion for SPENGO QueryServer principal

Josh Elser created PHOENIX-5393:
-----------------------------------

             Summary: Perform _HOST principal expansion for SPENGO QueryServer principal
                 Key: PHOENIX-5393
                 URL: https://issues.apache.org/jira/browse/PHOENIX-5393
             Project: Phoenix
          Issue Type: Improvement
            Reporter: István Tóth
            Assignee: Josh Elser
             Fix For: queryserver-1.0.0


[~stoty] found that we aren't doing {{_HOST}} expansion for PQS. We naturally get this for the principal we use to talk to HBase (by virtue of using SecurityUtil/UGI to log in). However, for SPNEGO, we're using the Avatica API to do this, so it doesn't do this "Hadoop-ism" for us.

We can use SecurityUtil to do it ourselves and then pass the correct hostname into the Avatica {{HttpServer.Builder}} API.

The error you get when {{_HOST}} is set is pretty obtuse on the server-side, including to help the poor soul who ventures here with a similar error.
{noformat}
2019-07-17 08:48:03,383 WARN org.apache.phoenix.shaded.org.eclipse.jetty.security.SpnegoLoginService:
GSSException: Failure unspecified at GSS-API level (Mechanism level: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - DES3 CBC mode with SHA1-KD){noformat}
We identified the problem by seeing, in {{-Dsun.security.spnego.debug=true -Dsun.security.krb5.debug=true}} output, the following:
{noformat}
Looking for keys for: HTTP/_HOST@EXAMPLE.COM{noformat}
At this point in the call, we should have had an expanded "instance" in the principal.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)