You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by Willem van Asperen <wi...@van.asperen.org> on 2015/10/26 00:21:54 UTC
identity-assertion fails for Hive without Kerberos
We have an unsecure (no Kerberos) cluster that is secured through a Knox
gateway. The gateway correctly authenticates users and works fine.
Connecting to Hive Server2 also works fine.
We are now implementing user assertion in Knox. A user known outside,
for example |willem|, is (after correct authentication) transformed into
the user |usr_hdp_developer|. I can see this transformation happening
correctly. In fact, I see the following audit rows:
|15/10/15 09:04:08
||2a0bda3b-be2a-4963-9f8a-69f519e4034f|audit|HIVE|willem|usr_hdp_developer||identity-mapping|principal|willem|success|
15/10/15 09:04:08
||2a0bda3b-be2a-4963-9f8a-69f519e4034f|audit|HIVE|willem|usr_hdp_developer||identity-mapping|principal|<strong>usr_hdp_developer</strong>|success|Groups:
[grp_hdp_developer, ...|
When I now access Hiver Server2 through Knox, I can see that Knox tries
to tell Hive to user the translated username:
|15/10/15 09:04:08
||2a0bda3b-be2a-4963-9f8a-69f519e4034f|audit|HIVE|willem|usr_hdp_developer||dispatch|uri|http://hdpprdhiv01.XXX:10001/cliservice?user.name=usr_hdp_developer|success|Response
status: 200|
It hands down the parameter |user.name| with the correct username to the
cliservice.
But this is not respected at the Hive side. Here I see:
|2015-10-15 08:44:40,291 INFO [HiveServer2-HttpHandler-Pool: Thread-36]:
HiveMetaStore.audit (HiveMetaStore.java:logAuditEvent(371)) - ugi=willem
ip=unknown-ip-addr cmd=get_table : db=analyse tbl=bag_adres|
This is what I found:
In the DefaultDispatch, a call is made to addCredentialsToRequest()
(when not Kerberos!). For the Hive dispatcher, this just adds an
Authorization header with just the primairy principal.
I thought it would be good practice to use the class
IdentityAsserterHttpServletRequestWrapper to do the mangling of the
Authorization header and put the asserted identity into that header.
I have patched the IdentityAsserterHttpServletRequestWrapper to put the
asserted user into the Authentication header -- but the IdentityAsserter
filter seems to be applied BEFORE the call to addCredetialsToRequest()
is made in the DefailtDispach.
Does this mean that the HiveDispatch class needs to become aware of
identity assertion and add the asserted username into the Authorization key?
I can see that the request comes in with the ORIGINAL Authorization
values (for the "outside" principal).
What are your views? Should HiveDispatch become aware of identity assertion?
Regards,
Willem
RE: identity-assertion fails for Hive without Kerberos
Posted by Willem Van Asperen <wi...@van.asperen.org>.
Yes. The patch I made today does exactly this, be it without using the helper class.
I do think the name Impersonating user is a little bit confusing as that is the same term frequently used for the doAs parameter, something that the outside user might add to their request.
A more appropriate name might be AssertedPrincipal which is more in line with the service identity-assertion.
W
-----Original Message-----
From: "Kevin Minder" <ke...@hortonworks.com>
Sent: 10/26/2015 19:18
To: "dev@knox.apache.org" <de...@knox.apache.org>
Subject: Re: identity-assertion fails for Hive without Kerberos
Please take a look at
https://issues.apache.org/jira/browse/KNOX-581
And the related change
https://git-wip-us.apache.org/repos/asf?p=knox.git;h=dc86bde
Would this take care of your issue?
On 10/25/15, 7:21 PM, "Willem van Asperen" <wi...@van.asperen.org> wrote:
>We have an unsecure (no Kerberos) cluster that is secured through a Knox
>gateway. The gateway correctly authenticates users and works fine.
>
>Connecting to Hive Server2 also works fine.
>
>We are now implementing user assertion in Knox. A user known outside,
>for example |willem|, is (after correct authentication) transformed into
>the user |usr_hdp_developer|. I can see this transformation happening
>correctly. In fact, I see the following audit rows:
>
>|15/10/15 09:04:08
>||2a0bda3b-be2a-4963-9f8a-69f519e4034f|audit|HIVE|willem|usr_hdp_developer||identity-mapping|principal|willem|success|
>15/10/15 09:04:08
>||2a0bda3b-be2a-4963-9f8a-69f519e4034f|audit|HIVE|willem|usr_hdp_developer||identity-mapping|principal|<strong>usr_hdp_developer</strong>|success|Groups:
>[grp_hdp_developer, ...|
>
>When I now access Hiver Server2 through Knox, I can see that Knox tries
>to tell Hive to user the translated username:
>
>|15/10/15 09:04:08
>||2a0bda3b-be2a-4963-9f8a-69f519e4034f|audit|HIVE|willem|usr_hdp_developer||dispatch|uri|http://hdpprdhiv01.XXX:10001/cliservice?user.name=usr_hdp_developer|success|Response
>status: 200|
>
>It hands down the parameter |user.name| with the correct username to the
>cliservice.
>
>But this is not respected at the Hive side. Here I see:
>
>|2015-10-15 08:44:40,291 INFO [HiveServer2-HttpHandler-Pool: Thread-36]:
>HiveMetaStore.audit (HiveMetaStore.java:logAuditEvent(371)) - ugi=willem
>ip=unknown-ip-addr cmd=get_table : db=analyse tbl=bag_adres|
>
>
>This is what I found:
>
>In the DefaultDispatch, a call is made to addCredentialsToRequest()
>(when not Kerberos!). For the Hive dispatcher, this just adds an
>Authorization header with just the primairy principal.
>
>I thought it would be good practice to use the class
>IdentityAsserterHttpServletRequestWrapper to do the mangling of the
>Authorization header and put the asserted identity into that header.
>
>I have patched the IdentityAsserterHttpServletRequestWrapper to put the
>asserted user into the Authentication header -- but the IdentityAsserter
>filter seems to be applied BEFORE the call to addCredetialsToRequest()
>is made in the DefailtDispach.
>
>Does this mean that the HiveDispatch class needs to become aware of
>identity assertion and add the asserted username into the Authorization key?
>
>I can see that the request comes in with the ORIGINAL Authorization
>values (for the "outside" principal).
>
>What are your views? Should HiveDispatch become aware of identity assertion?
>
>Regards,
>Willem
>
Re: identity-assertion fails for Hive without Kerberos
Posted by Kevin Minder <ke...@hortonworks.com>.
Please take a look at
https://issues.apache.org/jira/browse/KNOX-581
And the related change
https://git-wip-us.apache.org/repos/asf?p=knox.git;h=dc86bde
Would this take care of your issue?
On 10/25/15, 7:21 PM, "Willem van Asperen" <wi...@van.asperen.org> wrote:
>We have an unsecure (no Kerberos) cluster that is secured through a Knox
>gateway. The gateway correctly authenticates users and works fine.
>
>Connecting to Hive Server2 also works fine.
>
>We are now implementing user assertion in Knox. A user known outside,
>for example |willem|, is (after correct authentication) transformed into
>the user |usr_hdp_developer|. I can see this transformation happening
>correctly. In fact, I see the following audit rows:
>
>|15/10/15 09:04:08
>||2a0bda3b-be2a-4963-9f8a-69f519e4034f|audit|HIVE|willem|usr_hdp_developer||identity-mapping|principal|willem|success|
>15/10/15 09:04:08
>||2a0bda3b-be2a-4963-9f8a-69f519e4034f|audit|HIVE|willem|usr_hdp_developer||identity-mapping|principal|<strong>usr_hdp_developer</strong>|success|Groups:
>[grp_hdp_developer, ...|
>
>When I now access Hiver Server2 through Knox, I can see that Knox tries
>to tell Hive to user the translated username:
>
>|15/10/15 09:04:08
>||2a0bda3b-be2a-4963-9f8a-69f519e4034f|audit|HIVE|willem|usr_hdp_developer||dispatch|uri|http://hdpprdhiv01.XXX:10001/cliservice?user.name=usr_hdp_developer|success|Response
>status: 200|
>
>It hands down the parameter |user.name| with the correct username to the
>cliservice.
>
>But this is not respected at the Hive side. Here I see:
>
>|2015-10-15 08:44:40,291 INFO [HiveServer2-HttpHandler-Pool: Thread-36]:
>HiveMetaStore.audit (HiveMetaStore.java:logAuditEvent(371)) - ugi=willem
>ip=unknown-ip-addr cmd=get_table : db=analyse tbl=bag_adres|
>
>
>This is what I found:
>
>In the DefaultDispatch, a call is made to addCredentialsToRequest()
>(when not Kerberos!). For the Hive dispatcher, this just adds an
>Authorization header with just the primairy principal.
>
>I thought it would be good practice to use the class
>IdentityAsserterHttpServletRequestWrapper to do the mangling of the
>Authorization header and put the asserted identity into that header.
>
>I have patched the IdentityAsserterHttpServletRequestWrapper to put the
>asserted user into the Authentication header -- but the IdentityAsserter
>filter seems to be applied BEFORE the call to addCredetialsToRequest()
>is made in the DefailtDispach.
>
>Does this mean that the HiveDispatch class needs to become aware of
>identity assertion and add the asserted username into the Authorization key?
>
>I can see that the request comes in with the ORIGINAL Authorization
>values (for the "outside" principal).
>
>What are your views? Should HiveDispatch become aware of identity assertion?
>
>Regards,
>Willem
>