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
>
>
>
>


   

Reply via email to