Oops - that was the wrong link for the header based preauth - sorry: http://knox.apache.org/books/knox-0-10-0/user-guide.html#Preauthenticated+SSO+Provider
On Thu, Nov 10, 2016 at 9:41 PM, larry mccay <[email protected]> wrote: > 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#Reg >> ular+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 >> > >> > >> > >> > >> >> >> >> > >
