For that usecase, I would consider the HeaderPreAuth federation provider and mutual authentication between your multi-tenant service and Knox.
The SSL based mutual authentication ensures that there is a trust relationship between the service and Knox. Otherwise, anyone could call it and pass the header with any username. http://knox.apache.org/books/knox-0-10-0/user-guide.html#HadoopAuth+Authentication+Provider http://knox.apache.org/books/knox-0-10-0/user-guide.html#Mutual+Authentication+with+SSL On Thu, Nov 10, 2016 at 9:32 PM, Mohammad Islam <[email protected]> wrote: > Excellent!! It shows Knox has a lot of important features with > flexibility.I will give a try. > In a related note, does Knox allows its user (service) to impersonate its > end user. For example,I have a multi-tenant service which is running as > user "serviceX". It wants to access to WebHDFS as its end-user (say userY) > not as serviceX. Does Knox provide this type of impersonation or doas() by > its client? > Any link would be really helpful? Regards,Mohammad > > > > > On Thursday, November 10, 2016 3:07 PM, larry mccay <[email protected]> > wrote: > > > I believe that what you want to do is more like: > > * HeaderPreAuthFederationFilter *as is* > * RegexIdentityAssertionFilter to extract the username from the email > address > > http://knox.apache.org/books/knox-0-10-0/user-guide.html# > Regular+Expression+Identity+Assertion+Provider > > This allows the incoming header to be flown through the provider chain as > the email address until it gets to identity assertion provider. The > identity assertion provider is responsible for determining the identity to > assert to the backend service. It is invoked prior to authorization checks > within the request processing as well. This allows the authorization checks > to be applied to the asserted identity as they will be done inside the > cluster as well. > > > > On Thu, Nov 10, 2016 at 5:18 PM, Mohammad Islam <[email protected]> > wrote: > > > Hi, > > Currently Knox supports username in http header with key SMUSER (which is > > configurable). > > > > I'm wandering how can we support email address in place of user name. In > > other words, in my use-case, preauth filter gets the email address as > > header, can we parse the email address to get the username/principal > name? > > > > I was considering two options: > > > > 1. Extending current functionality of HeaderPreAuthFederationFilter to > > support email address as well. That means if SMUSER is null, check for > > email address and then parse to get the principal name. > > > > 2. In HeaderPreAuthContributor class, set the "PREAUTH_FILTER_CLASSNAME" > > from configuration. Currently it is always assigned to " > > HeaderPreAuthFederationFilter". I believe this approach is > > extendable/pluggable. > > > > What do you guys think? > > > > Based on your suggestion, I can start working on it. > > > > Regards, > > Mohammad > > > > > > > > > > > >
