Hi Rob -
If a given component requires a custom impersonation method then they can
provide a custom dispatch.
The impersonation using doAs query param in the DefaultDispatch is based on
the Hadoop defined impersonation using trusted proxies.
This mechanism predates the Knox project and is used across the ecosystem,
as Dilli indicated.
Knox is but one trusted proxy in the ecosystem. For example, you may have
Oozie workflows defined to make API calls to your component as well.
So, if you are adding new support for trusted proxies rather than
integrating Knox with an existing component specific impersonation
mechanism then you probably want to go with the default mechanism so that
you have support for other trusted proxies as well.
If there is something that you would like to do above and beyond that with
Knox because it would be more secure then we could consider component
specific extensions.
Hope that makes sense.
thanks,
--larry
On Fri, Nov 16, 2018 at 12:00 PM Dilli Dorai <dillido...@apache.org> wrote:
> Hi Rob,
> I have not been active recently on knox.
> Response from committers who added the feature would have more weight.
> In many existing haddop eco sub system REST API, doas query parameter is
> used.
> They have set up an usage pattern and knox seems to follow that.
> Thanks
> Dilli
>
> On Fri, Nov 16, 2018 at 8:33 AM Robert Levas <rle...@hortonworks.com>
> wrote:
>
> > Hey Knox team…
> >
> > I am curious about the location of the doAs indicator in the forwarded
> > request from Knox. Why is this a query parameter and not a request
> header,
> > like “X-DoAs”?
> >
> > Some infrastructures do not play well when trying to parse the query
> > parameters in authentication filters (for example Spring). I have worked
> > around my issue, but in the infrastructure that I am using if you attempt
> > to call httpServletRequest.getParameter("doAs") in the authentication
> > filter, the query parameters and request body get eaten and appear to no
> > longer be available to the request handler code.
> >
> > Aside from that, it seems like it would be more secure if the doAS value
> > was in the request header instead. For example it is encrypted when
> using
> > SSL.
> >
> > Can someone explain the reasoning behind placing doAs as a query
> > parameter? Is there any reason why it could not be a request header,
> > aside from existing code? Would it be possible for Knox to conditionally
> > set the doAs value as a query parameter or in the header based on some
> > metadata about the service or topology?
> >
> > Thanks,
> >
> > Rob
> >
> >
>
