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" <[email protected]> Sent: 10/26/2015 19:18 To: "[email protected]" <[email protected]> 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" <[email protected]> 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 >
